As you probably know SSL certificates use the https protocol to encrypt communication between your web browser and the web server hosting the web site you’re visiting. You can always tell when your session has been encrypted because your browser will display a lock icon near the address of the site in the browser’s location bar. If your web site doesn’t already have an SSL certificate you really need to get one. Certain web browsers have already started identifying sites without SSL as “not secure” even if there’s no ecommerce function or data transfer and Google also announced they would lower a site’s search rankings if it didn’t feature SSL again regardless of the site’s function.
So as every good sys admin should do I have deployed SSL certificates for all my sites. Recently I installed a new SSL certificate for my blog but upon testing it afterwards to ensure everything was working properly I was presented with the unsettling error message below indicating Warning: Potential Security Risk Ahead. Clearly something was amiss.
SSL_ERROR_BAD_CERT_DOMAIN
When viewing the advanced details of the error displayed below I saw the error code SSL_ERROR_BAD_CERT_DOMAIN. Naturally I was surprised to see this error because I knew my certificate had just been issued and wasn’t expired or using an old hashing algorithm etc. Upon closer inspection I could see the error was indicating the certificate was only valid for a different domain name which was not the domain of my site. This was a little confusing because I had just installed the new certificate and knew with complete certainty that it was registered in the name of my domain not the domain identified in the error message. The other domain name in question was also hosted on my server so this was a good clue to check site bindings.
Managing IIS Server Certificates
The next step was to double check the installed certificates. Using IIS Manager you can easily find and manage all of the certificates installed on the server. This is handy when you need to quickly identify expiration dates for example but to see how the certificates are assigned you will need to check the individual site bindings.
One other way to see all the SSL certificate bindings is to run the following command:
|
1 |
netsh http show sslcert |
This will output advanced details about all of the certificates installed on the server including the hostname:port and certificate store where the certificate is located.
IIS Server Name Indication (SNI)
The server hosting my site uses Windows Server 2012 R2 with IIS 8.5 which has a powerful feature for hosting SSL certificates called Server Name Indication (SNI). SNI allows multiple SSL certificates using different domain names to leverage a single dedicated IP address. Before IIS 8 this could only be accomplished with a wild card certificate. So after reviewing the SSL_ERROR_BAD_CERT_DOMAIN error message I knew the issue had to be related to an incorrect IIS site binding related to SNI config. As you can see in the picture below the SNI feature needs to be enabled by checking the box Require Server Name Indication. My site was sharing the same IP address as another site featuring a different SSL certificate and in my haste to install the new certificate I had not checked the Require Server Name Indication box. Once I did that and saved the settings my site was operational again without the security warning.
In Summary
Starting with IIS 8 scaling SSL certificates has never been easier thanks to Server Name Indication (SNI). The caveat with this increased scalability is that you have to ensure your site https bindings are always set properly by checking the Require Server Name Indication box on the https binding. If not set properly your site visitors will be greeted by the Potential Security Risk warning related to the SSL_ERROR_BAD_CERT_DOMAIN error. Thanks for reading!
