SSL | Peter Viola

IIS 8.5 SNI – Fixing SSL_ERROR_BAD_CERT_DOMAIN

IIS, Windows Server 2012 Comments Off

Jun 022019

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:

netsh http show sslcert

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!

Peter Viola

Creative, customer focused, results oriented, Senior Web Systems Engineer who enjoys providing the highest level of customer service supporting complex Windows hosting solutions. MCITP, MCSA, MCTS

More Posts - Website

Securing SmarterMail with SSL / TLS

Email Comments Off

Jul 152017

SmarterMail from Smatertools.com is a fantastic enterprise class Windows based mail server. One of the most compelling reasons to try Smatermail is that they offer a full featured version free for one domain. Leveraging SSL/TLS protocols with SmarterMail allows mail communication to be encrypted increasing privacy and security.

Export SSL Certificate to PFX File

Before making changes to Smartermail you will need to export the SSL certificate you intend to use to a PFX file that is password protected and contains the private key of the certificate. Smartertools recommends copying the file to C:\smartertools\certificates.

Open Microsoft Management Console (MMC)
Select Add new Snap-In and then select Certificates
Expand the Personal certificate store and then select the certificate you want to export
Right click on the certificate and select Export
Select PKCS #12 (PFX) and click Next to save the file

Configure SmarterMail SSL/TLS Ports

After logging into SmarterMail using an administrator account, go to the Settings menu and then click on Bindings and then Ports. From this page you will see the currently configured Ports SmarterMail is using and whether or not they are using SSL and TLS.

From the Ports men select New to add each additional port you intend to configure with SSL. In the example below I’m configuring SSL to be used with the SMTP Protocol on Port 465. Enter the certificate path to the PFX file that was exported in the previous steps. After entering the password click the Verify Certificate button to validate the path and certificate password are correct. When the certificate verification has successfully completed a notification will be displayed across the pop-up window. Click Save and the repeat the steps for any additional ports you intend to configure with SSL.

Configure SSL/TLS IP Address Bindings

Again from the SmarterMail Settings menu click on Bindings and then IP Addresses. From the list of configured IP Addresses select the one that is used by the mail server services and then click Edit. Select the new SSL/TLS ports that you added in the previous step that will be used and then click Save.

Open Firewall Ports for SSL/TLS

Be sure to open the new ports on your firewall appliance. In the example below I’m opening the additional SMTP ports using the local Windows Firewall on my server. The following ports can used for SSL/TLS.

25 (TLS), 110 (TLS), 143 (TLS)
465 (SSL), 993 (SSL), 995 (SSL)

Configure Mail Client for SSL/TLS

Once you have confirmed the new ports have been added to SmarterMail and the Firewall Ports are open you just need to configure your mail client to use the new settings.

The Incoming Server (POP3) settings should use port 995.

The Outgoing Server (SMTP) settings should use port 465.

In Summary

SmarterMail is an enterprise class mail server that allows securing your mail communication using SSL/TLS for greater privacy and security. Thanks for reading.

Peter Viola

Creative, customer focused, results oriented, Senior Web Systems Engineer who enjoys providing the highest level of customer service supporting complex Windows hosting solutions. MCITP, MCSA, MCTS

More Posts - Website

Scaling SSL With IIS 8 Server Name Indication (SNI)

IIS, Windows Server 2012 1 Response »

Jun 302014

One of the many great new features with IIS 8 on Windows Server 2012 is Server Name Indication (SNI). SNI is a TLS extension that includes the hostname or virtual domain name during SSL negotiation. The reasoning behind this was to improve SSL scalability and minimize the need for dedicated IP addresses due to IPv4 scarcity. This means that you can now host multiple SSL certificates on a web server only 1 IP address. With previous versions of IIS you were forced to bind SSL certificates with unique IP addresses and the only workaround available for hosting multiple SSL certificates with 1 IP address was to use a wild card certificate. In this walkthrough I will show how to leverage hosting multiple certificates using SNI.\r\n

Web Hosting Certificate Store

\r\nA new certificate store was created for Windows Server 2012 called the Web Hosting store. It is similar to the Personal store however it has been designed to support a significantly higher number of certificates with only a minimal performance impact on the server. On Windows Server 2012 certificates are now loaded on-demand in memory. Previously on older versions of Windows Server all certificates on a server would be loaded from just one GET request. The end result of this was high memory usage and limited scalability.\r\n\r\n\r\n\r\n \r\n

Hosting Multiple Sites Using 1 IP Address

\r\nOn my test server I have 3 sites configured using host headers and 1 IP address.\r\n\r\n\r\n\r\n \r\n\r\nI have already imported 3 SSL certificates and you can see they are in the Web Hosting certificate store. Installing the certificates is straight forward but I am not going to cover that in this blog post. However, if you need help with installing certificates then here are the steps to follow.\r\n\r\n\r\n\r\n \r\n

