SSL on IIS8.5 - Working with named URL, but localhost results in ERR_CERT_COMMON_NAME_INVALID

Question

I have IIS8.5 running on Win Server 2K12 R2. I have a valid SSL certificate registered to server's name foo.domain.com:

I have configured my website's bindings to use https with this certificate:

I am able to talk successfully to the website when talking to https://foo.domain.com, but I am unable to talk successfully when using https://localhost.com or https://127.0.0.1:

What do I need to do to be able to communicate successfully over localhost?

I have tried:

• Creating a self-signed certificate and attempted to use that, but I can't use two certificates for the same website. Using a self-signed for localhost disables my ability to communicate via foo.domain.com

I have not:

• Tried to apply intermediate COMODO certificates manually through mmc.exe certmgr.msc. Since my current setup is working externally, I do not believe this is the issue.
• Modified hosts file to redirect localhost to foo.domain.com

Answer 1

Your SSL cert is only valid for the exact FQDN by which the addressee access the website. The subject of the SSL certificate, and the server FQDN in the URL address bar must match. E.g., it is valid only for foo.domain.com, not foo, not localhost, not 127.0.0.1. This is by design. This is how SSL certificates work.

No self-respecting Certificate Authority will ever issue an SSL certificate for "localhost", because there are a theoretically infinite number of "localhosts" with no way of actually verifying their identity.

Answer 2

As stated by others, SSL certs are only valid for the exact FQDN used. When you created the self-signed certificate in IIS, it provided you with an "issued to" name. If you use this instead of "localhost", the cert should work. For instance, if the machine's name is foo.bar.com, then you can use https://foo.bar.com in the URL instead of https://localhost.

In my case, I was accessing a remote dev server by IP as there wasn't a DNS server that could resolve it by name. I kept getting the error you received. In my case, the machine name was something like foo.bar.local with an IP address of something like 10.1.1.37. When I created my IIS self-signed certificate, it issued it to foo.bar.local. So to make that work, I added an entry to my client machine's hosts file (c:\windows\system32\drivers\ets\hosts) that pointed foo.bar.local to 10.1.1.37 and started using https://foo.bar.local instead of https://10.1.1.37. It started working from that point forward.

Of course, all this assumes you've already installed the certificate into the client machine's trusted root certification authorities.

Hope that helps!

Answer 3

In the binding (IIS 10), you should leave the IP address = All unassigned and check the require Server Name Indication. Then select a Wildcard certificate.