
Announcing Certbot: EFF's Client for Let's Encrypt - schoen
https://www.eff.org/deeplinks/2016/05/announcing-certbot-new-tls-robot
======
hackuser
> 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.

~~~
a_imho
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](https://www.eff.org/document/fy-2014-statement-activity)

~~~
zeroxfe
> 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.

------
Perceptes
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](https://github.com/xenolf/lego)).

~~~
pde3
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!

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

~~~
pde3
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](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)

------
jalami
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](https://github.com/diafygi/acme-
tiny) Edit: clarification

~~~
majewsky
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...](https://github.com/majewsky/system-
configuration/blob/master/hologram-letsencrypt.pkg.toml) and
[https://github.com/majewsky/system-
configuration/blob/master...](https://github.com/majewsky/system-
configuration/blob/master/hologram-nginx.pkg.toml)

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

~~~
Flimm
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](https://github.com/certbot/certbot/pull/2790)

~~~
illumen
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.

~~~
laumars
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.

------
nickfrostatx
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.

~~~
theandrewbailey
> 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?

~~~
oarsinsync
> 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.

~~~
pde3
Perhaps you mean HPKP, not HSTS?

~~~
oarsinsync
Yes, sorry, HPKP.

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

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

~~~
pde3
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](https://certbot.eff.org/docs/using.html#renewal)

------
jbergstroem
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](https://github.com/lukas2511/letsencrypt.sh)

~~~
emilong
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...](https://blog.boldlisting.com/free-ssl-certificates-without-
placing-a-file-on-your-server-using-aws-route53-31035f8fca14)

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

~~~
WhatsName
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?)

~~~
detaro
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.

~~~
pde3
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](https://certbot.eff.org)

~~~
ceejayoz
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.

~~~
pfg
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).

~~~
ceejayoz
> 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.

~~~
pfg
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).

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

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