Enabling Server Name Indication

\r\nServer Name Indication (SNI) is enabled on the site binding properties by clicking the Require Server Name Indication checkbox. Click OK to save the settings and then close the Site Bindings window.\r\n\r\n\r\n\r\n \r\n\r\nNow I have added an SSL certificate for each site and enabled Server Name Indication each site’s SSL binding. The certificates have been correctly added to the Web Hosting store to ensure scalability. Looking at IIS Manager below we can see that the https binding of each site is sharing same IP address. With previous version of IIS this would not have been possible because the other 2 sites would have automatically been stopped.\r\n\r\n \r\n\r\n\r\n\r\n \r\n\r\nUsing an elevated command window you can see the new SSL binding type by running the following command:\r\n

<strong><span style="font-family: Calibri;">netsh http show sslcert</span></strong>

1	<strong><span style="font-family: Calibri;">netsh http show sslcert</span></strong>

\r\nThe picture below shows the SSL bindings for the 3 sites and the hostname is now included with port 443. Running this command on Windows Server 2008 you would only see the IP address and 443.\r\n\r\n\r\n\r\n \r\n

In Summary

\r\nWindows Server 2012 and IIS 8 offer many new features and performance improvements for hosting sites. Server Name Indication (SNI) offers impressive SSL scalability with the addition of the Web hosting certificate store. Now you can host multiple unique certificates on multiple sites using only 1 address. Implementing SNI offers greater site density on web servers with only a minimal memory impact. Thanks for Reading.

Peter Viola

Creative, customer focused, results oriented, Senior Web Systems Engineer who enjoys providing the highest level of customer service supporting complex Windows hosting solutions. MCITP, MCSA, MCTS

More Posts - Website

Using Wildcard SSL Certificates on IIS 7

IIS, Windows Server 2008 7 Responses »

Dec 092012

The other day I was helping someone who was trying to configure a wildcard certificate on their Windows Cloud Server. Their server was running Windows 2008 R2 server using IIS 7. The were technically savvy and knew how to configure site’s on their own and install a regular SSL certificate but they were stuck trying to get a wildcard certificate configured properly.

They had quite a few site’s configured using subdomains such as support.domain.com, mail.domain.com, login.domain.com, etc. To tighten security they decided to use SSL to protect all these sites so they bought a wildcard certificate for *.domain.com. They installed the new certificate on the 1st site correctly but when they tried doing it on the 2nd site they couldn’t. IIS wouldn’t let them assign the certificate on the other sites using a shared IP address. Does this sound familiar? Here’s how you can solve it and it’s easier than you think.

Here are 4 site’s configured in IIS using host header xxx.domain.com with the same IP address.

After installing our wildcard SSL certificate we assign the binding on the first site.

Testing the site we see that the wildcard SSL certificate is working great.

Now we go to site #2 and try to assign our certificate. However we’re not able to enter a host name for site #2.

If we click OK and try to proceed we get a warning about the dire consequences of our actions. As soon as we try to access site #2 using SSL, IIS will actually stop site #1 which cause all kinds of issues for our users.

Now that we’ve seen the problem let’s the get to the solution. According to my friend, former coworker, and IIS MVP Scott Forsyth, it turns out that this is not a bug and the IIS team designed it to work this way. There are 2 ways to solve this particular issue when using a wildcard SSL certificate. One way is to simply execute the following app command for each binding that you need.

appcmd set site /site.name:”” /+bindings.
[protocol=’https’,bindingInformation=’:443:‘]

This certainly works however I tend to have hard time remembering the syntax which leads us to the 2nd method which is in my opinion is far easier and has to do with how the wildcard SSL certificate was originally installed.

Remember back when you had just received the completed wildcard certificate from your SSL vendor? Like most IT people you were probably in a hurry when you installed it. Do you remember what you entered when you were prompted for a Friendly name before saving it? Chances are you just entered “domain.com” however what you should have specified is “*.domain.com”. Doh!

You can check this easily by looking at the certificate store in IIS Manager. If the Name column doesn’t show the * then you need to change it before it SSL binding on multiple sites will work properly.

So how does one change the Friendly name this after the certificate has already been installed? Open the MMC Snap-In for Certificates. Right-click on the certificate and change the Friendly name to *.domain.com. Save the changes and close out the MMC.

Now that the Friendly name has been changed to *.domain.com go back to IIS and try to add the SSL binding for site number #2 and now it works. Woohoo. Smile

Now you can add your wildcard certificate to as many subdomain host header sites as needed using only 1 IP and you don’t have to remember any programming syntax. I hope this helps and thanks for reading.

Peter Viola

Creative, customer focused, results oriented, Senior Web Systems Engineer who enjoys providing the highest level of customer service supporting complex Windows hosting solutions. MCITP, MCSA, MCTS

More Posts - Website