Announcing Certbot: EFF's Client for Let's Encrypt

[Posted May 12, 2016 by jake]

The Electronic Frontier Foundation (EFF) has announced a new name and web site for the Let's Encrypt client. The Let's Encrypt project is a free certificate authority for TLS certificates that enable HTTPS for the web. The client, now called "Certbot", uses Automatic Certificate Management Environment (ACME) to talk to the Let's Encrypt CA, though it will no longer be the "official" client and there are other ACME clients that can be used. "Along with the rename, we've also launched a brand new website for Certbot, found at https://certbot.eff.org. The site includes frequently asked questions as well as links to how you can learn more and help support the project, but by far the biggest feature of the website is an interactive instruction tool. To get the specific commands you need to get Certbot up and running, just input your operating system and webserver. No more searching through pages and pages of documentation or Google search results! While a new name has the potential for creating technical issues, the Certbot team has worked hard to make this transition as seamless as possible. Packages installed from PyPI, letsencrypt-auto, and third party plugins should all continue to work and receive updates without modification. We expect OS packages to begin using the Certbot name in the next few weeks as well. On many systems, the current client packages will automatically transition to Certbot while continuing to support the letsencrypt command so you won't have to edit any scripts you're currently using."

Announcing Certbot: EFF's Client for Let's Encrypt

Posted May 13, 2016 3:10 UTC (Fri) by gutschke (subscriber, #27910) [Link] (3 responses)

I am glad to see that they took this step. There are now a large number of different client implementations for the ACME protocol. The Certbot client certainly makes for a great reference implementation, and it also solves a couple of interesting problems that other clients don't attempt to address.

But it was unfortunate that for a while the LetsEncrypt project made it sound as if their client was somehow the "one-true implementation of ACME". I don't think this was ever intentional, as they went to so much effort to come up with an open specification for the protocol.

Moving the Certbot client into its own project that is deliberately separate from the LetsEncrypt CA is a great step.

Announcing Certbot: EFF's Client for Let's Encrypt

Posted May 13, 2016 9:18 UTC (Fri) by tialaramex (subscriber, #21167) [Link] (2 responses)

I don't think anybody expected the level of take-up of ACME that we've seen. It was predictable that lots of people would want free (to them) certs, including both people who previously weren't aware that it was possible to get one from WoSign or Start and those who didn't like the strings attached to those offers, but it wasn't so clear that hosting companies, and independent coders would actually write clients for ACME and thus in a sense over-shadow the official client work.

The downside to the proliferation of clients is that their quality is very... variable and they're often one person's hobby. If you're using a client written for your favourite obscure language, chances are that in six months it'll be unmaintained. ACME isn't official yet, the IETF is not a fast mover, and a finished ACME is likely to be a little different but ISRG are sure to implement the finished specification. And the CA/B forum is also currently debating changes to their Domain Validation rules. If a rule change requires something ACME doesn't do today, you should expect ACME to change, and with it Let's Encrypt, because if they can't pass the CA/B requirements it's all for naught. So an unmaintained client could become a real problem.

The move from the X1 to X3 intermediate certificate showed that some clients are doing "whatever seems to work" rather than even obeying the current spec. The spec says how to determine the relevant intermediates for your certificate, and Let's Encrypt's backend obeyed as did what is now called Certbot. But some other clients continued to mindlessly paste in the now irrelevant X1 intermediate, resulting in chains that don't work for some browsers. It's hard to explain to users that yes, they've got a valid certificate, but it won't work in _some_ web browsers because the client they used installed it wrong. I didn't see many client developers stepping in to help clean up the resulting questions from their users.

Announcing Certbot: EFF's Client for Let's Encrypt

Posted May 13, 2016 10:09 UTC (Fri) by pboddie (guest, #50784) [Link] (1 responses)

The downside to the proliferation of clients is that their quality is very... variable and they're often one person's hobby. If you're using a client written for your favourite obscure language, chances are that in six months it'll be unmaintained.

I don't even think it needs to be in an obscure language to risk this fate, either. What has happened is what tends to happen when a hot new (and evolving) technology appears and the practice of "scratching one's itch" combines with people trying to show that they're at the forefront of technological development: you get tens of different projects that don't really have any sustained commitment behind them.

And rather than a few high-quality choices, you risk getting many low-quality choices instead. Which means that everyone now has to trawl a long list eliminating each of those choices one by one as their flaws become apparent. What makes this case worse than usual is that the software is doing things upon which each site's security depends, so it's important that people do look to see what these clients actually do. ("I need root to edit your configurations!" No thanks!)

And infuriatingly, given the constraints of any hosting environment (and any absence of formal support from the hosting provider), the result can be a lot of uncertainty about whether any of the clients will do the job, with some people taking the "cargo cult" approach and chasing down some random project that random people claim does the job, and everybody else wondering why this supposed simplification of certificate management is starting to seem as complicated as the traditional approach.

Announcing Certbot: EFF's Client for Let's Encrypt

Posted May 13, 2016 12:42 UTC (Fri) by tialaramex (subscriber, #21167) [Link]

For hosting I think this will become a weak discriminator. In the same way that people moan (not always with the effect of discouraging new customers, but they do moan) if a hosting company has persistent network trouble, or screws up domain transfers, I think we'll start to see them moaning if the hosting company can't do Let's Encrypt properly or expects them to run some half-arsed Perl script rather than just clicking "Yes, encrypted site please".

Under the hood I'm not too scared how these are implemented. Bigger hosting companies are often maintaining their own source patches for Apache or nginx, even their own hand-rolled Linux kernel config. They're big boys, if they run letsencrypt.sh and its maintainers go away, they will get one of their staff to look after it. They will sometimes screw up (my host once billed me an entire year early due to fat-finger syndrome...) but they won't just let stuff rot because that's how you go out of business.

I do hope to see more ACME support inside TLS-capable server software. There's no reason why Apache (or IIS) shouldn't be able to conclude that it is in fact serving up https://some.name.example/ and therefore it can go get itself a certificate for that name from Let's Encrypt and sign everything accordingly without you needing to run any third party scripts. It's a bit trickier if you're an IMAP server or a SMTP server, but not insurmountable, at the least they could be taught to co-operate better with Certbot.

Longer term I'd also like to see ACME leveraged to do other things beyond issuing BR-compliant DV certificates to Internet servers. In one direction it seems useful to do ACME for private CAs. If I have dozens of internal servers speaking TLS, I _could_ expose them, or at least their names, to the Internet to use Let's Encrypt, but probably it makes more sense to set up a private CA. However that's only true if the private CA isn't a huge hassle. If it is, Let's Encrypt wins despite the increased attack surface and waste of public resources. So hence ACME for private CAs. ISRG's "boulder" ACME server is on github, but getting from there to having a package anybody running a private CA can install and use is a bunch of effort and (quite rightly) not one that ISRG's mission focuses on.

The other direction is other certificate types. S/MIME and other client issuance seems amenable to automatic systems. ISRG aren't interested, it's off-mission, but ACME could be re-purposed to this end. Even for EV SSL or EV code-signing, ACME can't solve all the problems but it can make a bunch of the less interesting steps that still occasionally go wrong fully automatic once you successfully complete all the manual human verification steps. Among themselves none of the CAs seem to be hostile to ACME, even if they'd rather not have an organisation issuing millions of free DV certificates, so I can imagine an EV-focused CA looking at ACME as part of a solution to make their EV product easier to buy, once ACME is more established.