Why we're going to be using Certbot as our new Let's Encrypt client
We need a new Let's Encrypt client to replace
acmetool, and I'm on record as not particularly
liking Certbot; it lacks some features
that are important to us, it's a pretty big program, and it's quite
ornate (and there's the issue of the EFF trying to get you to sign
up for their mailing list when you register a Let's Encrypt account
with an email address). But despite that, Certbot is going to be
our future Let's Encrypt client unless we uncover some fatal problem
as we finalize how we're going to operate it.
The reason why is very simple; I never want to go through changing clients again, because changing clients is very disruptive and a lot of work. We're forced to change clients now because our previous client of choice has stopped being maintained and hasn't kept up with Let's Encrypt's changes. Certbot is pretty much the closest thing Let's Encrypt has to an official client, so the odds are very good that it will keep up with any Let's Encrypt changes, and probably also any other changes needed to keep working on popular Linuxes such as various versions of Ubuntu LTS.
(Let's Encrypt officially recommends Certbot and has for some time.)
Certbot is not my ideal Let's Encrypt client. But it is a workable client (and we can make it more workable with a cover script), and it's extremely likely to stay that way for as long as we want to use Let's Encrypt. This is good enough to make it my choice.
(On a pragmatic basis, Certbot also seems to be the closest I can
acmetool in a client that is written in a way that I'm
okay with. In particular, as someone who has dealt with OpenSSL and
written things in Bash, my view is that I don't think either are
the right foundation for a Let's Encrypt client that I want to
entrust our systems to. I admire the spirit of aggressive minimalism
that makes people write Let's Encrypt clients with little or no
dependencies, but that isn't what's important to us.)
Sidebar: I don't regret picking
acmetool way back when
Back when I initially picked
my usage case was different and Certbot was significantly more work
and more intrusive to install than it is today. Carrying over using
acmetool when we switched to Let's Encrypt
was natural, and it worked well. Also, acmetool is a very simple
client to use and in the beginning that was important to us because
we weren't sold on the benefits of Let's Encrypt; a complex install and operation
process wouldn't have been half as attractive, and we might have kept
on using manually obtained TLS certificates (especially after we could
get free ones through the university's central IT).
acmetool has worked great for years and was the no
hassle client we needed at the start. Especially at the time when
we started using it, I don't think there was a better alternative
Wireless networks have names and thus identify themselves
Recently something occurred to me that sounds obvious when I phrase it this way, which is that wireless networks have names. Wireless networks intrinsically identify themselves through their SSID. This is unlike wired networks, which mostly have no reliable identifier (one exception is wired networks using IEEE 802.1X authentication, since clients need to know what they're authenticating to).
This matters because there are a number of situations where programs might want to know what network they're on, so they can treat different networks differently. As a hypothetical example, browsers might want to apply different security policies to different networks. With wireless networking, the browser can at least theoretically know what network it's on; with wired networking, probably it can't (not reliably, at any rate).
(Another case where you might want to behave differently depending on what network you're connected to is DNS over HTTPS. On some networks, not only can you trust the DNS server you've gotten to be not malicious, but you know you need to use it to resolve names properly. On random others, you may definitely know you want to bypass their DNS server in favour of a more trusted DoH server.)
PS: I believe that Windows somewhat attempts to identify 'what network are we on' even on a wired connection, presumably based on various characteristics of the network it gets from DHCP information and other sources (this is apparently called 'network locations'). My experience with this is that it's annoying because it keeps thinking that my virtualized Windows system is moving from network to network even though it isn't. This makes a handy demonstration of the hazards of trying to do this for wired networks, namely that you're relying on heuristics and they can misfire in both directions.