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.

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:

openssl pkcs12 -in my-original.p12 -out certkey.pem -nodes -clcerts

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:

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: <No 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-----

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:

$ 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:

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