PHP Session Permission Denied Errors with Sub-Domains and IE7 or IE8

I encountered a strange problem with IE7 and IE8 where if I visited `example.com` first and then visited `sub-domain.example.com`, Apache would return Permission Denied errors errors when trying to access the PHP session files for `sub-domain.example.com`.

After some investigation, it appears this is a problem with the way IE7 and IE8 request session data from Apache, or possibly because IE7 and IE8 have a non-standard way of announcing the domain they're requesting session data for.

Here's my scenario:

I'm running Apache 1.3 with two domains, each has their own account with their own users:

    Domain: mycompany.com
    Session path: /tmp/
    Webserver user: mycompanycom

    Domain: support.mycompany.com
    Session path: /tmp/
    Webserver user: nobody

Here is what happens during a normal visit with Firefox/Safari/Chrome:

  1. I visit `mycompany.com` and session file is created in /tmp/ owned by the user mycompanycom
  2. I then visit `support.mycompany.com`, and second session file is created in /tmp/ owned by user nobody
  3. Apache doesn't get confused and the correct session files are returned

However, here's what happens during a visit with IE7 and IE8:

  1. I visit `mycompany.com` and a session file is created in /tmp/ owned by the user mycompanycom
  2. I then visit `support.mycompany.com` and, instead of creating second session file in /tmp/ owned by the user nobody as you would expect (and as happens when using Firefox/Safari/Chrome), Apache tries to return the session file for mycompany.com.
  3. The session file for `mycompany.com` is owned by the user mycompanycom, so the web server, running as user nobody cannot access it. Permission is denied.

I searched Google for a solution and came across this question on StackOverflow. Several users suggested creating a separate directory in /tmp/ to separate the stored session data for `support.mycompany.com` from the session data for `mycompany.com` and then telling PHP to store all session data for `support.mycompany.com` in the new directory. This worked perfectly!

Here's what I did. First, create the new session directory (Note: Make sure the new directory resides inside /tmp/!):

    mkdir /tmp/support.mycompany.com
    chown nobody:nobody /tmp/support.mycompany.com

I then added the following to an .htaccess file in the root web directory for `support.mycompany.com`:

    php_value session.save_path '/tmp/support.mycompany.com'

And finally, I removed all existing session data in /tmp/ to ensure the new session path would get used immediately:

    rm -f /tmp/sess_*

And that's it! Now IE7 and IE8 work properly because when visiting `support.mycompany.com`, IE7 and IE8 do not accidentally find session data for `mycompany.com` and try to use it.

I'm fairly certain this problem has to do with how IE7 and IE8 request session data from Apache. They probably first request session data for `mycompany.com` and THEN request session data for `support.mycompany.com`, even though the latter was the only doman entered in the address bar.

Internet Explorer: Incorrect Password During Certificate Import

While importing a P12 certificate into Internet Explorer today, I got a message saying "The password you entered is incorrect.":

Internet Explorer - Incorrect certificate password

However, I successfully imported this same certificate, using the same password, on Firefox and Safari. But Internet Explorer (both IE7 and IE8) continued to tell me I was using the wrong password. After checking, double-checking, and quadruple-checking the password, I was 1000% sure the private key password that I was using was correct and that Internet Explorer itself was to blame.

After much trial and error, I discovered the problem: Internet Explorer has a maximum private key password length! The password I was using (modified for security purposes, but identical in length) was as follows:

603979ba15c2097f8f7fy35ec0ucfbeb

That's 32 characters, the same length as an MD5. However, Internet Explorer appears to have a problem with that! I changed the password to the following 26 character password and the certificate imported with no complaints from IE!

ae869d263e267593286188b638

If you're having the same problem, you may be wondering how to change the password on your P12 file. To do this, you'll need access to OpenSSL. If you have a Mac, you might be able to find OpenSSL in /opt/local/bin/openssl. But more likely you're on Windows and you will need to download and install the OpenSSL binary for Windows.

You can use the OpenSSL program to convert the P12 file to PEM format, and then convert the PEM certificate back into a P12 file, using a shorter 26-character password when prompted. Here's how:

First, convert the original P12 file to PEM format:

[sourcecode lang="bash"]
openssl pkcs12 -in my-original.p12 -out certkey.pem -nodes -clcerts
[/sourcecode]

