Announcing Certbot: EFF's Client for Let's Encrypt | Hacker News Reader

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

eff.org

165 pointsschoen61 comments

> Let’s Encrypt is a certificate authority, co-founded by EFF, Mozilla, and researchers from the University of Michigan

I'd like to make a point about money: Institutions like these need money, or many important public goods will never exist. Consider that next time you are making donations or your legislators want to cut funding.

Risking playing the devils advocate, checking the EFFs annual financial reports shows 13M support + 1M from investment income against 7,5M total expenses (salaries being 5,3M). EFF is doing good work and Let's Encrypt is a great initiative and I'm sure they can use every dollar, I'm just wondering whether you could have a bigger impact donating your money to other organizations / developers who are worse off.

https://www.eff.org/document/fy-2014-statement-activity

> I'm just wondering whether you could have a bigger impact donating your money to other organizations / developers who are worse off.

You certainly could.

However, every donation has opportunity costs in multiple dimensions, and if you walk down the "can I have better impact somewhere else" path, you'll find it rife with circularities and get nowhere.

Instead of the top N _best_ candidates to donate to, I usually look for N _good_ ones, and be done with it.

The smaller the organization, the bigger the impact of your money. However that doesn't mean it will be spent better.

tinhat on. Also consider where they get most of their money.

Please elaborate if you suspect ulterior motives.

EFF receives donations from DPR2 [1].

[1]: http://motherboard.vice.com/read/the-secret-life-of-a-silk-r...

> This is because he says he donated hundreds of thousands of dollars to a wealth of different organisations and charities. Those included the Tor Project, the nonprofit that maintains the Tor software, and some entities with no immediate link to technology or drug policy, such as a children's home. (The Tor Project did not respond to multiple requests for comment.)

No direct mention of the EFF, but I'll take your word for it. Of course even if Assad, Erdoğan, and Putin donate money to the WWF, that does not mean saving panda's is a bad thing.

So what? now the project is _tainted_?

This new name and website are a big improvement to the branding of the client, and make it clear that this client is not a requirement for getting a certificate from Let's Encrypt. It was very difficult to explain to people learning about it that there is a difference between:

1. Let's Encrypt, the certificate authority

2. ACME, the protocol for users to interact with Let's Encrypt

3. Boulder, an implementation of an ACME server in Go that Let's Encrypt uses

