And you get the extra benefit of being emailed[0] a few times beforehand if the certificate fails to renew as long you register your account with an email address.
Very much so. In my experience with nightly jobs in a corporate setting, the more often something happens, the more likely you are to catch an upstream dependency that breaks it.
The sooner you catch that breakage, the easier it is to get the resources (either from that team, or from your own team) to fix it. It’s a matter of “Oh we changed that API 2 months ago, everything is fine for us, all of our people have moved on to other tasks” versus “Oh our change broke you? We can revert it until we have a workaround”.
2 months, in most orgs, is enough time to figure something out before your entire business goes offline.
If by "automatic update tool" you're referring to Certbot (the EFF's reference ACME client implementation), you don't have to use it. There are several dozen ACME clients, including some that are entirely shell scripts (such as Dehydrated).
Not recommending this, but it is technically possible to proceed as follows:
* Server mints an arbitrary key pair, it produces a CSR with the public key in it, signed using the private key, and the administrator manually copies this to an external ACME client.
* ACME client uses the CSR and control over DNS to get Let's Encrypt (or any ACME CA) to issue periodically, say, once every 45 days or as soon as possible if that's exceeded.
* Server periodically fetches any new certificates for its name from any public source of them. You can build your own server, you can use crt.sh, you can use Google, it doesn't matter because the certificates necessarily contain baked in proof that they're genuine.
Notice that in this design the server and ACME client don't talk to each other at all. They both have to be (at least sometimes) connected somehow to the public Internet, but they never need to connect to each other after that one time setup, they don't even need a human to manually transfer stuff, they just both do their thing and it works out.
This does mean the key remains the same for the lifetime of the server. But if you have a sane policy for servers getting replaced (e.g. they're depreciated over 36 months and replaced before 48 months) there's no reason that should pose a problem in itself.
> It seems unworkable for the majority of smaller sites who are increasingly forced to use letsencrypt.
It's one line in a crontab, hardly an enterprise level endevaour involving IBM consultants and a triple redundant K8S cluster.
> Unless you want that automatic update tool on your server, which I find a bit sketchy.
It's no sketchier than you using binaries from your distro's repo, or even the Linux kernel. I doubt you'd read either line by line to check for nefarious wrong doing.
Let's Encrypt is a Certificate Authority, so, it doesn't have any "default behaviour" in respect of renewals, from the CA's point of view "renewing" is just a new issuance that happens to be for an identical subject. Let's Encrypt's rate limiting policies do actually care about that ("Duplicate Certificate Limit" five per week for each subject) but it can't put in place any particular policy about when you must or will renew.
CAs which charge for issuance often have a policy which implies an earliest sensible renewal date, because they will "carry over" remaining time on the previous certificate. There is a practical limit to that, (for example today your "one year" certificate from such a CA can only have up to 398 days until it expires, so renewing two months early won't make sense) because of the Baseline Requirements and/or trust store policies.
But if you're doing client development for ACME, the protocol Let's Encrypt implements for issuance, then yes, they'd tell you that they advise you to begin trying to renew with 30 days left. The EFF's Certbot tool, which a long time ago was just named "letsencrypt" implements this policy as do many other stand alone ACME clients.
