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.

Solution 1

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.

Solution 2

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.

Comments

[Admin]

Have a look here imperialviolet.org/2011/05/04/pinning.html about "certificate pinning" and at the HSTS initiative whis is related to the former dev.chromium.org/sts

[Admin]

As of 2019 my Chrome 75 is caching SSL certificates

[Admin]

TLS 1.2 introduced session tickets. This mechanism effectively "caches" the certificate, by not needing to transfer it at all. More info at blog.filippo.io/we-need-to-talk-about-session-tickets

[Lorin Hochstein]

Amended original question to clarify that it's a server certificate.

[Ramhound]

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.

[tuexss]

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.

[Robert Važan]

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

[Seth]

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?

[Etienne]

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.

[Seth]

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.

[Etienne]

I am only reporting what I experienced regarding SSL cert and it looked like Chrome cached it but I am not 100% sure. Thanks

[Seth]

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?

[Etienne]

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]

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

[anilech]

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.

[Tad Lispy]

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.

[Evan Carroll]

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

[Daniel B]

The only cache that could be used is for validity checks, though that is a security trade-off.

[tuexss]

You'd probably need to go to the keychain and remove it manually from the certificates.