4. Certbot (formerly the Let's Encrypt client), a command line client and ACME library for Python, originally developed by the Let's Encrypt team

Any CA can use ACME to offer automated certificate issuance to their users. Anyone can implement an ACME server or client in any language. There is no "official" client or server necessary.

It's also important that Certbot was rebranded to distance it from Let's Encrypt because, personally, I think the project is doomed to fail. It tries to handle both certificate issuance and configuration of software using certificates. It attempts to abstract the process for someone who barely understands what certificates/SSL/TLS are (if at all), but requires so much detail from them in order to configure and run the client that they might well have just learned how it worked in the first place. In other words, Certbot's use case targets laymen, but requires non-layman understanding to use. It doesn't help that their documentation is very badly organized and confusing, often mixing content for the CLI and the Python Library, which have different audiences: end users and developers building an automated tool in Python.

Meanwhile, intermediate and advanced developers and system administrators who understand the concepts are much better served by a different client that simply takes care of certificate issuance without trying to automatically manage the software they will be using the certificate with. There are many, but so far I've been happy with Lego (https://github.com/xenolf/lego).

I think your criticisms were pretty fair of the earliest releases of the Let's Encrypt client, but they seem to be less accurate now. We see the client (aka Certbot) being used successfully by many hundreds of thousands of site operators. In terms of full automation, the Apache plugin has gone from "experimental" to "works for most people automatically". We'll be working on delivering similar features for Nginx next.

But if lego works for you; that's great!

Does Certbot have the ability to only output the signed certs to a specified directory and nothing more?

At the moment you can get that behaviour with "certonly --csr". You'll need to make a CSR file yourself. It'll drop your cert and chain files in the current directory. You'll still have an account key and some other ACME protocol housekeeping state in /etc/letsencrypt.

https://github.com/certbot/certbot/issues/2373 will track implementation a nicer version of that functionality; it'll probably be --no-lineages (lineages are Certbot's notion of a succession of renewed or updated certificates that replace each other; they live in /etc/letsencrypt/live, though you can put them somewhere else with the --config-dir option)

The large majority of sites using Let's Encrypt certificates are first-time users of SSL. So far they are succeeding with that demographic and one of their key goals was to spread SSL to previously unencrypted sites.

I use acme-tiny[0] and it was pretty simple to setup. The letsencryptclient requires running as root and quite a few dependencies if I remember correctly.

I have acme-tiny run with its own private user privilages monthly in a cron job and it's pretty slick. Only has access to the account key and writing to the http challenges and cert directories, no private key access.

[0] https://github.com/diafygi/acme-tiny Edit: clarification

The letsencryptclient does not need to run as root. I run it below its own user and group, and add that group to the http user to allow it to read the certificates and keys. Configuration at https://github.com/majewsky/system-configuration/blob/master... and https://github.com/majewsky/system-configuration/blob/master...

Permissions are more granular on your setup, though, as far as I can see.

The letsencryptclient (now renamed to certbot) runs `sudo apt-get install ...` even when running `--help`. I have a pull request that aims to fix that particular surprise: https://github.com/certbot/certbot/pull/2790

This should be fixed in the new release. For backwards compatibility we've kept the behavior of letsencrypt-auto the same, but certbot-auto will request (Y/N) permission before installing things.

For the many folks who want the previous behaviour, they'll need to run certbot-auto --non-interactive (-n for short).

Wow. That's a backdoor.

Trying to install stuff without the users permission, and using sudo without the users intent is really not right. How can we trust this if they do such things?

It looks like it is running a sudo command with a python script with scripts under a non-root user. This means that anyone who can write data to that non-root user folder can then run things as root.

ie. I can drop in a .py file and execute whatever code I want. Code run with sudo should not allow this.

The backdoor is `sudo` and if you allow passwordless `sudo` then any program you execute has permissions to run code as root. If you require a password to `sudo` then there's less of an issue as even the LetsEncrypt client would require you to grant permissions to `apt-get`.

That all said, it's still bad form to `apt-get -y` when run with a `--help` flag. Particularly with the `-y flag`. Even if you trust LetsEncrypt (and most of us would), it's still unexpected / non-idiomatic behavior and the `-y` flag means users don't get much time to cancel the operation should any output concern them.

This is a discussion about letsencypt-auto, not the underlying letsencrypt/certbot program. Here's what the docs said about letsencrypt-auto:

"Because not all operating systems have packages yet, we provide a temporary solution via the letsencrypt-auto wrapper script, which obtains some dependencies from your OS and puts others in a python virtual environment: <instructions to download and run letsencrypt-auto>"

If users don't read the label before downloading and running a script, they might be surprised by what it does. But we've learned that users don't read those instructions and get upset anyway, so cerbot-auto now asks for additional interactive permission before installing things.

Like I said, I haven't used the their client, just going off what I've come across in researching it briefly. Something must have changed then, there are multiple ways to configure it, or what I read previously was just wrong.

I thought that was why repos like https://github.com/diafygi/letsencrypt-nosudo existed for a time.

That's good news nonetheless.

Yes, there are definitely multiple ways to configure it. We focused first on working successfully for as many people as possible, which meant shipping the letsencrypt-auto wrapper script which requires sudo.

But with some extra work you can definitely run Certbot as a non-root user, and we're working with the OSes that package us to have Certbot operate with something like ssl-cert group privileges in many situations in the future.

I understand and had that idea when I heard it needed sudo initially. It makes sense for a reference-ish implementation to make it quick and easy for the large userbase to adopt. If I had to trust an org to run their code as sudo on my rig, EFF would probably be it. HTTPS needs to be adopted universally first and foremost.

I just chose Acme-tiny because it was tiny and didn't have many of the bells and whistles like wrapping revocation or a DNS verification that I didn't need. Neat and nifty features for certain, but I try to keep it stupid simple. I wanted something with a small footprint I could understand and domesticate.

Thanks for all your work, the EFF is awesome and so is Certbot. Letsencrypt has been a lifesaver. Keep up the good work!

One problem I have with this tool is support for pre-computed public keys or CSRs. The client prefers to generate a new key pair for every certificate. Automated renewal that works the same way for existing CSRs as it does for regular certificates requires undocumented hacks.

Using the same key pair for multiple certificates is necessary for public key pinning, since Let's Encrypt only issues certificates that last 90 days. I would love to see this feature get developed further.

It's worth pointing out here that reusing a static keypair with Let's Encrypt is currently more or less straight-forward using acme-tiny.

https://github.com/diafygi/acme-tiny

Edit: Looks like https://github.com/lukas2511/letsencrypt.sh is capable of doing the same, as pointed out in another comment.

There is code in the client to reuse a keypair when renewing (without needing to reuse a CSR); there's just no way to trigger that from the UI so far. Maybe I'd better add one soon.

https://github.com/certbot/certbot/issues/2373 (if you want to reuse a CSR; reusing the key is probably easier)

> Using the same key pair for multiple certificates is necessary for public key pinning, since Let's Encrypt only issues certificates that last 90 days.

So do like Github does (did?)[0], and make the pins valid for 5 minutes.

[0] looks like they upped it to 60 days?

> So do like Github does (did?)[0], and make the pins valid for 5 minutes.

That kinda defeats the point of HSTS. If the key is changing regularly, it makes it easy for an attacker to just temporarily prevent access to the site for long enough for the pin to timeout, and then present their own certificates and keys.

Perhaps you mean HPKP, not HSTS?

Yes, sorry, HPKP.

I've found acmetool perfect for my use and this table explains why: https://github.com/hlandau/acme#comparison-list-of-client-im...

The biggest feature the official letsencrypt client was missing was triggering restarts of other services after certificate renewal.

Hooks to perform arbitrary restarts and housekeeping upon renewal were added in version 0.5.0. Run with "--help renew" and/or see https://certbot.eff.org/docs/using.html#renewal

For people that want something much smaller (dependency-wise), I can recommend letsencrypt.sh which – together with cron – achieves the same goal: https://github.com/lukas2511/letsencrypt.sh

letsencrypt.sh is great. It has easy support for existing CSRs and can do dns-01 verification (i.e. making sure you control the domain via a DNS secret rather an http get path/secret). I wrote up a usage tutorial for the latter with Route53 here https://blog.boldlisting.com/free-ssl-certificates-without-p...

This is the new name of what was previously known as the official Let's Encrypt client.

Which was a lot more straight forward, so why change it to something obscure? (I mean "Let's Ecrypt" is a well positioned brand and since this is all about trust, why introduce a new name?)

Because it's supposed to be independent of the Let's Encrypt brand, with Let's Encrypt hopefully being one of multiple providers of CAs speaking the ACME protocol and this client being one of many clients compatible with them.

There has been a lot of misunderstanding and FUD about how you can use Let's Encrypt because of the relatively heavy and by default "invasive" official client. This hopefully helps to make it clearer that it is one option of many.

The official client (now Certbot) actually supports a whole bunch of different use cases; some people want full automation of everything; other people find that "invasive". The software supports both, but people would often find the wrong instructions. The new Certbot landing page tries to do a much better job of giving people instructions that are tailored to their use case and needs. Please try it and send us feedback!

https://certbot.eff.org

"Since it doesn't seem like your operating system has a packaged version of Certbot, you should use our certbot-auto script to get a copy:

    wget https://dl.eff.org/certbot-auto
    chmod a+x certbot-auto

"certbot-auto accepts the same flags as certbot; it installs all of its own dependencies and updates the client code automatically."

I don't know whether to be terrified or horrified.

certbot-auto (previously known as letsencrypt-auto) is definitely a hack -- it allows people to run the client on typically older OSes that don't have backported native packages. It's basically a tiny autoupdate and packaging system written in bash and python. It uses airgapped signatures for updates, checks sha256 hashes for all of the python dependencies it's installing, and puts them into a python virtual environment so that they don't affect your OS.

If you don't like wget; chmod, you can check a gpg signature too: https://certbot.eff.org/docs/intro.html#installation

Oh, and it's in use on 500K - 1 million webservers. So extra eyes auditing it are always welcome :)

Given the emphasis on full automation in Let's Encrypt, it's really baffling that the official client lacks DNS-based support at this time. Anyone behind a load balancer like AWS ELB can't really use it.

HTTP-01 verification works quite well behind load balancers - it's a simple GET request to a specific URL.

You're probably thinking of TLS-SNI-01, which requires changes on the host that's terminating TLS (which isn't possible on a load balancer unless it has dedicated support for ACME).

> HTTP-01 verification works quite well behind load balancers - it's a simple GET request to a specific URL.

Running the client on one of the servers frequently results in it hitting one of the other servers in the cluster. It's a pain in the ass - you either rely on luck and retry a number of times until it hits the right server, or you have to go the more manual route and deploy the challenge directory to all of the servers.

DNS doesn't care how many servers there are, as long as there's the right record in place.

You can work around that fairly easily by having a permanent redirect (HTTP 301) for /.well-known/acme-challenge/* to a dedicated validation server (which might just be certbot in HTTP-01 standalone mode).

Now that's an interesting idea I'll have to play with. Thanks!

We're working on it: https://github.com/certbot/certbot/issues/2782

This along with IPv6 are probably one of the two most visible issues right now.

IPv6 support has recently been completed in Boulder (the LE CA software) already:

https://github.com/letsencrypt/boulder/issues/593

That was the main blocking issue. IPv6 in LE is coming very soon.

Same. The current approach of placing a file on a HTTP endpoint is basically a joke, right?

Can you please explain why that is a joke? (I am assuming you are saying the LE verification isn't secure)

Wow, that's really cool. I remember digging through the documentation for days to get everything set up on my systems (nginx on Arch Linux). Now this thing gives me the same information in just two clicks, which is a massive improvement.

An official client implies that other implementations of the standard are unofficial. Building a monoculture around a single client isn't healthy for the project, and nobody wants to put an unofficial client into their security infrastructure.

This blog post[1] explains the motivation behind the name change (and moving the project to the EFF).

[1]: https://letsencrypt.org/2016/03/09/le-client-new-home.html

I had been interested in Let's Encrypt, but hadn't dove in. This makes implementation alot more compelling.

Reply on news.ycombinator.com