My stance on Let's Encrypt

Recently I was asked by someone as to why I was using Let's Encrypt. The question came from someone who has been in the business for long, and is used to the world of the ancient CA giants. It was filled with a fully misinformed sense of distrust and prejudice towards Let's Encrypt.

In my opinion, this distrust is completely misplaced. In fact, I think that Let's Encrypt has so far been more trustworthy than many of its CA-peers.

Free is not cheap!

Let's get one thing straight. The fact that Let's Encrypt is free, does not mean it is cheap.

It is still a certificate authority that has employees, infrastructure costs, and, additionally, needs to pay for audits to remain in the web of trust.

To pay for this, it relies on donations. And it gets those: Millions of dollars of them, from world-leading companies. Amongst which are Google (Chrome), Mozilla (Firefox, Thunderbird) and Microsoft (Internet Explorer, Edge). But also Facebook, the company behind WordPress (Automattic) and many, many more.

All of these companies wish for the project to succeed. A project that is a collaborative project of the Linux Foundation.

Auditable open source CA software

They are using software they wrote themselves: Boulder. It is open source, can be used by anyone, and be audited by anyone. This means that any company can extend their audit chain, all the way to the root issuer of their certificates.

Better validation systems in place

Ancient CA's often use e-mail validation. Send an e-mail to an address they often invented and might be going to one of your users if you offer e-mail on your main domain. This has caused many problems in the past, and should, in my opinion, never be used.

Some of the CA's did not even do proper validation. WoSign had its own audit company, and both WoSign and StartCom got caught issuing certificates they shouldn't have.

Let's Encrypt does things differently, and offers two validation methods:

You will use a locally generated private key for your requests to Let's Encrypt's API.
With this, you can request certificates, and you would do the following (example of HTTP-validation):

  1. Generate a private key (most clients use 4096 bits).
  2. Generate a signing request with the CN and SAN (SAN is mandatory).
  3. For hostname in list of hostnames: a. Request challenge. If CA responds with "valid", the host is already validated. Next. b. CA will tell you what to call the token file name, and what value to put it in.
    Save file in your publicly available /.well-known/acme-challenge directory. c. Tell the CA that the validation token is in place. d. CA verifies the token it sent you is available from http:///.well-known/acme-challenge/ e. Token is validated, token-file can be removed. Next.
  4. After all hostnames have been validated, ask the CA to issue your certificate.
  5. Save certificate files and optionally deploy them.

Alternatively, for DNS-validation, you would use a hook-script or manual interaction to save them to a DNS-record to prove ownership. The HTTP-validation opens a world of possibilities, and makes it very easy to do it on a per-host basis.

Starting in january 2018, they will also offer wildcard certificates. for this you will need to use DNS-validation.

CAA: Explicit validation only

As per the CA-forum's agreement, CA's are allowed to treat resolving failures as permission to issue a certificate for your domain. That means that if your resolver is giving timeouts or refuses connections, this can give green light to CA's to issue certificates for your domain if they can't resolve a CAA record.

Let's Encrypt does not do this. If a CAA record does not exist, it will do business as usual. If a resolver failure occurs (timeout, refused), it will consider it as fatal, and not allow issuance of the certificate. This, in my opinion, is a lot safer.

Active on IRC

Developers of Let's Encrypt (as well as very active and knowledgable users) are on IRC. They are very friendly and are very happy to share their knowledge with anyone who wants to know. The Let's Encrypt people that are there are also usually very responsive. This meant in the past that if issues with the CA arose, they were fixed in matter of minutes where possible.