This should give you a file called certkey.pem. This file contains both the certificate and the private key. However, the next command requires that the key be contained in a separate key.pem file, so you'll want to edit certkey.pem with a text editor and extract the private key portion (it should be the bottom half of the file). The key.pem file should look somewhat like this:

[sourcecode lang="bash"]
Bag Attributes
localKeyID: EE 35 CB 41 81 23 4C 89 FF 43 42 E0 3C 3B FF 93 9E 0E B7 AA
Key Attributes:
-----BEGIN RSA PRIVATE KEY-----
MIIoOwLBAAJBANSdWgmhySZsCD/koC6nST/JzH/Uqjm6NXsQwtTwx493rhM/90BB
JyfdkfDQCHR/XP0szI1LqS/AXfSx1q25/3MCAwEAAQJBAM0Iu+Mm7zJTT7nqDgfv
VW+4RaRVp05JHaWQdeerpBnWJI+2NDsiKrovyrvYjglJcdpXHhoM95T5qm8x65XP
MhkCIQD5vQ2dNGoFGn0yL0ELDU39PrVvfZyJV3wXedjrQm9utwIhAN0FRk/qIWzz
p9ZP9DjIpIRj6BdWLRrZmLqxdnUXifSlAiBy6fb1u0RJjK7HBM9dPK7+NHiQEJCS
8dp7wZl5d1xnCSIhANLoF6pmnyLil4QwgVlOTv9ufqjSZ+w5GD7a3Vj678RpAiAV
6rTJ3mAZAeQiaRHhgRP7SuvQS6EDWDPxbMBMwYklfA==
-----END RSA PRIVATE KEY-----
[/sourcecode]

With these files in place, you can run the following command to convert the PEM certificate back into a P12 format, providing a new password (maximum 26 characters) when prompted for the Export Password:

[sourcecode lang="bash"]
$ openssl pkcs12 -export -in certkey.pem -inkey key.pem -out my-new-certificate.p12 -rand /dev/random
2048 semi-random bytes loaded
Enter Export Password:
Verifying - Enter Export Password:
[/sourcecode]

That's it! Now you should be able to install the certificate in Internet Explorer without any "incorrect password" complaints.

Internet Explorer "Remember my password" Checkbox Missing

On my office laptop, I discovered the Internet Explorer "Remember my password" checkbox option was missing. This was quite annoying, as I started using Eclipse's internal browser to test my development work on the staging server I setup at home. The staging server is protected by a simple .htaccess file, which prompts you for a username/password with a dialog box like the one below:

As you can see, its missing the "Remember my password" option, which means I have to reenter the credentials every time I want to login. After a lot of research on Google, I finally figured out the problem: the Protected Storage service needs to be running. Either I disabled the Protected Storage service or a Windows security update did. Either way, after changing the "Startup type" to Automatic and restarting all IE browsers, here's how the password dialog looked:

I have a feeling that a Windows, or an Internet Explorer, security update changed the way IE stores passwords. For most users, the update had no effect since the Protected Storage service is set to Automatic by default. But not for me; I love tinkering with stuff. I disabled a lot of unnecessary Windows XP services on my laptop last year to help keep it secure while I'm on the move.

Update:
In the comments, Haiman posted the following alternate fix. Several users reported his fix worked for them, so I'm including it here. (You'll need to use the registry editor to make this change, Start->Run->regedit.exe, but be sure to make a backup of your registry before fooling around with it!)

Your office pushes out a GPO or registry change to disable users from caching passwords.

User Key: [HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersion
Internet Settings]
Value Name: DisablePasswordCaching
Data Type: REG_DWORD (DWORD Value)
Value Data: (0 = default, 1 = disable password cache)

Why I won't install IE7

IE7 needs Service Pack 2.

Service Pack 2 does horrible things to a computer. For example, I have two computers with the same exact hardware specs. Same services running. The SP2 computer runs MUCH slower than the SP1 computer. I'm not just talking about network speed (I know about the TCP connection limitation in SP2 (from 65k connections down to 10 connections! (and I know about the tcpip.sys hack to fix it)). I'm talking about launching programs, opening my computer, etc. All are much slower with SP2.

So, unless someone can find me an IE7 that runs with SP1, I won't be installing it. Besides, Firefox does everything I need on a daily basis, and IE6 is there for backup, in case there's some stupid ASP site that I need to view that just wont work right in Firefox (damn non-standardization!).