All posts
6 min read

How Automatic SSL Actually Works (and Why It Sometimes Doesn't)

The padlock in the browser comes from a certificate that has to be issued, installed, and renewed on a schedule that keeps getting shorter. How Let's Encrypt and ACME prove you own a domain, how tools like Traefik and Caddy automate it, and the five reasons a certificate fails to issue or renew.

infrastructuredomainssecuritydeployment

Most modern hosts give you HTTPS automatically: you point your domain at them, wait a minute, and the padlock appears. It's easy to forget there's anything happening at all — until a certificate fails to renew and every visitor gets a full-page browser warning telling them your site is dangerous.

Understanding how automatic certificates work makes those failures easy to diagnose. It's also more relevant than ever, because certificates are getting shorter-lived, and anything that isn't fully automated is running out of time.

What a certificate is for

An SSL/TLS certificate does two jobs:

  1. Encryption — traffic between the browser and your server can't be read or altered in transit.
  2. Identity — the browser can confirm it's really talking to yourapp.com, not an impostor.

The identity part is why certificates must be issued by a certificate authority (CA) that browsers trust, and why the CA must check that you control the domain before issuing one.

Let's Encrypt and ACME

Let's Encrypt is a free, non-profit certificate authority, and a large share of the web uses it. It issues certificates automatically using a protocol called ACME. Other CAs support ACME too.

The flow, which your server or proxy runs for you:

  1. Your server generates a key pair and asks the CA for a certificate for yourapp.com.
  2. The CA says: prove you control that domain. Here's a challenge.
  3. Your server completes the challenge.
  4. The CA verifies it and issues the certificate.
  5. Your server installs it, and schedules renewal well before it expires.

The three ways to prove you own a domain

HTTP-01. The CA gives your server a token and asks for it at http://yourapp.com/.well-known/acme-challenge/<token>. The CA fetches that URL from the internet; if the token is there, you've proved control. The most common method. It requires your domain to already point at the server, and port 80 to be reachable from the internet.

TLS-ALPN-01. Similar, but the proof happens during a special TLS handshake on port 443. Useful when port 80 isn't available.

DNS-01. The CA asks you to create a specific TXT record at _acme-challenge.yourapp.com. Your tooling does this through your DNS provider's API. This is the only method that can issue wildcard certificates (*.yourapp.com), and it works for servers that aren't reachable from the internet at all. The trade-off: your server needs an API key for your DNS provider, which is a powerful credential to hold.

How tools automate it

Web servers and reverse proxies like Caddy and Traefik have ACME built in. You tell them which domains to serve, and they obtain certificates, store them, and renew them on their own. cert-manager does the same for Kubernetes, and certbot is the classic standalone client for servers running Nginx or Apache.

With Traefik, for instance, a route for your domain plus a configured certificate resolver is enough: the first request for a new domain triggers issuance, and renewal happens in the background.

Certificates are getting shorter-lived

Let's Encrypt certificates have long been valid for 90 days. That's shrinking. Let's Encrypt already offers opt-in shorter certificates — including 45-day and 6-day options — and has announced that its default will reach 45 days by February 2028, in line with industry-wide rules that shorten maximum certificate lifetimes.

The reasoning is sound — a compromised or mis-issued certificate is dangerous for less time — but the practical consequence is blunt: manual renewal is no longer viable. Any certificate that's renewed by a person with a calendar reminder will eventually expire. Automated renewal, with monitoring to catch failures, is the only approach that scales.

Why issuance or renewal fails

When the padlock breaks, it's almost always one of these.

1. DNS doesn't point at the server (yet)

HTTP-01 challenges go to wherever your domain's DNS currently points. If you've just changed DNS and it hasn't propagated, or there's a leftover record pointing somewhere else (an old AAAA record for IPv6 is a classic), the CA reaches the wrong server and the challenge fails. Check both A and AAAA records. (How to Connect a Custom Domain to Your App covers DNS records.)

2. Port 80 is blocked

A firewall rule that allows only 443 "because we're HTTPS-only" breaks HTTP-01. Port 80 must stay open for challenges — the server can redirect all other port-80 traffic to HTTPS.

3. A CAA record forbids the CA

A CAA DNS record lists which certificate authorities may issue for your domain. If one exists and doesn't include the CA you're using, issuance is refused. Useful security control; confusing when you forgot it was there.

4. Rate limits

Let's Encrypt limits how many certificates you can get — for example, a cap on certificates per registered domain per week, and a small limit on repeatedly issuing the exact same certificate. You'll only hit them by accident, typically from a misconfigured setup that requests a new certificate on every restart because it isn't storing the ones it gets. Make sure certificates are saved to persistent storage. Use Let's Encrypt's staging environment while testing new setups.

5. The certificate store was lost

A container that stores certificates in its temporary filesystem loses them on every redeploy and requests new ones — heading straight for rate limits. Mount the certificate storage (for Traefik, its acme.json file) on a persistent volume. Docker Volumes vs Bind Mounts explains the options.

Monitoring certificates

Automation fails quietly. Two cheap safeguards:

  • Expiry monitoring. Most uptime services warn you when a certificate is within a couple of weeks of expiring. If renewal is working, you never see the alert. If you do see it, you have time to fix things. (How to Know When Your App Is Down.)
  • Watch the logs of whatever does your renewals. A failed renewal attempt is logged long before the certificate actually expires.

The checklist

  • Domain's A (and AAAA, if any) records point at the right server
  • Port 80 reachable for HTTP-01 challenges (or use DNS-01)
  • No CAA record blocking your CA
  • Certificates stored on persistent storage
  • Staging environment used while testing a new setup
  • Expiry monitoring with alerts

EasySpawn issues and renews certificates automatically through Let's Encrypt and Traefik for every domain you connect — you point DNS at it, and certificates are never your problem. See how it works or join the waitlist.

Related: How to Send Email From Your App Without Landing in Spam · Self-Hosting Next.js Without Vercel · What Is HTTPS? · Reverse Proxies Explained

Keep reading