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:”
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.
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.
Nice post. I’ve run into this in the past, and your blog here would have saved me some heartache on a definite id10t error.\r\n\r\n:) Thanks!
Nicely explained post and a thank you very much!
Thanks, found myself in this situation. Your info save my head.
Thank you so much! I was about to go insane trying to figure out why I would have paid extra for a wildcard certificate if I could only use it on one site.
Thanks Peter! Have seen this tip before, but didn’t book mark it. This tip saves a lot of hassle 🙂