3

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

enter image description here

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

enter image description here

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:

enter image description here enter image description here

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
3

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.

  • Then how does one quickly debug issues over HTTPS? The server will not expose details of errors to non-localhost connections as it's a security concern, but I can't talk to it as localhost. Swapping to a self-signed certificate for debugging purposes seems like it would work, but I'd like to be able to debug a production environment without making it unavailable to the public. – Sean Anderson Nov 2 '14 at 22:48
  • Fiddler is a great tool for debugging web traffic over HTTPS. – Ryan Ries Nov 2 '14 at 22:49
  • Sure. I have Fiddler and I'm familiar with it. What I mean is.. lets say my server encounters an error when talking to the database. The server would include details about the issue it encountered in the body of its response, but omits those details when not talking over localhost. I will need to dig through error logs on my server, or take my application out of production, change to a self-signed, localhost certificate and then reproduce the error. I don't understand why it is a security concern to allow my server to talk to itself over HTTPS... – Sean Anderson Nov 2 '14 at 22:54
  • You can also just click that link "Proceed to 127.0.0.1" [unsafe]" and it will take you to the website just like normal. Just because the SSL certificate isn't valid doesn't actually prevent it from technically still working. Your web browser is just trying to warn you that something fishy could be happening if you thought you were connecting to a legit web service. – Ryan Ries Nov 2 '14 at 22:55
  • I am able to do that when issuing a request through the browser, but the screenshot below that shows a POST request failing which has no response attached because the response is insecure. This might be more of a programming issue at that point, though, so I'll do some more digging. Thanks for your time. – Sean Anderson Nov 2 '14 at 22:58
0

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!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.