Let's Encrypt - What Free Universal HTTPS Actually Changes

On April 12, the Internet Security Research Group flipped the switch and Let's Encrypt left public beta. Free, automated, ninety-day TLS certificates, issued by an intermediate that chains to a root every modern browser already trusts. After eighteen months of beta, this is now production infrastructure.

The headline reads as a price-tag story — TLS certificates used to cost between thirty and several hundred euros a year, and now they don't. The price-tag reading misses the point. The actual change is automation. A free certificate that expires in ninety days is structurally different from a paid certificate that expires in three years, and the difference reshapes how you operate web infrastructure.

What ACME actually is

Let's Encrypt does not give you a certificate because you ask. It gives you a certificate because you prove control of a domain through an automated protocol called ACME (Automated Certificate Management Environment). The proof takes one of two forms:

• HTTP-01 challenge: the CA gives you a token, you serve it at a specific URL on the domain over HTTP, the CA fetches it and confirms.
• DNS-01 challenge: the CA gives you a token, you publish it as a TXT record on the domain, the CA queries DNS and confirms.
  Both prove the same thing: that whoever is requesting a certificate for example.com has administrative control of either the web server or the DNS for that domain. There is no human in the loop. There is no faxed corporate document. There is no waiting room.

This is also why the certificates last ninety days and not three years. Short lifetimes are only tolerable when renewal is automated. Automated renewal is only feasible when issuance is automated. The two design choices reinforce each other.

The tooling, today

The official client is letsencrypt-auto, distributed from the project's GitHub repository. On Debian 8 Jessie, the simplest path is to clone the repo and run the bootstrapper, which installs Python dependencies into a virtualenv:

1git clone https://github.com/letsencrypt/letsencrypt /opt/letsencrypt
2cd /opt/letsencrypt
3./letsencrypt-auto --help

For an existing nginx site at /var/www/example.com with the public-facing vhost listening on port 80, the webroot plugin handles the HTTP-01 challenge without touching your nginx config:

1./letsencrypt-auto certonly \
2    --webroot \
3    --webroot-path /var/www/example.com \
4    --email admin@example.com \
5    --agree-tos \
6    --domain example.com \
7    --domain www.example.com

The certificate, chain, and private key end up under /etc/letsencrypt/live/example.com/. Wire them into your nginx server block:

 1server {
 2    listen 443 ssl http2;
 3    server_name example.com www.example.com;
 4 
 5    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
 6    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
 7 
 8    ssl_protocols TLSv1.2;
 9    ssl_ciphers HIGH:!aNULL:!MD5;
10    ssl_prefer_server_ciphers on;
11 
12    # ...
13}

Renewal is the part you actually have to think about. The recommended pattern is a cron job running twice daily, which is no-op until renewal becomes due:

10 */12 * * * /opt/letsencrypt/letsencrypt-auto renew --quiet --post-hook "systemctl reload nginx"

Twice daily because the renewal logic is conservative — it only acts if a certificate is within thirty days of expiry — and a twice-daily check insulates you from one failed run.

The chain-of-trust note

The certificates Let's Encrypt issues today are signed by their intermediate, which is itself cross-signed by IdenTrust's DST Root CA X3. That cross-signature is what makes Let's Encrypt certificates usable on browsers and devices that haven't yet added the ISRG Root X1 to their own trust stores — which, today, is most of them. The dependency on IdenTrust is temporary, and Let's Encrypt has been clear that the long-term goal is for ISRG Root X1 to be trusted in its own right. For now, the cross-signature is what lets you deploy this on a 2010-vintage Android device and have it work.

The rate limits

Let's Encrypt's rate limits are public and worth reading before you scale anything. The limits that matter for most operators:

• 20 certificates per registered domain per week
• 5 duplicate certificates per week
• 100 names per certificate (SAN limit)
• 500 accounts per IP per 3 hours
  If you're running a single domain with a handful of subdomains, you will not approach these. If you're running a multi-tenant platform that issues per-customer certificates, you absolutely will, and you need to plan for it.

Failed validations also count against you, so test against the staging endpoint (acme-staging.api.letsencrypt.org) before going live with new automation. The staging certificates are not browser-trusted, but the protocol is identical, and you can break things there at no cost.

What this changes

Before April 12, the cost of TLS — financial and operational — was a real argument against universal HTTPS. Operators ran HTTPS only where they had to, mostly login pages and payment forms, and served everything else over plaintext HTTP. The argument was never good, but it was coherent.

After April 12, the argument disintegrates. Free, automated, browser-trusted certificates are available to anyone with shell access to a server and a domain. The remaining barriers — configuring TLS correctly, managing renewal, handling certificate rollover — are real, but they are operational problems, not financial ones.

The expectation is shifting accordingly. Within a year or two, plain HTTP will be the suspicious choice. Browsers are already adding "Not Secure" indicators for password fields on HTTP pages. The trajectory is one-way.

What it does not change

Let's Encrypt issues domain-validated certificates — DV. Not OV (organization-validated), not EV (extended-validation, the kind that used to paint the URL bar green). For most use cases, DV is sufficient: it proves what TLS actually proves, which is that you are talking to the holder of the domain, encrypted and authenticated. EV proves something more — that the holder is a specific legal entity with the registered name shown — and there are operators who legitimately need that, mostly banks and exchanges. They will continue to pay commercial CAs. The Let's Encrypt model does not extend to EV by design, because the validation can't be automated.

The other thing Let's Encrypt does not solve is operational competence. A free certificate on a server with bad cipher suites, weak Diffie-Hellman parameters, or a private key checked into a git repository is not secure. The job is now cheaper, not finished. Run your config through testssl.sh or the Qualys SSL Labs analyser before declaring victory.

The summary

A small, technically-focused non-profit just made commercial HTTPS obsolete for ninety percent of use cases. The price drop is the visible change. The structural change is automation: short-lived certificates that you renew by code, not by procurement, and that are issued through a protocol any reasonable language can implement against.

If you operate a server that serves any traffic at all, the question is no longer whether to deploy HTTPS. It is what is keeping you from deploying it tonight.