What is the purpose of frequently rotating TLS certificates without changing underlying keys?

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.

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
Modulus=AF384ED52C86FBDCD4F3117AD63652874889E442C80B4B112B3AEFA978607B33758927E75F92838D1A42B19F1DB59BC55322068FB197D38BBCB68984CAB4F0328E10A1B0D98DA794AAA379AB7C3CAFF177663127EC5069872F801E925AEDB76C865209A00A55618A2D1BB91F368D5739A1DE88C9FE66F5E0108C1FF1025D62DEE3BFBFB9BCFD3E71EC9C6E91A05AECD9833AE32B89B432DCD4C489D69C2BEC7E325C621184A8E8658CD3B755E62E65E19A2649ADC668E5C2705280884FC5D3B9D5914AC27D22B050F819233A0DDFF4194F55BDE358AABA6376567087BA69407B17EA364DB3A842A1972199B9B5632088F0E1C45B50DD1AD123F49573094051F3


$ 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
Modulus=C15236913979042DF078DF5B73AF463A636F98CE32A2AABAC378180566A87C382BB3A82A6808D4103D626A37CA4FBF8ABEA5939DD6C9874A8D318593F5481F59756E76817CBD38B73A5C703438BB9A824FD054B168ED3C9E5CD0445F744ED2A4EAA6327A94813A98C941BD60F3B19C5DC8CDFB34DE9293C53D41A234B4499A4F19C6AF193084F61C6636D7E89AEA86110231E6EE03F4C853841B0FB46122E6D73E7EF08D058665C7297B1A329F16F0EEB856E7614EB16B23CB4B6BBC5B567685F02638B52ECEBC71B06A1503776C0945A75E3227F71FE2956FC48533A6529066C840433A6705E94523843D10C45A8BC9CD58FCA6A6AABD79F2FFFEE6CB254AB9

[...]
$ openssl x509 -in google-apr.pem -noout -subject -dates -modulus
Modulus=924D62DDCD6B012D33F6CF12A5FD6291B490867ABB1E4F7F356FA8BBD424400C283EE7BB14DA8D1268239814A490F7D88EBA5EA3A9ED8DFEE6B6FF841405A964D47B1F76DB6F39A6990FD024060248FA889580271D6DDA6A7ADEB1538425268FAA8C2D824865DA3F30F78D48887D4C90D86F0A8A95F0A9CC951B7562FC98EC91D132C1C9418182045652BF510D357F1792201126DF230CD76BCA58B367A30088E6606FE7B80265582BD9A235F36AC60A2A6C266775979B52501355C51C7927ABA5DD0FFAFA39DFA240B3F21826188A9818B5E9761D38E15ACA980EF12BA14BEE00CA3D8C7F66112B56CEDCE2CA8BE67DD8ACA8B594D906CAE752217F67419E59

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.

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.