31

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.

Improve this question
4

4 Answers 4

Reset to default
16

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.

Improve this answer
6
  • 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.
    – Robert Važan
    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
22

No. See IBM SSL overview

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

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

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

Improve this answer
3
  • Amended original question to clarify that it's a server certificate.
    – Lorin Hochstein
    Feb 16, 2012 at 15:01
  • 2
    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. youtube.com/watch?v=wMFPe-DwULM
    – Evan Carroll
    May 30, 2019 at 15:54
  • The only cache that could be used is for validity checks, though that is a security trade-off.
    – Daniel B
    May 30, 2019 at 16:02
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...

Improve this answer
7
  • 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
-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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.