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.


3 Answers 3


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.

  • 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 5, 2015 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 6, 2015 at 18:46
  • 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. Jul 5, 2015 at 8: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, 2017 at 9: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, 2019 at 6:36

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

  • 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 7, 2017 at 5: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 7, 2017 at 6: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 7, 2017 at 7: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, 2017 at 6: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, 2017 at 6:17

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .