Setting Up A Wildcard Certificate in IIS 7, How to Avoid Those Certificate Mismatch Errors.


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, and 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 * or from our example, * 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 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 /”<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.



See you next time and I hope this was helpful!


Matthew Reid



Comments (14)

  1. George says:

    This would be a great posting if it worked this way. When in IIS manager I don't have the option to provide a Host Name if I change the protocol to HTTPS. It works fine in HTTP but that option to name the Host Name isn't there in HTTPS.

    Any suggestions?

  2. Hi George,

    When you use the wildcard certificate, and it is ready, you will see the Host Header field is available to be configured. General steps are;

    1. Create Certificate request in IIS
    2. Issue it from Certificate authority

    3. Complete the certificate request in IIS installation, the name must be * format

    4. And then Bind this certificate, you will see the same UI as the post shows.


  3. Anonymous says:

    Works for me as in the article.

    Once you select a wildcard certificate (* from the dropdown, the Host Name section will become configurable.  If you select an SSL certificate from the dropdown that is not a wildcard certificate the host name value will correctly not become configurable.

  4. Larry says:

    I'm with George on this – the Host Name is grayed out and does not allow for an entry to be made.

  5. Bradley Uffner says:

    I had the same problem, host name was grayed out and cleared once I selected the certificate.  The cert is definitely a wildcard cert.

    I was able to work around the problem by first creating the binding through the gui without the hostname, then running the command line to add the binding with the hostname.  I then modified the command line slightly to remove the original binding without the hostname.

    I then repeated this for the 2nd site and everything is working correctly.

  6. Lucas says:

    Im with the other, article is useless, the option is greyed out

  7. Al says:

    The wildcard certificate has to have a friendly name that begins with a * or else the Host name field will not become enterable.  E.g. will not work but * will.


  8. Chris Wilkins says:

    What do you do when you don't have a private key on the cert?  It disappears right after you install it.

  9. Derek Greer says:

    Can you explain why it is necessary to use appcmd to add the second and third sites?  Why wouldn't using the binding dialog for each respective site to set the same bindings work?

  10. Derek Greer says:

    Update: For the sake of any others using this as a guide to set up wildcard certs in IIS, I was able to set up my main site and a subdomain site in IIS 7.5 using the binding UI dialog for each site.  Additionally, the appcmd wasn't available form me when I launched a console window.  I'm not sure if it was just a path thing or not.  Once I got an error trying to execute the instructions from the command line I decided to try the UI instead.

    Addtionally, I purchased my wildcard from GoDaddy and we discovered that, while our previous certificate and binding setup for [company].com 443 worked for both http://www.[company].com and [company].com, switching the [company].com binding over to the new certificate only matched for the [company].com.  We had to add an additional record for http://www.[company].com 443 for the https://www.[company].com to resolve.  I'm guessing that the * part of *.[company].com swallows up the www part, so you need an explicit binding for that.  It makes sense, but I thought I'd point it out for anyone reading this afterwards since the article didn't mention it.

  11. Dave Bacher says:

    When importing the certificate, it's important that the friendly name start with a *.  Otherwise IIS does not pick up that it is a wildcard certificate, even if it is.  (You can change the friendly name via mmc)

  12. justin fred says:

    Thanks for share

    This would be a great posting if it worked this way. When in IIS manager I don't have the option to provide a Host Name if I change the protocol to HTTPS


  13. Bernster says:

    I read in another post that in IIS 7.5 the gui will work fine and you don't need to use appcmd. Not true in my case. I still encountered the dreaded reset warning but this post worked like a charm.

Skip to main content