Personally, I don't see the problem with short expiry dates, though less than a month would be too short in my opinion.
Their users are "people using browsers", not "people asking for cert signatures".
Plus, this concept that short expiration times increase security is suspect at best. If the private key leaked, 45 days is far too long, you'd need to reduce this to hours to actually help as a revocation strategy. And even then, chances are that the new key will leak as well right away, as it's most likely that the key was stolen by some undetected malware. And if the key didn't leak, a two year old cert is just as secure as a two minute old one.
I disagree. The smooth running and ease of automation of TLS certs benefits the entire ecosystem, including the end-users. Remember when the only sites that had TLS certs were the ones that could afford it?
> If the private key leaked, 45 days is far too long, you'd need to reduce this to hours to actually help as a revocation strategy.
This is a good example of the Nirvana Fallacy.
> And even then, chances are that the new key will leak as well right away, as it's most likely that the key was stolen by some undetected malware.
No certificate expiry control can protect against continuous, undetectable data exfiltration. Meanwhile, a one-time access that grants me the ability to impersonate you for 2 years is a significantly worse situation than one that only grants me that ability for a few weeks.
* Certs come with secrets. Long-lived secrets are riskier than short-lived ones because of window of opportunity if they're compromised in an undetected way.
* Less frequent cert rotations mean that the rotation process is inherently riskier. The old adage of "request a 2-year cert, and you're scheduling an outage 2 years from now" has a lot of truth to it. More frequent rotations increases the incentive to automate, which reduces the service risk.