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.
Background:
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.
https://site.domain.com:444
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.
Background:
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.
https://site.domain.com:444
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.
