How do I determine where an SSL certificate is being served from?
I am having the same issue described in this question: IIS 7 Still Serving old SSL Certificate
I have replaced an old SSL certificate with a new one and completely removed the old certificate from the server.
The poster above solved his issue when he realised that there was an ISA server between his web server and the Internet so he cleared the old certificate from the ISA cache and the problem was solved.
I have seen the same solution elsewhere: http://forums.iis.net/t/1182296.aspx
Unfortunately I am having trouble proving to my ISP that the issue is not on my server and that they are caching the old cert somewhere in their infrastructure.
I am 99.999% certain that the certificate installation and bindings are correct on IIS:
- I have configured 2 bindings for the site with different alternate ports 9443 and 8443.
- The old certificate was previously bound to the site on port 9443, both bindings now use the new certificate
- I have configured the etc/hosts file to point the bound domain to 127.0.0.1 so when I open a browser to the domain the requests are all local
- If I visit the 2 URLs from another machine (i.e. via the Web) I get served the old cert on port 9443 and the new cert on port 8443
- If I visit the 2 URLs from a browser on the web server I get served the new cert on both ports
I am 99.999% certain that the certificate is not cached on the client side:
- I have hit the site from multiple browsers on both PC and mobile devices
- I have hit the site over multiple connections, including my corporate LAN, home DSL and a mobile
My next step is to do something like a trace route of the TLS session establishment to figure out where the old certificate is being served from so I can prove to my ISP that this is something they need to solve.
Is this possible, what tools are available for this?
I do not think that your ISP is caching anything in this regards, here are the reasons:
- To serve YOUR certificate with YOUR thumbprint, they need to have access to YOUR private key
- ISP's usually do not cache SSL traffic
- ISP's escpecially do not cache SSL traffic on non-standard ports
So this seems to be an issue with your own server. Try rebooting it, try tracerouting it, try the suggestions from the comments like @MadHatter's:
echo ""|openssl s_client -connect 127.0.0.1:9443 |openssl x509 -text -noout|&grep depth=0
Also, if you use SNI or stuff like that, make sure that the Default non-SNI Website in IIS has the correct certificate bound, as this is served to at least non-SNI clients, and I have seen problems when they did not match where there shouldn't have been problems.