Let's Encrypt certificates currently have a ninety-day lifetime9. Web standards do not require any minimum certificate lifetime. As of 2015, the Baseline Requirements3 specify a maximum certificate lifetime of 39 months.
The Technical Advisory Board5, chose a 90-day certificate lifetime to start with, with an expectation that people will want to auto-renew at the 60-day mark.
30 days is often used to keep CRLs small for mobile clients. That's why Google rotates the certificates on its properties every 30 days. However, they re-certify the same public key.
Otherwise, it can create a DoS for user agents over wireless. From Peter Gutmann's Engineering Security, page 640:
... For PKIs sized at tens of thousands of users, multi-megabyte CRLs are not uncommon, and the potential size of CRLs for hypothesised national CAs/PKIs is unpleasant to contemplate. As long ago as 1998 a Verisign employee had warned that for user populations much larger than 10,000 certificates the use of CRLs “requires infrastructure capabilities that are beyond the state of the art and further may not operate in practice” [214] (in practice if the CRLs are issued extremely infrequently and most clients don’t check them then this can be made to appear to work, for some value of “work”).
An example of these problems was illustrated by the Johnson and Johnson PKI which, with 60,000 users, had a CRL over a megabyte in size after its first year of operation [215], requiring that users fetch roughly a million times more data than necessary for any certificate check (the entire CRL had to be fetched in order to obtain the effect of a single boolean valid/not valid flag). The problem was “solved” in this instance by only issuing a CRL once a week and caching old copies of the CRL to turn it into the ritual check described earlier, a relatively common approach whenever this problem raises its head. In contrast the rather larger US Department of Defence (DoD) PKI, which by 2005 had issued sixteen million certificates and revoked ten million of those, was issuing fifty megabyte CRLs (!!) that users had to download once a day [216]. A few years later these had grown to over a hundred megabytes, with the largest CRL known to the author, reportedly from a European government CA, being over 150MB, resulting in what’s euphemistically reported as “low user satisfaction” as systems appear to hang while they retrieve and search such monstrous CRLs [217].
A kludge adopted by one organisation to try and address this problem was to start removing fields from the CRL in an attempt to reduce its size, discarding accuracy in the interests of just getting some sort of data out the door [218]. Another CA, even after taking this drastic step in addition to splitting the load across four sub-CAs, still ended up with 90MB CRLs, with widely-used tools requiring around a gigabyte of memory to process one of these monster CRLs [219]. Other PKIs went even further, using dozens and dozens of CAs (with their attendant cost and overhead) purely to restrict the size of the CRL that any one CA had to issue. The reason for the rapid growth of these CRLs is that great quantities of certificates are routinely revoked for benign purposes entirely unanticipated by the X.509 designers, discussed in more detail in “Case Study: Inability to Connect to a Required Server” on page 502.
Maybe let's Encrypt should issue certificates for 45 day, and send a new certificate every 30 days, without requiring a re-enrollment. At 90 days or 180 days, it could require operators to prove possession of the private key again.
And a 90-day or 180-day (or longer) certificate could be an upsell item to help defer costs.
