Adding a Hostname to your SSL certificate binding on port 443

I see a lot of articles and posts about being able to bind different websites on the same server to port 443.  This article is my take on the subject.

It is possible to bind multiple websites hosted on the same server to port 443, but you can’t easily do it from the GUI because the Host name is greyed out as shown in Figure 1.  However, if the SSL Certificate begins with a *, then it is enabled.  This is likely to support wild card certificates as shown in Figure 2.

The confusion comes when you attempt to bind different SSL certificates to the different website both of which want to use port 443.  That won’t work.

Figure 1, Host name is greyed out

I tried a hack just to test by binding SSL certificate 1 to port 443 and SSL certificate 2 to 444 from within the GUI.  Then using appcmd I modified the bindings for the 2 websites so that they both used port 443 and had a different host name.

The result of this was that the certificate originally bound to port 444, SSL certificate 2, was changed to use SSL certificate 1.  Meaning, the different SSL certificates being bound to port 443 where being forced to use a single SSL certificate.  The SSL certificate on port 444 was being replaced with the one bound to 443.

This means that you can only have 1 SSL certificate per IP:PORT combination.

Figure 2, Host name is not greyed out when * exists

Another way to view this requirement is using the following netsh command:

netsh http show sslcert

The result will show you the IP:PORT combination settings for the installed SSL certificate.  The reason this combination is required is due to the sequence of events that happen during the handshake.  A pseudo example:

  1. CLIENT – resolve URL to IP and PORT
  2. CLIENT – connects to IP and PORT
  3. SERVER – Answers from that IP and PORT
  4. CLIENT – Asks for SSL certificate
  5. SERVER – Sends SSL certificate
  6. CLIENT – Compares SSL certificate name from server to name from step 1
  7. CLIENT – Assuming they match, begin encrypted exchange
  8. CLIENT – Send encrypted information to server
  9. SERVER – Sends encrypted information back to client

The reason that the IP and PORT combination is so important is because the server must know which certificate to return to the client in step 5.  The server does not know the hostname until step 8.  This is why IIS is setting the SSL certificate back to the original one bound to port 443 when it is attempted to bind it to an IP:PORT:Hostname combination.

Note that you can make some changes in the applicationHost.config file directly, however you will not be able to bind different SSL certificates to an IP:PORT:Hostname, where IP:PORT are the same.  You can bind the same SSL certificate to *:443:Hostname.


IIS 8 introduces a new concept called SNI (Server Name Indication).  Check it out.

Comments (5)

  1. Anonymous says:

    Great post. Thanks for sharing.

    Just some more explanation from me on certificate starting with * in second para.

    That * doesn't mean that is wild card certificate necessarily.

    In IIS7 (on Windows 2008 R2), I saw missing hostname under 'Edit Site Binding' [your first screenshot]. That was the first SSL 443 website on that IIS server. The website was and I used internal certificate server to issue the certificate for that internal Dev / Test site.

    1. I resolved the missing Hostname by opening the MMC console on the server and adding Certificate MMC for Computer
    2. Expand Personal node under Certificates (Local Computer) on server

    3. Right click on the certificate in the list and choose properties

    4. Under General tab, change the 'Friendly Name' from to * and click OK

    5. Go to IIS Binding for the website and you should be able to add Hostname and pick the * certificate.

    6. Verify the website and you will see certificate in browser with the FQDN /


    Faisal Masood


    MCSE, MOS: SharePoint 2013

    MCITP, MCTS: SharePoint 2010

    MCSA: Office 365

    MS: MS Project 2013

    MS: Azure

    SharePoint, Office 365, Azure, ProjectServer EPM Consultant

  2. PK says:

    Hi Faisal,

    Thanks for the wonderful input.

    Worked like charm.

  3. Sciclops says:

    Very Nice Faisal.  It resolved our issue. Tank you!!!

  4. BlueSky2010 says:

    Handy trick, give the cert a friendly name starting with '*' an IIS won't gray out the host-header box:

    Hope this helps someone!

  5. Grateful says:

    Thanks for much for the '*' in the friendly name tip – it solved my issue, appreciate it.