I read in the OWASP cheat sheet regarding certificate / public-key pinning that “Google rotates its certificates … about once a month … [but] the underlying public keys … remain static”.

Increasing the frequency of key rotation makes sense to me in that, should a key be compromised without detection, the time frame for ongoing damages is reduced.

What is the benefit of rotating certificates so frequently? Is it to allow them to use SHA1 (for old-browser compatibility) whilst limiting an adversary's scope for finding a matching signature? Or is there something else that I'm missing?


One big advantage is removing the need for revocation in the event of a compromise.

The "typical" way to do this is publishing a certificate revocation list (CRL) or using the OSCP protocol in the event of a compromise to revoke certificates. However, the CRL or OSCP check is incredibly easy to bypass. An attacker in a position to perform a MITM attack can simply block a client from communicating with the server where the CRL is hosted and the client will simply happily go about its business. This is necessary because of common situations like captive portals that work over HTTPS yet blocks all other traffic, including traffic to CRL servers.

Short lived certificates have the advantage that in the event of a compromise, the compromised certificate will only work for a very limited period of time until the certificate expires, therefore limiting the damage that can be caused.

Adam Langley has written extensively on the subject if further readings is required.

  • 2
    +1 This is the action of an organization that expects compromises instead of just considering them a possibility. Bypassing CRL bypasses is the only reasonably safe way to operate so many servers -- and even that is not perfect (but nothing that is even marginally usable by humans is).
    – zxq9
    Apr 14 '15 at 8:41
  • 1
    With regards to certificate compromise (presuming that the certificate is pinned therefore mitigating a rogue/compromised CA) are there mechanisms other than (a) compromising the underlying key, and (b) producing a certificate with a matching signature? Apr 14 '15 at 9:25
  • 5
    @musiKk: there is hope with Let's Encrypt
    – WoJ
    Apr 14 '15 at 10:55
  • 1
    @musiKk RapidSSL (and I presume GeoTrust generally) doesn't ask why you are reissuing. Apr 14 '15 at 11:46
  • 4
    If the public key remains the same, the private key must remain the same. "Compromise" to me means that someone has compromised the private key. Changing the certificate in the case of a private key compromise does nothing. So I'm a bit confused as to this answer. Can you explain? Apr 27 '15 at 17:21

Terry Chia answered the question "What is the benefit of rotating certificates so frequently?" fully correct, so there's nothing for me to add.

However, I'd like to add a note that Google does frequently change their public keys as well, so the assumption of the cheat sheet is invalid. This does add pretty much confusion and may be part of the reason for the original question.

Just from my personal x509-archives:

$ openssl x509 -in google-oct.pem -noout -subject -dates -modulus
subject= /C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
notBefore=Sep 24 10:48:54 2014 GMT
notAfter=Dec 23 00:00:00 2014 GMT

$ openssl x509 -in google-nov.pem -noout -subject -dates -modulus
subject= /C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
notBefore=Oct 22 12:57:51 2014 GMT
notAfter=Jan 20 00:00:00 2015 GMT

$ openssl x509 -in google-apr.pem -noout -subject -dates -modulus

The actual keys are completely different, and that's perfectly fine from a security perspective.

Assuming that given enough time and ressources, one may e.g. attempt to brute-force-calculate a private key to match a known public key. Or something like heartbleed does happen one more time, resulting in a compromise of private keys. A simple way to mitigate both kinds of threats is to periodically change the keys.

From my observations, Google's certificates are valid for three months, but are exchanged once a month. This is fine from an operational point of view: you don't want to reload the new certificates in exactly the same second, but probably start deploying the new certificates on 1% of the affected servers and increase to the full fleet of servers. If something goes wrong, you can still revert to the old, still-valid certificate, and have up to two more months to fix the new certificates, server configuration, server software or whatever is resulting in the associated trouble with the new (broken) certificate.

  • You can confirm a change in a private key by a change in the modulus (and possibly exponent) of the certificate. openssl x509 -subject -dates -modulus gives you easier to read output. The -pubkey output is base64 of the DER structure of a sequence of the RSA OID, the modulus and the exponent. (You cannot reliably diff base64 because it is not octet aligned, the addition of a single byte will propagate changes in the output, though it should not vary here, it could vary.) Apr 27 '15 at 12:32
  • Where is Terry Chia's Answer? Deleted?
    – flow2k
    Nov 19 '18 at 5:45

Under Ayrx's answer, Steve Sether notes that:

  1. There is a one-to-one correspondence between the public key and private key - they form a so-called key-pair. The private key changes if and only if the public key changes. So we need to first understand, since the private key doesn't change during a certificate refresh, the public key doesn't either. Only the cert is updated, notably its expiration date.
  2. Let's consider the scenario that our private key is compromised - say an adversary stole our private key. Changing to a new cert will not help, because the cert is public, the adversary can keep obtaining the new certs, and masquerade as us.

I agree with Steve's points. So what's the use of changing to a new cert?

The crux here is not changing to a new cert, but rather the limited validity or expiration of the old cert. If the private key compromise is undetected (#2. above), then this expiration will not help - however, if we know of the compromise (as is often the case), we can try to revoke the cert (mentioned by Ayrx) - regardless of and independent of revocation, we know we have to use a new private key. The expiration of our old cert means our private key will also "expire" at the same time, as they're a key-pair.

There may be other attacks that refreshing the cert can help mitigate, but I think the above use case is a prominent one.

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.