We have a site www.name1.domain.com for which we successfully created and implemented an SSL cert. We then added another site, www.name2.domain.com, and are seeing some strange behaviour in IE7 and IE8 (surprise!).
Basically, IE7,8 reports a mismatch of host name when we go to https://www.name2.domain.com/ . When I add and view this cert in IE for this domain, the host name is incorrect, but belongs to the older host name, i.e., www.name1.domain.com.
Firefox doesn't have this issue, and picks up correct host name www.name2.domain.com for the second site without issue.
Any ideas why IE is misbehaving (apart for the sassy ones (-: ) ?
Check your Antivirus settings This could be causing trouble for you. So go to your antivirus settings and find the SSL protocols option. Enable all SSL protocols and restart your system. See if the problem persists.
Open your Google Chrome and type chrome://flags into the address bar and hit Enter. Step 2. Find Allow invalid certificates for resources loaded from localhost and enable this option.
Your problem is that Internet Explorer on Windows XP (and probably other software as well) is not SNI capable.
I've just ran into the same problem - basically Firefox and Chrome are ok and get the correct certificate, but Internet Explorer does not. Then I've looked it up a bit and saw this on Wikipedia, among other things:
Browsers with support for TLS server name indication [7] Internet Explorer 7 or later, on Windows Vista or higher. Does not work on Windows XP, even Internet Explorer 8.
So, your apache/openSSL combo is SNI capable and can do this, but Windows XP is not.
My solution is that I'm putting the primary subdomain first in the VirtualHost configuration, and the secondary less. At least there is less explanation to clients on why this pops up. I don't know if it would work for you though.
Firefox supports running SSL over the same port,443 (using the same IP) to two virtual hosts (in Apache), but IE7 does not.
http://www.eggheadcafe.com/software/aspnet/36069240/sni-support.aspx
====
http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#vhosts2
Why is it not possible to use Name-Based Virtual Hosting to identify different SSL virtual hosts? Name-Based Virtual Hosting is a very popular method of identifying different virtual hosts. It allows you to use the same IP address and the same port number for many different sites. When people move on to SSL, it seems natural to assume that the same method can be used to have lots of different SSL virtual hosts on the same server.
It comes as rather a shock to learn that it is impossible.
The reason is that the SSL protocol is a separate layer which encapsulates the HTTP protocol. So the SSL session is a separate transaction, that takes place before the HTTP session has begun. The server receives an SSL request on IP address X and port Y (usually 443). Since the SSL request does not contain any Host: field, the server has no way to decide which SSL virtual host to use. Usually, it will just use the first one it finds, which matches the port and IP address specified.
You can, of course, use Name-Based Virtual Hosting to identify many non-SSL virtual hosts (all on port 80, for example) and then have a single SSL virtual host (on port 443). But if you do this, you must make sure to put the non-SSL port number on the NameVirtualHost directive, e.g.
NameVirtualHost 192.168.1.1:80 Other workaround solutions include:
Using separate IP addresses for different SSL hosts. Using different port numbers for different SSL hosts.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With