Blog / Let's Encrypt Is Out of Beta — Free HTTPS for Everyone (and a New Way to Fail)
ssl lets-encrypt https automation

Let's Encrypt Is Out of Beta — Free HTTPS for Everyone (and a New Way to Fail)

Let's Encrypt left beta with millions of free certificates issued. How ACME automation works, setting up Certbot with nginx — and the new silent failure mode.
The CompleteStatus Team · · 6 min read
Let's Encrypt Is Out of Beta — Free HTTPS for Everyone (and a New Way to Fail)
Want this checked continuously?
CompleteStatus grades your headers, SSL and email security 24/7 — free, commercial use allowed.
Monitor your site free

On April 12, Let's Encrypt quietly removed the word "beta" from its homepage. In the five months since its public beta opened in December, the free certificate authority has issued well over a million certificates — a number that took traditional CAs years to reach — and a meaningful share of them went to sites that had never had HTTPS at all. The project's stated goal is a 100% encrypted web, and for the first time that sounds less like idealism and more like a schedule.

If you've been waiting for Let's Encrypt to be "ready" before trusting it with your sites, this is the milestone you were waiting for. Here's what it is, how to set it up, why its unusual 90-day certificates are a feature rather than a nuisance — and the brand-new failure mode it introduces that you should start monitoring for today.

What Let's Encrypt actually is

Let's Encrypt is a certificate authority run by the non-profit Internet Security Research Group, with backing from Mozilla, the EFF, Akamai, Cisco and others. Three properties make it different from every CA before it:

  • Free. Domain-validated certificates cost nothing. The historical $50–$200/year toll on encryption is gone.
  • Automated. Certificates are issued and renewed by software speaking an open protocol called ACME — your server proves it controls the domain (typically by serving a challenge file), and the CA issues the certificate. No web forms, no approval emails, no human in the loop.
  • Short-lived. Certificates are valid for 90 days, not the one-to-three years the industry is used to. More on why below.

The official client recently got a new name, too: what launched as the letsencrypt tool is now Certbot, maintained by the EFF. Same job, better name, actively developed.

Setting it up: Certbot and nginx in a few minutes

The webroot method is the least invasive way to start — it doesn't touch your server config, it just drops challenge files where your existing site can serve them. First, make sure nginx will serve the challenge path:

server {
    listen 80;
    server_name example.com www.example.com;

    location /.well-known/acme-challenge/ {
        root /var/www/letsencrypt;
    }
}

Then request the certificate:

certbot certonly --webroot -w /var/www/letsencrypt \
    -d example.com -d www.example.com

Certbot proves domain control, and your certificate and key land in /etc/letsencrypt/live/example.com/. Point nginx at them:

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}

Reload nginx, and you're serving HTTPS with a certificate every major browser trusts. Renewal is one command — certbot renew checks all your certificates and renews any within 30 days of expiry — so the standard move is a cron job:

0 3 * * * certbot renew --quiet && systemctl reload nginx

Total cost: zero dollars and about fifteen minutes. If you've been putting off the HTTPS migration (the case for which we made in February), your last practical excuse just retired.

Why 90 days is a feature, not a bug

The short lifetime is the most-complained-about design decision, and it's the most deliberate one. The reasoning:

  • Shorter lifetimes limit damage. A compromised or mis-issued certificate is dangerous for as long as it's valid. Ninety days caps that exposure at three months instead of three years — revocation on the web being famously unreliable.
  • They force automation. Nobody wants to renew certificates by hand eight times over two years, so 90-day certs push you to automate — and an automated renewal is more reliable than a human calendar reminder, not less. The one-year certificate you installed manually is a time bomb with a long fuse; everyone forgets it until the browser warning appears.
  • Automation compounds. Once renewal is a cron job, adding HTTPS to the next site — or the next fifty — is trivial. This is how encryption becomes the default rather than a project.

The industry logic here is sound: manual certificate management is where expiry outages come from. Let's Encrypt is essentially forcing the fix.

The new failure mode: silent renewal breakage

Here's the part that deserves its own alarm bell. With traditional certificates, the failure mode was forgetting — a renewal date sails past unnoticed. With automated 90-day certificates, the failure mode is subtler: the automation itself breaks, and nothing tells you.

The ways it happens are all mundane:

  • The cron job was never installed on the new server after a migration — the certificate works perfectly for up to 90 days, then dies.
  • The webroot moved. A deploy restructured directories; the ACME challenge now 404s; every renewal attempt quietly fails.
  • A firewall or nginx change blocked port 80, which the challenge needs.
  • Certbot renewed the certificate but the reload didn't happen, so nginx keeps serving the old, expiring one from memory.
  • Rate limits or a client error stall renewals, and the error goes to a cron mailbox nobody reads.

Notice the shape of the problem: every one of these failures is invisible for weeks. The certificate remains valid the whole time — right up until the moment it isn't, at which point every visitor gets a full-page browser security warning, which is downtime in every way that matters.

The rule this implies: never let the system that renews the certificate be the only system that knows when it expires. Renewal automation should be verified from the outside, by something independent of the server, the cron daemon and Certbot itself.

Trust the automation — and verify it

An external check is the natural fit. CompleteStatus connects to your site from the outside exactly as a browser does, inspects the certificate actually being served — not the one on disk — and tracks its expiry date. If renewal breaks for any of the reasons above, the served certificate's remaining lifetime starts ticking down abnormally, and you get an alert weeks before expiry instead of a panicked morning after. It also catches the sneaky variant where renewal succeeded but the web server never reloaded.

Let's Encrypt just made HTTPS free for everyone; the right response is to encrypt everything and automate everything — then put one independent watcher on the result. Create a free account, add SSL monitoring to your freshly encrypted sites, and let the robots check the robots.

Stop checking by hand

CompleteStatus runs these exact checks around the clock — uptime, SSL, DNS, security headers and SPF/DKIM/DMARC — and alerts you the moment something changes. One dashboard, one bill.
Start free Run a free check
Uptime is table stakes. We watch the rest — security headers, email authentication, certs and DNS, with the fix attached.
Start free
Company
© 2026 CompleteStatus. All rights reserved. CompleteStatus — operated in the United States · support@completestatus.com