Do web browsers cache SSL certificates?

Question

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.

I 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, Feb 16 '12 at 14:23
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, Dec 14 '12 at 15:58
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, Feb 20 '20 at 20:49

score 18 · Accepted Answer · answered Feb 05 '15 at 11:42

18

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.

answered Feb 05 '15 at 11:42

tuexss

318
2
5

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 Feb 05 '15 at 12:05
3

It 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 Feb 06 '15 at 18:46
5

+1 After the [StartSSL mixed SHA1/SHA2 chain fiasco](https://forum.startcom.org/viewtopic.php?f=15&t=15929&start=0&st=0&sk=t&sd=a&sid=c5cc5782c93461824941c200e141b5f8&view=print), 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 Jul 05 '15 at 08:37
3

hit 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 Oct 23 '17 at 09:42
1

At 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 Mar 24 '19 at 06:36
You'd probably need to go to the keychain and remove it manually from the certificates. – tuexss Jun 12 '19 at 09:04

score 0 · Answer 2 · answered Apr 07 '17 at 05:25

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...

answered Apr 07 '17 at 05:25

Etienne

139
4

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 Apr 07 '17 at 05:30
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 Apr 07 '17 at 06:23
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 Apr 07 '17 at 07:02
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 Apr 09 '17 at 23:20
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 Apr 10 '17 at 06:02
1

Step 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 Apr 10 '17 at 06:12
1

Step 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 Apr 10 '17 at 06:17

score -1 · Answer 3 · answered Feb 16 '12 at 15:28

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.

Do web browsers cache SSL certificates?

3 Answers3