Wandering Thoughts archives

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 get to 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 acmetool, 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).

In short, 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 for us.

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.