Learn PKI - ACME Protocol & Let's Encrypt

#Introduction

In the previous episode, episode 7, you installed server certificates and built mTLS manually. That is fine for one or two servers, but imagine repeating the same steps for a hundred servers: creating a CSR, signing, installing, then remembering all the expiry dates. Automation is no longer an option, it is a necessity. Episode 8 is the turning point from manual to automatic.

ACME (Automatic Certificate Management Environment) is the answer to that problem. This standard, documented in RFC 8555, allows a client to request, receive, and renew certificates without human intervention. You will see how a certificate is born from an order, passes a challenge, gets validated, then is issued within minutes.

This episode's roadmap: first we dissect the ACME workflow, second we compare the three challenge types, third we discuss External Account Binding, fourth we practice Let's Encrypt with certbot, and finally we look at the trend of short-lived certificates plus ACME Profiles.

#ACME Protocol and RFC 8555

#Why ACME Is Needed

Before ACME, issuing a certificate meant contacting a CA, proving domain ownership via email or file upload, then waiting. For a certificate valid for a year, that manual process was still tolerable. But as the industry began shrinking validity periods, automation became the only sensible way.

ACME automates that entire flow: account registration, order creation, domain ownership proof, up to certificate download. An ACME client running on the server can request new certificates and renew old ones without human interaction.

#The ACME Workflow

The ACME flow can be simplified into several sequential stages. Understanding these stages is important because every real-world problem — certificates not being issued, validation failing — can always be traced to one of these stages.

1. Account: the client creates an account on the ACME server with its own key pair.
2. Order: the client sends an order request containing a list of identifiers, for example domain names.
3. Challenge: the ACME server responds with a list of challenges the client must complete to prove domain ownership.
4. Validation: the client prepares proof according to the challenge type, then the server verifies that proof.
5. Issue: after all challenges are valid, the server issues the certificate and the client downloads it.

Notice the position of the key in the Account stage. This account key matters: the certificate issued later is signed with a key bound to the account, so automatic renewal can only be done by the same account owner.

#Challenge Types

ACME defines several ways to prove domain ownership. Each has its own strengths and limitations. Choosing the right type is often an architectural decision, not merely a technical one.

HTTP-01 is the simplest. The client places a token at the URL /.well-known/acme-challenge/ on port 80, and the ACME server visits that URL to verify. This validation only proves control over port 80, not over the entire server.

curl -s http://example.com/.well-known/acme-challenge/abc123token

DNS-01 works through DNS records. The client creates a TXT record named _acme-challenge.example.com containing a token, and the ACME server reads that record. Because verification happens via DNS, this type supports wildcard certificates that HTTP-01 cannot serve.

dig TXT _acme-challenge.example.com +short

TLS-ALPN-01 uses port 443 with a special ALPN protocol named acme-tls/1. The ACME server performs a TLS handshake and checks the token inside the temporary certificate. This type is useful when port 80 is blocked and the client uses SNI.

openssl s_client -connect example.com:443 -alpn acme-tls/1

All three types above are equally valid, but their use depends on the environment. HTTP-01 is easiest to start with, DNS-01 is required for wildcards and is the most flexible, while TLS-ALPN-01 suits special situations with limited ports.

#External Account Binding

By default, an ACME account is not bound to any external account — anyone can create an account and request certificates, limited only by rate limits. External Account Binding (EAB) changes that: the ACME account is bound to an account already registered at the CA via a key identifier and an HMAC key.

EAB is commonly used by CAs to prevent abuse and enforce issuance policy. When using EAB, the client must include the EAB credentials on every request. Certbot supports it via the --eab-kid and --eab-hmac-key options.

certbot certonly --standalone --preferred-challenges http \
  --eab-kid key-identifier \
  --eab-hmac-key hmac-secret \
  -d example.com

Never share the EAB HMAC key. It is a secret equivalent to your CA account password. Store it in a secret manager, not in a configuration file anyone can read.

#Let's Encrypt and Certbot

#Getting to Know Let's Encrypt

