I love love love the let's encrypt 3 months expire for this reason, it used to be such a pain to remember how to do the yearly/biyearly renew and now, as you say, it's just a Cron job.
At work, our customers need to get new certificates from a gov't agency every other year.
Most of them have either completely forgotten about it and how to do it, or there's been a change of employees and the new ones didn't get the memo, so to speak.
So it falls on us to remind them and guide them through the process.
How I wish the gov't moved to a 3 month setup like Let's Encrypt.
Depending on the government agency, there may be a required level of ongoing identity and need verification that can't be automated. For personal PKI in the US DoD, for instance, you have to go in-person to an ID office on a military installation to get your common access card renewed. For server certs, there is obviously no way to make a server go somewhere physically, but you need a qualified sponsor to sign off on the request to the DoD PKI office, and who that person is will likely change over any multi-year span, as military command positions tend not to last more than a year and even the civilian offices still see fairly frequent turnover at the higher levels. Plus those people need to sign requests with their common access card, which requires them to periodically go to an ID office in-person.
I'll go further: Three months is too long. Secrets which are used to authenticate and identify should be rotated far more regularly, using infrastructure which treats them as effectively ephemeral. The industry has learned to do this -- and built the infrastructure to support it! -- for things like user credentials (see: extensive use of AWS IAM roles, rather than user creds). We should be making a push to treat certificates the same way.
(That said, three months is better than any longer period. The shorter the rotation, the lower the risk -- but, more importantly, the stronger the impetus to build strong automation around the process.)
A three month expiration time with automatic renewal after two months (as letsencrypt recommends) is a sweet spot for me. When something breaks this gives you 30 days to figure out that something went wrong and to fix it with zero customer impact. The 30 day grace window is also long enough that let's encrypt will send you two emails (at the 19 day and 9 day thresholds) to make you aware that something might be going wrong.
If we lowered the expiration time to say 3 days, with automatic renewal after 2 days, then any breakage on your side or downtime on let's encrypt's side would quickly escalate into https errors. That in turn would train users that those just happen, and make them ignore the big red scary page even when it's an actual attack. That sounds much worse than the small risk from a 30 day certificate.
> If we lowered the expiration time to say 3 days, with automatic renewal after 2 days, then any breakage on your side or downtime on let's encrypt's side would quickly escalate into https errors. That in turn would train users that those just happen, and make them ignore the big red scary page even when it's an actual attack. That sounds much worse than the small risk from a 30 day certificate.
That's already happened. I'm encountering LE errors on random websites so much that I don't care and automatically click through warnings. This is especially troublesome because my government keeps MITM me and I don't like it.
I did this manually for a while with a reminder every 3 months but now it happens automagically with a cron job on my server as well and now I'm similarly at risk of forgetting how it worked in the first place
> now I'm similarly at risk of forgetting how it worked in the first place
I once met a person at a client org who was generally opposed to automation due to risks of forgetting how things work and not always knowing what the internals behind those abstractions are. It was an interesting take.
At the same time, something like Ansible and other methods of automation can be pretty useful and actually aid in documenting things.
It's especially good if you can spare 10% of your time to put some notes down in Markdown files in a Git repo, or source/deploy most of your automation scripts from there as well.
Lets encrypt makes sense in a world where you have pet servers and can install random software like certbot and keep them running for years.
In a world of containerized and immutable cattle servers its not a good solution. Especially not when you technically only need it for something that is internally accessible.
Currently my homelab setup is based on running certbot locally in a docker and a calender entry - maybe I get annoyed enough and switch to my own cert at some point, but those are also a big pita.
LE's short expiry is the primary reason why I don't use it. Yes, I know, automation is the approved solution for this, but it's not a great solution for me.
Agreed, when the tools stop working (which, they do) then suddenly what was swapping out a file instead becomes a big ordeal with fighting nginx .well-known bypass or trying to figure out why lets encrypt can't connect via IPv6 but everything else seems to be able to or, in my case, when certbot-auto stopped working and had no upgrade path on oBSD.
my blog and personal website are down for this reason, I simply can't spend half-a-day at this point in my life figuring out how to do this on OpenBSD. So I'd rather just leave it dead at this point.
Guess I could just buy an SSL certificate still, maybe I do that tonight.
Most of them have either completely forgotten about it and how to do it, or there's been a change of employees and the new ones didn't get the memo, so to speak.
So it falls on us to remind them and guide them through the process.
How I wish the gov't moved to a 3 month setup like Let's Encrypt.