Ssl – Same Domain with Two Different SSL Situations

In this case you would need separate ports if they were on the same IP, or separate IPs if you wanted them on the same standard SSL port (443). IIS doesn't support reading host headers and redirecting using SSL. You can use the same wildcard certificate without any issue, but you would need something inbetween IIS and the client (like Microsoft Forefront Threat Management Gateway) in order to do routing by hostname over SSL. (I hope that makes sense)

The reason this happens is because the connection is encrypted and the certificate is validated before the HTTP header is actually sent, so at that time IIS has to know what site it's using beforehand. Now, Firefox does send the hostname in with the initial encryption request but I'm not sure if IIS supports that (or if any other browsers do).

The First Few Milliseconds of a HTTPS Connection has an incredibly in depth description on how HTTPS generally works (through a special debug build of Firefox). As you can see a few paragraphs in TLS supports a server name extension, but as far as I know IIS does not support that extension.

When adding Subject Alternative names to a certificate, the same rules as the Common Name apply. The full domain name being used must exactly one of them.

In your case, you're using the domain www.completelydifferent.com but the single SAN is only given as completelydifferent.com. This isn't close enough and will cause the browser warning you've seen. What confuses the matter is that the browser awrnings (I think this is the same for all browsers) will show the CN of the certificate in the warning and not the SANs, so it gives the impression that the SAN isn't being read correctly.

Also useful: openssl is a command-line interface the the openssl library functions, and can be used to verify the certificate: openssl x509 -in <cert file> -text will show you the full text of the certificate file. (Some certificates include this text in the file)