Let's Encrypt is a public Certificate Authority that issues TLS certificates for free and automatically via ACME. It is operated by the Internet Security Research Group and runs at no cost — funded by sponsors and donations, not by certificate sales. Its root CA is already embedded in all modern operating systems and browsers.

For you, Let's Encrypt is attractive for two reasons: free and fully automatic. What makes it stand out is its 90-day validity policy — far shorter than commercial certificates that can last years — as a way to force the ecosystem to always renew certificates before expiry.

#Rate Limits

Because it is free, Let's Encrypt must protect itself from abuse. It applies rate limits per account, per domain, and per network. For example, there are limits on the number of duplicate certificates per week, the number of new certificates per domain per week, and the validation failure limit per hour.

Rate limits are nothing to fear as long as your automation is healthy. Problems arise when you repeatedly request the same certificate manually. Remember the rule of thumb: renew via certbot renew, do not recreate certificates from scratch, and avoid uncontrolled certificate requests for testing.

#The 90-Day Lifecycle

A 90-day certificate is not about adding work, but about shrinking the risk window. A revoked or compromised certificate only survives at most 90 days. And with a short validity period, automation becomes a discipline: you can no longer rely on a manual annual ritual.

In practice, certificates are renewed not at expiry but midway through their validity. Certbot renews automatically about 30 days before expiry, so there is always room for a few retries if validation fails.

#Installing and Using Certbot

Certbot is the most popular ACME client, developed by the Electronic Frontier Foundation. It has plugins for many web servers, including Nginx, so it can modify the TLS configuration and issue the certificate at the same time.

apt install certbot python3-certbot-nginx
certbot --nginx -d example.com -d www.example.com

The certbot --nginx command above issues a certificate for two domains at once and installs it into the Nginx configuration. Certbot also writes a renewal script to be used later. To only issue without changing the configuration, use certonly mode.

#Auto-Renewal

Automation at Let's Encrypt does not stop at issuance. Certbot ships with a timer that runs certbot renew twice a day, and that command only renews certificates already within the renewal window. So running it many times is harmless — it is idempotent.

certbot renew --quiet

Make sure the renewal timer is active on your system. If you run certbot inside a container or a custom scenario, move the renewal logic into your own cron or pipeline, because ignoring renewal is the most common cause of unexpected certificate expiry.

#Short-Lived Certificates and ACME Profiles

The industry keeps moving toward shorter validity periods. After 90 days became the standard, the next topic of discussion is 6-day certificates. The logic: if a certificate is stolen or a CA is breached, the vulnerable window is only a matter of days, and automation failures are quickly visible. Most infrastructure CAs, including step-ca, already apply similar practices.

To support that scenario, ACME Profiles are being normalized through an IETF draft. The concept is simple: an ACME server can define named profiles carrying a set of policies — for example validity period, key type, or allowed domain list — and clients simply request the profile by name. This simplifies administration and prevents clients from sending disallowed parameters.

#Closing

Episode 8 changes how you view certificates: not as static artifacts managed once a year, but as a dynamic lifecycle that runs automatically. You mastered the ACME flow from order to issuance, distinguished the three challenge types, understood EAB, then practiced Let's Encrypt with certbot along with its rate limits and auto-renewal.

Key takeaways:

• ACME RFC 8555 automates the entire order, challenge, validation, and issuance cycle.
• HTTP-01 needs port 80, DNS-01 is for wildcards, TLS-ALPN-01 uses port 443.
• EAB binds the ACME account to an external account to prevent abuse and enforce CA policy.
• Let's Encrypt issues free certificates with a 90-day validity and per-domain rate limits.
• Auto-renewal with certbot renew is idempotent and only touches certificates nearing expiry.
• Short-lived certificates and ACME Profiles shrink the vulnerable window while forcing healthy automation.

In episode 9, you will see the modern side of all this from a private CA perspective. We will learn step-ca from Smallstep, build your own CA that speaks ACME and many other protocols, complete with provisioners, template-based issuance, and SSH certificate authority. See you there!