But (there was always a but coming) ... the word "rotation" is over-used here and very dangerous, because it doesn't emphasize what's important. To many it means "deploying a new credential". That's not that important at all, at best it's a means to an end at worst it's make-work. What's important is that credentials are revoked. It's exactly like the important part of backup systems being that we can restore (and we should really call them "restore" systems).
When a credential becomes compromised, what you want to do is revoke it and make sure it stays revoked, other wise the attacker's goal is complete. So think of it a "Revocation" system, and call it that.
Viewed in that context, it become more apparent that the write-up doesn't mention, or test or check, that the credential actually is revoked and doesn't work any more. But that's the most critical step. Even if you're relying only on expiration times (which seems unsafe!) it's important to check for broken checks (like fail-open configurations that let everything in), broken clocks, etc ...
For large majority of companies, would they even spot that their keys have been stolen? That's a few steps before revocation itself.
I wish there was a CA out there that could let you requests new certs more frequently.
Yes there's Let's Encrypt, which is amazing and works great but the ratelimits[1] really kill you if you're not careful. I've had a few issues where I've triggered the LE ratelimit with a production domain and got locked out of making new certs for a whole week. I would gladly pay for an ACME CA which does not enforce these ratelimits.
It might be easier to resell someone else's certificates.
[0] https://golang.org/pkg/sync/atomic/#example_Value_config
