I've never had any of these issues, so I'm surprised by how spectacularly the author's setup broke. I can understand some Python library failing during the auto update process needing a rollback, but needing a complete reimage to fix the situation? How does that even happen?

> new protocol for the letsencrypt challenges was released, announced in some obscure corner of the web and bit by bit the old method of issuing new certificates was deprecated. You would not have known this unless you interacted with Letsencrypt on a daily basis, but like most of these things their whole value lies in NOT having to interact with them all the time.

Let's Encrypt also sent out emails to people still using the old method at least two months before the old method was phased out. You have to provide an email address when setting up LE exactly for this reason. The only explanation I can think of for why the author wouldn't have received an email is that they did not execute a renew check for their certificate in the three months leading up to the change of service, which is going straight against LE's guidelines (you should check more often, exactly for this reason). This is the

> which is odd because after all the situation hasn’t changed and if it worked last time it should still work this time

The situation obviously _has changed_ otherwise the venv wouldn't have been updated. Libraries get bugfixes even if those don't apply to you specifically; deal with it. You're not the only customer here.

> I understand that Letsencrypt needs to stay with the times. But the Letsencrypt folks should also understand that in the greater scheme of things certificates are not the most important thing in life and that causing your end users this level of grief is in the longer term not in the projects’ best interest.

Web security is not a "set and forget" thing. It's not a toggle button from "insecure" to "secure". If you want a zero-maintenance certificate solution, get a managed server and get someone else to handle the annoying stuff for you.

> The machine that this is all running on will need a much more recent version of its OS. That means I’m going to have to migrate a whole bunch of data to another machine in order to be able to do this without downtime.

This is unsurprising coming from someone who wrote a blog about why they don't like to update. However, the assumption that the entire host OS needs to update just to use a new piece of software is simply wrong. Things like Docker and LXC make it trivial to run newer software without upgrading the entire system. It also forces the software into a contained space to prevent the catastrophic failure the author had to deal with before.
From what I can tell from a Shodan check for this domain, the author still seems to be running Ubuntu 14 (which went EOL last year). That probably explains why the author is afraid that they will need to upgrade their server. However, if you're running on a software stack whose LTS support has already been dropped, you're just postponing the inevitable by not planning an upgrade plan already. Blaming Let's Encrypt for potentially not supporting a platform nobody else supports is a silly excuse.

I agree that Let's Encrypt has its issues. Sure, their client can use some thinning, their decisions are sometimes confusing, but the normal situation is not nearly as bad as the author describes here. If you're bothered by the official client updating things, use a different client; there's plenty of them.