27
2
Do any web browsers cache SSL server certificates? For example, if I change the SSL certificate on a web server, will all of the web browsers pick up the new certificate when they connect via SSL, or is it possible that they could have a stale certificate?
I'm thinking of the scenario when an SSL certificate expires and is replaced by a new one on the web server.
Lorin Hochstein
Posted 2012-02-16T14:10:27.957
Reputation: 3 037
11
Well, the answer by RedGrittyBrick is correct, but not really answering the question. The question was, if browsers do it, not if they should or need to do it.
From what I've heard, both MSIE and Chrome actually do cache certificates, and don't replace them when they get a new version as long as the old one is valid. Why they do this is not for me to understand, as it lowers security.
tuexss
Posted 2012-02-16T14:10:27.957
Reputation: 156
The currently accepted answer is pretty clear. It specifically indicates that, no, browsers do not cache the certificates. As you point out the landscape changed, the reasons Chrome does, is well documented would be nice for you to link to those reasons. Since the certificate is still valid it doesn't "lower" the security that wouldn't make sense. – Ramhound – 2015-02-05T12:05:40.323
3It does lower it, because you can't replace an old SHA-1 key with a newer one, because the old one still is valid, and Chrome ignores the new one, if I understood everything right. So there's no way of enforcing a switch to higher security standard - so it "lowers" in a relative sense by not enabling to push it higher. Just like inflation doesn't lower your money designated value, but its actual market value. – tuexss – 2015-02-06T18:46:49.727
5
+1 After the StartSSL mixed SHA1/SHA2 chain fiasco, it is clear that Chrome on Windows is indeed caching intermediate certs, possibly indefinitely. Chrome will ignore any new intermediate cert sent by the server. It is not clear though whether caching is keyed by server cert's identity or intermediate cert's identity and what exactly constitutes that identity.
– Robert Važan – 2015-07-05T08:37:57.0373hit the issue today, both chrome and firefox shows different certificates in normal window (old certificate) and incognito mode (correct one). Command line utilities like curl or openssl reports correct certificate of course. Fixed by clearing browser's cache (ctrl+shift+del) - "cookies and other site data" for chrome and "offline website data" for firefox. – anilech – 2017-10-23T09:42:01.117
1At least current version of Firefox (66.0) on OSX seems to hold on to it's cache pretty strongly. Yesterday I've updated a TLS certificate for my website and both CLI openssl and Chromium shows me the new certificate. Firefox shows me the old one despite reload with cache disabled, clearing all the cache and offline data and a browser restart. – Tad Lispy – 2019-03-24T06:36:09.993
You'd probably need to go to the keychain and remove it manually from the certificates. – tuexss – 2019-06-12T09:04:19.143
20
No. See IBM SSL overview
The SSL client sends a "client hello" message that lists cryptographic information such as the SSL version and, in the client's order of preference, the CipherSuites supported by the client. The message also contains a random byte string that is used in subsequent computations. The SSL protocol allows for the "client hello" to include the data compression methods supported by the client, but current SSL implementations do not usually include this provision.
The SSL server responds with a "server hello" message that contains the CipherSuite chosen by the server from the list provided by the SSL client, the session ID and another random byte string. The SSL server also sends its digital certificate. If the server requires a digital certificate for client authentication, the server sends a "client certificate request" that includes a list of the types of certificates supported and the Distinguished Names of acceptable Certification Authorities (CAs).
The SSL client verifies the digital signature on the SSL server's digital certificate and checks that the CipherSuite chosen by the server is acceptable.
…
Microsoft's summary is similar. The TLS handshake is also similar in this regard.
In step 2 there doesn't appear to be a way for the client to say "don't bother sending a server certificate, I'll use my cache".
Note that there are several types of certificates, client, server and CA. Some of these are cached.
RedGrittyBrick
Posted 2012-02-16T14:10:27.957
Reputation: 70 632
This is not true, and assuming there is no cache because of an overview of how SSL works excludes caching is a pretty bad justification. https://www.youtube.com/watch?v=wMFPe-DwULM
– Evan Carroll – 2019-05-30T15:54:33.037The only cache that could be used is for validity checks, though that is a security trade-off. – Daniel B – 2019-05-30T16:02:46.660
Amended original question to clarify that it's a server certificate. – Lorin Hochstein – 2012-02-16T15:01:19.440
0
I'm not sure if my input will help in any way but here's what I've just experienced: I've got a web site in azure with a custom domain. I tried accessing it with https in chromes before configuring the SSL binding for my domain name. Chrome was telling me that the site is not secured which perfectly makes sense (ERR_CERT_COMMON_NAME_INVALID) But after I uploaded my cert and configured the SSL binding in azure I was still getting the same error. At this stage, when opening a new private browser window (or using another browser) the https was working fine.
But I could never get it to work in my open Chrome session. I tried clear SSL state, same result. It worked after restarting chrome altogether.
I was probably tricked by something but it almost looked like the cert was cached...
Etienne
Posted 2012-02-16T14:10:27.957
Reputation: 139
That error would imply that you accessed the site with a URI that was different from what was in the CN. Did you actually change the URI to access the site in chrome after you setup the binding? – Seth – 2017-04-07T05:30:24.007
nope, only thing I changed at the time was the binding. When I first queried https it was served using the default azure ssl cert but it was still serving me this one after I changed the binding with the correct cert it in Azure. – Etienne – 2017-04-07T06:23:13.183
As you said you configured your domain SSL binding, does that mean you accessed the server using your domain from the get go or not? The error would indicate that there was a difference between the URL you used and the URL the cert was for. That's what I meant. In addition your actual server configuration could matter quite a lot if you think about HSTS and such. – Seth – 2017-04-07T07:02:27.830
I am only reporting what I experienced regarding SSL cert and it looked like Chrome cached it but I am not 100% sure. Thanks – Etienne – 2017-04-09T23:20:10.403
And from my POV there are some ambiguities which I'm trying to clear up to make it a better answer. So did you or did you not use your own URL from the get go? Was there a default SSL cert available for that connection and you exchanged it or did you do the initial SSL setup? – Seth – 2017-04-10T06:02:01.303
1Step 1: published web site to azure. At this stage it has both a default azure URL and default cert.
Step 2: setup custom domain for the web app, now mysite.com correctly points to the site. The SSL cert fo mysite.com is not configured at this stage.
Step 3: At this point, when trying to https the site, I'm getting security error saying the cert doesn't match (and it makes perfect sense)
Step 4: I install the SSL cert for Mysite.com in azure and STILL the security warning pops up from Chrome. It DOES NOT occur in any other browser or if I open a private nav. – Etienne – 2017-04-10T06:12:53.570
1Step 5: I restart Chrome and now (and only now) is my web site served using the correct SSL certificate.
Hence my conclusion is that there was indeed a caching issue of the certificate – Etienne – 2017-04-10T06:17:26.383
-1
There are plans of some browser developers to implement such a chaching system for detecting attacks like the attack on Diginotar in 2011.
But at the moment AFAIK no such system is active in current browsers. Therefore you don't have to think about this situation when updating your server certificate.
Robert
Posted 2012-02-16T14:10:27.957
Reputation: 4 857
1As of 2019 my Chrome 75 is caching SSL certificates – Fabian Thommen – 2019-06-14T10:26:06.920
TLS 1.2 introduced session tickets. This mechanism effectively "caches" the certificate, by not needing to transfer it at all. More info at https://blog.filippo.io/we-need-to-talk-about-session-tickets/
– Jari Turkia – 2020-02-20T20:49:33.720I would assume the browser checks the date on the cert to see if it needs to get a newer one, like it does for everything else but am not sure. – soandos – 2012-02-16T14:23:01.760
Have a look here http://www.imperialviolet.org/2011/05/04/pinning.html about "certificate pinning" and at the HSTS initiative whis is related to the former http://dev.chromium.org/sts
– Shadok – 2012-12-14T15:58:25.637