I installed a new SSL certificate into IIS7, removed the old certificate and setup the bindings for the new certificate – so https is now bound to the new certificate only.
I restarted IIS7 (and the Windows 2008 Server itself) and checked the certificate using the commands:
netsh http show sslcert
This showed the new certificate only, as I expected
certutil -store MY
This also only showed the new certificate and not the old one, as I expected
I also opened mmc and checked the certificates there and I only see the new one and not the old one.
I'm also using an account with Administrator privileges.
However — when I open a browser (from any computer) and go to the https site it is still using the old certificate. Even when I remove the old certificate from the browser it still gets sent the old one and not the new one.
Can anyone help me work out where I'm going wrong? How can I exorcize the old phantom certificate?
Best Answer
First a couple points that are probably the same for you
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:
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:
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
.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:
Now we've verified this is the 'bad' thumbprint, and expected single record we can delete it with this command:
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 :-)