Hacker News Reader

Comment by jedberg | Hacker News Reader

Good practice says that you should be renewing your certs when they have about 10% of their lifetime left, just in case this exact thing happens with whoever your provider might be.

It's unlikely they would be down for so long that certs would actually expire.

View on HN

I don't think a percentage is the best way to think about it. There is a lot of variability in lifetimes and the time it takes to resolve issues is not related to the lifetime of the cert.

Just pick a discrete number of days before expiration such that you have a comfortable amount of time to deal with issues.

We (Let's Encrypt) recommend renewing with 30 days left, so every 60 days. If your system is automated like we recommend that shouldn't be burdensome, no reason to do it less often than that.

Also, Nagios/Icinga has a handy certificate checker in check_http. If that is a bit too much then logwatch the log and notify on the box itself.

For what it’s worth, I’ve run into some issues with this guidance from you guys as I’ve been building out a private CA with ACME support. A lot of ACME clients have hard coded renewal at 30 days prior to expiration, which makes them pretty worthless for managing short-lived private certificates. Using a percentage might not encode a fixed SLA very well, but as a default it does accommodate various lifetimes well.

I can see pros/cons either way, just thought you might be interested in this feedback.

The recommended way to use LE is to run the renew command daily and it will do nothing until it finds a cert 1 month or more old. That way you have 2 months to solve an issue.

What happens if their private key gets exposed? A third of the internet being suddenly insecure is a really scary prospect. If everything is automated, a lot of smaller sites may not notice until the certificate expires, or even for some time after that.

Having more options means less fallout if a CA gets compromised.

Reply on news.ycombinator.com