There are some articles that explain the need for a wildcard certificate, but not so many which discuss the steps to properly set this up in IIS 7 which was why I decided to write this article as it is a common situation we see here on the support team.
Imagine the following scenario. We have multiple sites (for example let us say site1.marei.com, site2.marei.com and site3.marei.com) which are bound to the same IP:PORT and are distinguished by their different host headers. We have an SSL requirement for each and have requested and installed a unique certificate for each. Now upon browsing to the sites, users will see certificate mismatch errors.
Why is this happening?
Well, we need to realize that an https request is handled through Kernel on IIS7 first. What happens is that the host name is encrypted when the client sends the SSL blob. Because the sites are using the same IP:PORT, IIS requires the host name as it is part of the binding to look up the correct certificate. However since the hostname is encrypted in the SSL blob, IIS is not able to look up the correct site as the binding is incomplete. In the end this means that IIS cannot decrypt the hostname which in turn will cause it bind to the first IP:PORT and will ignore the hostname giving certificate mismatch errors on the other sites.
What are the solutions?
There are three solutions to this issue:
1) We can keep the same IP for each site but change the SSL port to a unique value. This is not a very practical solution as users would now have to enter the port into the request as follows.
2) A second option is to keep all sites on the default SSL 443 port and give each a unique IP. This is another option and is definitely more practical than the first. But what about the situation where there is a limitation on the number of available IPs or then why even use host headers?
3) The third option would be to use a wildcard certificate. Here you will have the wildcard certificate issued to *.domain.com or from our example, *.marei.com. So long as the domain remains the same, any host header will satisfy the certificate requirements and you will no longer receive those pesky certificate mismatch errors. Here are the steps to set this up.
Setting up a Wildcard Certificate in IIS 7:
We will start from where the wildcard certificate has been successfully installed.
1) In IIS manager, setup the 443 binding to site1.marei.com as with the host name as in the following example.
2) Open command prompt with administrator privileges and goto %systemdrive%\Windows\System32\inetsrv
Here we will use appcmd to create the bindings for the other sites. You will know it was successful if you see “SITE object changed” after running the command. The command syntax is as follows:
appcmd set site /site.name:”<IISSiteName>” /+bindings.[protocol=’https’,bindingInformation=’<IP>:443:<hostHeaderValue>‘]
Please see the following screenshot for reference.
3) Now in IIS you can view the bindings but please note, you can not make any changes or else the binding settings will be reset. Any changes will need to be made via appcmd we used in step 2.
4) Now you can test the sites verifying we are using https:// and you can see there are no longer any certificate errors on any of the sites. I will show a screenshot of site2 for reference.