The incorrect localhost certificate is being served by IIS

Question

OK I have a SSL issue that I can't seem to get past on this 1 Win7 x64 machine. I have been using self-signed certs for years and even blogged about them before so I have experience. However something is happening that I can't figure out this time.

I have (2) localhost SSL certs created and insalled on my machine.

1. localhost (friendly name) issued and created in IIS (7.5). It contains the 'Issued To' and 'Issued By' values of my machine name: 'DevMachine123'. This is the certificate being served up for applications configured under the 'Default Web Site' in IIS.
2. localhost SSL certificate created using makecert.exe tool where CN=localhost (common name) was used. It contains the 'Issued To' and 'Issued By' values of 'localhost'. This is the SSL cert I want served up in IIS for my applications configured under the 'Default Web Site'.

The error I'm getting is:

'The security certificate presented by this website was issued for a different website's address.'

When I view the certificate being served up from the IE browser: it shows the localhost cert issued to 'DevMachine123' is being used and not the localhost issued to localhost (#2 above) which should resolve this issue. Hence the name mismatch because 'DevMachine123' does not match 'localhost'.

Another point to make; my certificates have been added to 'Trusted Root Certification Authorities' so they both are trusted certificates.

Last point to make, I checked the https port 443 Binding configuration for the 'Default Web Site' on my machine in IIS. I view the certificate and it shows the correct localhost certificate is bound (#2 above with CN=localhost).

I feel that I have covered my bases here (yes I have seen this and this so please do not re-post). What am I missing here?

Thanks!

Answer 1

Verify you have only one site set per binding in IIS as well.

If the Default site and a separate one are installed, they may both have an HTTPS binding on the same port. If this happens, the cert served may be the one from the other site.

Answer 2

Very similar answer to @IsolatedStorage but with some more details of what helped me.

First a couple points that are probably the same for you

• I was trying to update a certificate because it has expired.
• I have multiple domains bound to the same IP. They happen to be a SAN certificate but that's probably irrelevant.
• I was trying to use the centralized certificate store. Again I think this is irrelevant to most of my answer.
• I had already attempted to update the certificate but it wasn't showing the new date.
• You're probably in a panic right now if your old certificate already expired. Take a deep breath...

First I'd recommend strongly going to https://www.digicert.com/help/ and downloading their DigiCert tool. You can also use it online.

Enter in your website https://example.com and it will show you the expiration date and thumbprint (what MS calls the certificate hash). It does a realtime lookup so you don't have to worry whether or not your browser (or intermediate server) is caching something.

If you're using the centralized certificate store you'll want to be 100% sure the .pfx file is the latest version so go to your store directory and run this command:

C:\WEBSITES\SSL> certutil -dump www.example.com.pfx

This will show you the expiration date and hash/thumbprint. Obviously if this expiration date is wrong you probaly just exported the wrong certifcate to the filesystem so go and fix that first.

If you are using the CCS then assuming this certutil command gives you the expected expiration date (of your updated certificate) you can proceed.

Run the command:

netsh http show sslcert > c:\temp\certlog.txt
notepad c:\temp\certlog.txt

You likely have a lot of stuff in here so it's easier to open it up in a text editor.

You'll want to search this file for the WRONG hash that you got from digicert.com (or the thumbprint you got fromChrome).

For me this yielded the following. You'll see it is bound to an IP and not my expected domain name. This is the problem. It seems that this (for whatever reason I'm not sure) takes precedence over the binding set in IIS that I just updated for example.com.

IP:port                      : 10.0.0.1:443
Certificate Hash             : d4a17e3b57e48c1166f18394a819edf770459ac8
Application ID               : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name       : My
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check                  : Enabled
Revocation Freshness Time    : 0
URL Retrieval Timeout        : 0
Ctl Identifier               : (null)
Ctl Store Name               : (null)
DS Mapper Usage              : Disabled
Negotiate Client Certificate : Disabled

I don't even know where this binding came from - I don't even have any SSL bindings on my default site but this server is a few years old and I think something just got corrupted and stuck.

So you'll want to delete it.

To be on the safe side you'll want to run the following comand first to be sure you're only deleting this one item:

C:\Windows\system32>netsh http show sslcert ipport=10.0.0.1:443

SSL Certificate bindings:
-------------------------

IP:port                      : 10.0.0.1:443
Certificate Hash             : d4a17e3b57e48c1166f18394a819edf770459ac8
Application ID               : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name       : My
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check                  : Enabled
Revocation Freshness Time    : 0
URL Retrieval Timeout        : 0
Ctl Identifier               : (null)
Ctl Store Name               : (null)
DS Mapper Usage              : Disabled
Negotiate Client Certificate : Disabled

Now we've verified this is the 'bad' thumbprint, and expected single record we can delete it with this command:

C:\Windows\system32>netsh http delete sslcert ipport=10.0.0.1:443

SSL Certificate successfully deleted

Hopefully if you now go back to Digicert and re-run the command it will give you the expected certificate thumbprint. You should check all SAN names if you have any just to be sure.

Probably want to IISRESET here to be sure no surprises later.

Final note: If you're using the centralized certificate store and you're seeing erratic behavior trying to even determine if it is picking up your certificate from there or not don't worry - it's not your fault. It seems to sometimes pick up new files immediately, but cache old ones. Opening and resaving the SSL binding after making any kind of change seems to reset it but not 100% of the time.

Good luck :-)

Answer 3

Same symptoms

Changed HTTPS binding in the drop down list to the server IP (in the site bindings dialog). It was set to "all unassigned" Got a warning about overwriting an existing certificate / IP combination, which I accepted, and and issue resolved.

Answer 4

I had a similar issue and had also gone through the checks you mentioned above for the site bindings. I ran the following netsh command

netsh http show sslcert

This showed me two SSL Certificate bindings. One on IP:Port 0.0.0.0:443 with the correct certificate and one on IP:Port [::]:443 with an expired certificate. I opened CertMgr.msc for the Local Computer (see here for instructions) and searched for the invalid certificate and discovered it had expired.

To resolve the issue I did the following

1. netsh http delete sslcert ipport=[::]:443
2. iisreset /restart