3 ms·

It took some warming to, but I have come round to appreciate letsencrypt's short certificate lifetimes. Monthly renewal should be maximum for any system, but id

It took some warming to, but I have come round to appreciate letsencrypt's short certificate lifetimes. Monthly renewal should be maximum for any system, but ideally you'd want to go weekly. Assuming your renewal is automated, I don't see any downside, only benefits. It properly internalises cert renewal as part of standard system operations, bringing it into your daily ops instead of having it as some scary gray undocumented box for the next guy to tick. Much like writing tests, it initially hurt my ego a bit, but I've come to like and proselytise it.

tqkxzugoaupvwqr 8y ago
Your proposal may lead to an unintended DDoS of the CA.
- jjeaff 8y ago
  Let's Encrypt recommends a daily cron job for cert renewal. The certbot only actually pings the servers for a renewed cert if the current cert is within 30 days of expiration.
- geofft 8y ago
  Most CAs already operate an OCSP responder which supports querying daily (if not more frequently) to make sure a certificate still hasn't expired; it checks the database and responds with a signed and timestamped acknowledgement. (Those that don't need to support frequent queries of a static certificate revocation list file.) So this is already a level of requests that CAs have to be built for. And even if it didn't, scaling certificates from once a year to once a week requires merely 50x capacity - a finite number, and something that's very easy to plan out. If CAs in the '90s and '00s were able to handle a certain once-a-year request load, surely CAs today can handle 50x that.
entity345 8y ago
There is no need for enforced expiry of certificates, especially here where there are used internally on a controlled network. If there is a requirement or good practice to periodically replace key-pairs then it should be a network management operation. Equipment should never stop working because it decided that a key-pair had expired. X509 certificates are not technically optimal in many situations and, let's face it, the main driver for expiry dates is that certificate vendors want to sell more certificates...

tqkxzugoaupvwqr 8y ago

Your proposal may lead to an unintended DDoS of the CA.

jjeaff 8y ago
Let's Encrypt recommends a daily cron job for cert renewal. The certbot only actually pings the servers for a renewed cert if the current cert is within 30 days of expiration.
geofft 8y ago
Most CAs already operate an OCSP responder which supports querying daily (if not more frequently) to make sure a certificate still hasn't expired; it checks the database and responds with a signed and timestamped acknowledgement. (Those that don't need to support frequent queries of a static certificate revocation list file.) So this is already a level of requests that CAs have to be built for. And even if it didn't, scaling certificates from once a year to once a week requires merely 50x capacity - a finite number, and something that's very easy to plan out. If CAs in the '90s and '00s were able to handle a certain once-a-year request load, surely CAs today can handle 50x that.

entity345 8y ago

There is no need for enforced expiry of certificates, especially here where there are used internally on a controlled network. If there is a requirement or good practice to periodically replace key-pairs then it should be a network management operation. Equipment should never stop working because it decided that a key-pair had expired. X509 certificates are not technically optimal in many situations and, let's face it, the main driver for expiry dates is that certificate vendors want to sell more certificates...