I am stuck in a situation which I cannot figure out. Here is my issue.
I got an SSL certificate from a trusted authority and installed it in my server. Then, I configured my website to use that certificate in port 443 with an IP address which is unused.
Then, I navigated to my web site to see if it works but I see that IIS gives the wrong certificate for this request. So, the browser blocks the response from being rendered.
I thought that IIS did something wrong while configuring and I checked the certificate mappings with the following command:
netsh http show sslcert
I get the Certificate Hash and run the following command to see if the certificate is the one that I need:
get-item cert:\LocalMachine\My\DC0D3FF5D752CD58FD291C48F30646FD9E0D8AED
It is indeed the one I needed. But, strangely I am still getting the wrong certificate when I navigate the web page.
Can u guide me where else I should look and what might be the cause of this?
Just to follow up on this for others that could not resolve it using the above solution, I had experienced a similar problem whereby the server was delivering the wrong certificate for HTTPS connections to a website with a host header value.
In my case, it turned out to be that the binding was set to receive connections from * instead of the actual server IP address. Modifying the binding to be bound to the IP address resolved the issue.
We had the same issue, a https website presenting a wrong certificate on a Win2012 R2 server with multiple https sites using SNI.
Even when modifying the hosts file and redirecting the hostheader to the IP address used on the website we were still presented a certificate from another site, so no DNS issue here.
As it turned out, the website from which we received the (wrong) certificate had one binding on the same IP with SNI turned off, so this cert was apparently presented as the 'default' certificate.
Checking SNI on this site binding solved the problem on the other site.
It is so ironic that the answer popped up in my stupid head after I submitted this question. DNS Host A record was pointing to wrong IP address and that's why I was getting the wrong cert. Changed the IP address for the DNS Host A record and it is all working now.
So I had a similar situation that I faced with a customer. They had multiple HTTPS sites hosted on IIS in Windows Server 2012 R2. They split things between a redirect site and the https site, so you would see basically an HTTP binding with a lone redirect to the site at https.
What they were experiencing was only one of their sites working, and all the other sites were failing with (Error code: ssl_error_bad_cert_domain). Started down a rabbit-hole looking at the certs, all valid, turns out in the redirect for the working site, they had an https redirect as well, this was causing the issue. Once the lone https redirect was removed from their http redirect site all sites started working again.
So, if you have redirects it may be worth checking to make sure they do what you want them to do.
Why?
"Since all of the HTTPS sites are using an * for the IP in the SSL cert bindings and the customer added an SSL binding that had a specific IP mapped to the redirect site, it seems that IIS decided to pass all HTTPS traffic to that redirect site since it had a specified IP address and the others didn't." - JT Shoupe
I encountered a similar issue and the troubleshooting steps listed by the questioner helped me track down the problem.
In my case, I was getting the correct certificate when I browsed to the site from a remote machine, but was getting an old expired certificate when I browsed to the site from the server itself.
When I ran the
netsh http show sslcertcommand, it showed that the correct certificate mapped to the IPv4 interface (0.0.0.0:443), and the old expired one mapped for the IPv6 interface ([::]:443). I rannetsh http delete [::]:443and that resolved the issue.