🤖Module 10 — ACME & Let's Encrypt: Automation Is Now Mandatory

{
    "PeiDSJ6MPvc": "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417",
    "keyChange": "https://acme-v02.api.letsencrypt.org/acme/key-change",
    "meta": {
        "caaIdentities": ["letsencrypt.org"],
        "profiles": {
            "classic": "https://letsencrypt.org/docs/profiles#classic",
            "shortlived": "https://letsencrypt.org/docs/profiles#shortlived",
            "tlsserver": "https://letsencrypt.org/docs/profiles#tlsserver"
        },
        "termsOfService": "https://letsencrypt.org/documents/LE-SA-v1.8-July-06-2026.pdf",
        "website": "https://letsencrypt.org"
    },
    "newAccount": "https://acme-v02.api.letsencrypt.org/acme/new-acct",
    "newNonce": "https://acme-v02.api.letsencrypt.org/acme/new-nonce",
    "newOrder": "https://acme-v02.api.letsencrypt.org/acme/new-order",
    "renewalInfo": "https://acme-v02.api.letsencrypt.org/acme/renewal-info",
    "revokeCert": "https://acme-v02.api.letsencrypt.org/acme/revoke-cert"
}

What to read out of this — there is a lot in eight lines.

• PeiDSJ6MPvc — that random-looking key is deliberate, and it is my favourite detail in the whole protocol. Let's Encrypt inserts a random entry into the directory specifically to break clients that hard-code URLs or that choke on unexpected fields. If your client crashes on this, it was going to crash the next time a real field was added. Follow the link in its value and they explain exactly that.
• newNonce exists because every ACME request must carry a single-use number (a nonce). That is what stops an attacker recording a valid request and replaying it later.
• newAccount, newOrder, revokeCert, keyChange — the four things you can do: register, ask for a certificate, revoke one, and rotate your account key.
• renewalInfo is ARI, standardised as RFC 9773 in September 2025. It lets the CA tell your client when to renew. Section C3.
• profiles — three certificate profiles: classic, tlsserver and shortlived. Part D.
• caaIdentities: ["letsencrypt.org"] is the name this CA looks for in your CAA DNS records — Module 11's subject.

🔑 The rule this teaches: fetch the directory, never hard-code an endpoint. Every URL above can change, and the CA has gone out of its way to punish clients that assume otherwise.

=== PRODUCTION ===
https://acme-v02.api.letsencrypt.org/acme/new-order

=== STAGING - use this for ALL testing ===
https://acme-staging-v02.api.letsencrypt.org/acme/new-order

What to read out of this.

• Two completely separate environments with separate accounts, separate rate limits, and separate CA hierarchies. A staging account does not exist in production and vice versa.
• Staging certificates are signed by an untrusted root ("Fake LE Root"), so browsers reject them. That is the point — you can issue as many as you like without polluting Certificate Transparency logs or burning your production quota.
• Staging limits are far higher. Production allows 50 certificates per registered domain per week (Part C2); staging is generous enough that you will not hit it while testing.

⚠️ This is the mistake to avoid above all others in this module. Debugging a broken ACME setup against production will exhaust your weekly quota in an afternoon, and then you cannot issue a real certificate for seven days — including the renewal that was already due. Test in staging, then switch one flag.

In certbot that flag is --test-cert (or --server with the staging directory URL). In acme.sh it is --staging. In lego it is --server.

ACME — Automatic Certificate Management Environment, RFC 8555 — is a protocol for getting certificates without a human being involved. The client proves control of a domain by completing a challenge the CA can verify automatically, and the CA issues a certificate in seconds.

Before it, obtaining a certificate meant filling in a form, emailing a CSR, waiting, paying, and installing the result by hand. That is fine annually and impossible at scale — and it is the process that produces expired-certificate outages, because it depends on somebody remembering.

Why it matters more every year: the CA/Browser Forum is cutting maximum lifetimes to 200 days in March 2026, 100 days in 2027 and 47 days in 2029. At 47 days, manual renewal is roughly eight times a year per certificate. ACME is not a convenience any more; it is the only viable process.

The design detail worth mentioning: everything starts from a directory — one JSON document listing every endpoint. Clients are expected to fetch it each time rather than hard-code URLs, and Let's Encrypt enforces that culturally by inserting a random entry into the directory to break clients that make assumptions about its shape.

/etc/letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory/8f3a.../private_key.json

/etc/letsencrypt/live/shop.example.com/:
lrwxrwxrwx 1 root root   43 Aug 20 09:12 cert.pem -> ../../archive/shop.example.com/cert1.pem
lrwxrwxrwx 1 root root   44 Aug 20 09:12 chain.pem -> ../../archive/shop.example.com/chain1.pem
lrwxrwxrwx 1 root root   48 Aug 20 09:12 fullchain.pem -> ../../archive/shop.example.com/fullchain1.pem
lrwxrwxrwx 1 root root   46 Aug 20 09:12 privkey.pem -> ../../archive/shop.example.com/privkey1.pem

What to read out of this.

• The account key is JSON, not PEM. ACME uses JWS — JSON Web Signature — so certbot stores the account key as a JWK. That is why you cannot read it with openssl pkey.
• The account key path contains the directory URL. acme-v02.api.letsencrypt.org versus acme-staging-v02... — separate accounts for separate environments, exactly as Exercise A1.2 said.
• Everything in live/ is a symlink into archive/. That is deliberate: your nginx config points at the stable live/ path, and renewal writes cert2.pem, cert3.pem into archive/ and re-points the symlink. Your config never changes.
• The four files are exactly Module 08's set: fullchain.pem and privkey.pem are what you configure; cert.pem and chain.pem are the split versions, with chain.pem being what ssl_trusted_certificate wants for OCSP stapling.

⚠️ Never point nginx at archive/. Those filenames change on every renewal, and your config will silently keep loading cert1.pem forever. Always use live/.

Identity, not authorisation. The account key signs every request so the CA knows who is asking, tracks rate limits against it, and can suspend it. It does not grant any right to a domain.

Every order still requires passing a challenge that proves current control of each name. So stealing an account key does not let an attacker obtain certificates for your domains — they would still have to place a file on your web server or create a DNS record.

What a stolen account key does allow: revoking your existing certificates, reading your order history, and burning your rate limits. Worth protecting, but the domain-control proof is the real security boundary.

The practical detail: the account key and the certificate key are different things and are constantly confused. The account key lives in /etc/letsencrypt/accounts/ as a JWK and never changes; the certificate key is per-certificate in live/<domain>/privkey.pem. Backing up only the certificates loses the account.

Simulating a certificate request for test.example.com
Performing the following challenges:
http-01 challenge for test.example.com
Waiting for verification...
Challenge failed for domain test.example.com
http-01 challenge for test.example.com

Certbot failed to authenticate some domains (authenticator: standalone).
The Certificate Authority reported these problems:
  Domain: test.example.com
  Type:   dns
  Detail: DNS problem: NXDOMAIN looking up A for test.example.com

Hint: The Certificate Authority failed to verify the temporary standalone
server certbot used for the challenge. Ensure the listed domains point to
this machine and that it can accept inbound connections from the internet.

What to read out of this — a failure is the right result here, and it is informative.

• Simulating a certificate request — --dry-run used staging and will discard whatever it gets. Nothing was issued and no production quota was touched.
• It failed at NXDOMAIN, which is correct: test.example.com does not point at your machine. The CA has to reach you, and this is the message you get when it cannot.
• Type: dns on an http-01 challenge surprises people. Before the CA can fetch http://your-domain/.well-known/... it must resolve the name. DNS failures therefore surface as challenge failures with a dns type even when you chose the HTTP challenge.
• The hint is unusually good. "Ensure the listed domains point to this machine and that it can accept inbound connections from the internet" is, in practice, the cause about 90% of the time.

🔑 Make --dry-run a habit. Run it after any change to your ACME setup, before the renewal is due. It exercises the entire path — DNS, firewall, web server, challenge, hooks — against staging, and costs nothing. The worst time to discover your renewal is broken is the day it needs to work.

1. Fetch the directory — one JSON document with every endpoint URL. Never hard-code these.
2. Register or look up an account, identified by an account key that signs every request.
3. Create an order listing the identifiers (domain names) you want.
4. The CA returns an authorization per name, each with challenges you may complete.
5. Complete a challenge — put a token file on port 80, or a TXT record in DNS — and tell the CA to check.
6. The CA validates, connecting back to your server or querying DNS.
7. Finalize the order by submitting a CSR; download the resulting certificate.
8. Deploy it and reload the service — which is not part of ACME and is where the outages come from.

The detail worth drawing out: the CSR arrives at the very end. Everything before it is about proving control. The CSR carries the key; the challenge carries the authority. They are deliberately separate.

And the practical habit: certbot --dry-run runs the whole flow against staging and discards the result, so you can verify DNS, firewall, web server and hooks without spending quota. Run it after every change — the worst time to find out renewal is broken is the day it must work.

=== what the CA would fetch ===
LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0.9jg46WB3rR_AHD-EBXdN7cBkH1WOu0tA3M9fm21mqTI

HTTP 200  content-type: application/octet-stream

What to read out of this.

• The content is <token>.<thumbprint> — the CA's random token, then a SHA-256 thumbprint of your account key. That second half is what stops one person completing a challenge on another person's behalf: the CA knows which account key the response must be bound to.
• The filename is the token itself, so the CA fetches a path it chose. You cannot pre-create it.
• Content-type does not matter. Let's Encrypt ignores it, which is why a plain static file works and no special web-server configuration is needed.
• It is plain HTTP with no certificate involved at all. That is deliberate — you are trying to get a certificate, so requiring one would be circular. It is safe because the token is single-use, random, and bound to your account key.

💡 The whole mechanism is a static file. Any web server that can serve a file from a directory can complete HTTP-01, which is why --webroot is the most robust certbot mode: it writes into a directory your existing server already serves, and never touches your config.

=== does anything have one right now? ===
(usually empty - records are removed after validation)

=== the CNAME delegation pattern ===
(empty unless that domain uses delegation)

=== what a wildcard certificate looks like ===
DNS:*.wikipedia.org
DNS:*.m.wikipedia.org
DNS:*.wikimedia.org
DNS:*.m.wikimedia.org

What to read out of this.

• _acme-challenge records are almost never present. They exist for seconds to minutes during validation and are then removed. Finding an empty result is the normal, healthy state — a stale record left behind usually means a failed run that never cleaned up.
• Those wildcards could only have come from DNS-01. Every *. entry in a publicly trusted certificate implies the operator proved control of the DNS zone. HTTP-01 and TLS-ALPN-01 physically cannot produce them.
• *.wikipedia.org and *.m.wikipedia.org both appear, which is Module 03's wildcard-depth rule (B3) again: one star covers one label, so a second level needs its own entry.

🔑 The connection worth making explicit: "wildcard" and "DNS-01" are the same requirement. If someone asks for a wildcard certificate, they are asking for DNS API automation, whether they realise it or not — and that brings the credential-scoping problem with it. The right follow-up question is almost always "do you actually need a wildcard, or would per-host certificates do?"

HTTP-01 — the CA fetches http://<domain>/.well-known/acme-challenge/<token> on port 80 and expects the token plus a thumbprint of your account key. Simple, needs no credentials, and is the right default for any public web server. Cannot issue wildcards, and port 80 is not negotiable.

DNS-01 — you publish a TXT record at _acme-challenge.<domain>. Nothing connects to your server, so it works for internal hosts, and it is the only challenge that can issue wildcards.

TLS-ALPN-01 — validated inside a TLS handshake on port 443 using the acme-tls/1 ALPN protocol. For TLS-terminating proxies that cannot spare port 80. No wildcards.

The decision in one line: need a wildcard, or unreachable on port 80 → DNS-01. Otherwise HTTP-01. TLS-ALPN-01 only for the proxy case.

The security point to raise unprompted: DNS-01 requires credentials that can change your DNS. On a compromised web server that is far worse than losing a certificate — an attacker could repoint your mail and your identity provider. The mitigation is CNAME delegation: point _acme-challenge at a separate throwaway zone and scope the credentials to that zone alone.

Because it only proves control of one host. Serving a file at http://shop.example.com/.well-known/... demonstrates control of that one name and says nothing about api.example.com or any other subdomain.

A wildcard covers an entire namespace, so the CA needs proof of control over that namespace — which means the DNS zone. Only DNS-01 provides that.

The framing I like: proving you can get inside one house does not prove you control the street. Changing the street registry does.

And the follow-up worth volunteering: since a wildcard forces DNS-01, and DNS-01 forces DNS API credentials, asking for a wildcard is really asking for a much broader credential. With ACME automation, per-host certificates are usually the better answer — and with lifetimes heading to 47 days, the operational argument for wildcards is weakening rather than strengthening.

Found the following certs:
  Certificate Name: shop.example.com
    Serial Number: 3f9a2c8e5b1d47f0a6c39e82b74d105f
    Key Type: ECDSA
    Domains: shop.example.com www.shop.example.com
    Expiry Date: 2026-11-18 09:12:44+00:00 (VALID: 62 days)
    Certificate Path: /etc/letsencrypt/live/shop.example.com/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/shop.example.com/privkey.pem

=== how is renewal actually triggered? ===
NEXT                        LEFT      UNIT                 ACTIVATES
Mon 2026-08-24 11:42:19 UTC 5h 3min   certbot.timer        certbot.service

What to read out of this.

• certbot certificates is the inventory command. It reads local state only — no network, no quota — and tells you exactly what this machine believes it manages, with expiry dates. First thing to run on an unfamiliar server.
• The timer runs twice a day, not monthly. That is deliberate: certbot only renews certificates within 30 days of expiry, so most runs do nothing. Frequent checking means a transient failure has dozens of chances to recover before it becomes urgent.
• Key Type: ECDSA — certbot has defaulted to ECDSA for new certificates for a while now, which is the Module 02 (A1) recommendation applied by default.
• The paths are the live/ symlinks from Exercise A2.1, which is what your nginx config should point at.

🔑 "Twice a day, renew at 30 days" is worth being able to justify. With a 90-day certificate you get 60 days and roughly 120 attempts before expiry. A single failed run is a non-event. This is why automated renewal is more reliable than a calendar reminder — not because software is cleverer, but because it retries.

Up to 50 certificates can be issued per registered domain every 7 days.
Up to 5 certificates can be issued per exact same set of identifiers every 7 days.
Up to 5 authorization failures per identifier can be incurred by one account every hour.
Up to 300 new orders can be created by a single account every 3 hours.
Up to 10 accounts can be created from a single IP address every 3 hours.

What to read out of this.

• These change. Let's Encrypt has revised its limits several times, and any blog post quoting them is a snapshot. Read the live page, which is what this command does.
• The two seven-day limits are the dangerous ones, because a week is longer than most certificates have left when you notice a problem.
• "Failed validations: 5 per hour" is the one that stops a broken cron job hammering the API. Note it is per identifier, not per account — so one broken domain does not block your others.
• sed -e 's/<[^>]*>//g' strips HTML tags crudely. Fine for grepping a documentation page; not something to build on.

🔑 The single most valuable habit in this module: --dry-run first, every time. It uses staging, exercises the entire path, and cannot burn production quota. The people who get rate-limited are the people who skipped it.

Almost certainly the duplicate certificate limit: 5 certificates per week for the same exact set of names. The pattern is always the same — renewal fails, someone retries against production while debugging, and after the fifth attempt they are locked out for seven days with the certificate still expiring.

The other one that bites at scale is 50 certificates per registered domain per week, where "registered domain" is the registrable part, so every subdomain of example.com shares one pool. A migration can exhaust that legitimately.

Immediate options: wait for the window to refill; change the set of names slightly, since the duplicate limit is keyed on the exact set, so adding one name creates a different set; or fall back to another CA if you have one configured.

The real answer is prevention: debug in staging. certbot --dry-run and --test-cert exercise the whole flow against an environment with no meaningful limits, and issue untrusted certificates that never touch your quota.

What this signals in an interview: knowing the numbers is fine, but knowing why people hit them — retry loops against production during an incident — is the operationally useful part.

https://acme-v02.api.letsencrypt.org/acme/renewal-info

=== a real ARI response looks like this ===
{
  "suggestedWindow": {
    "start": "2026-02-03T04:00:00Z",
    "end":   "2026-02-04T04:00:00Z"
  }
}

What to read out of this.

• The endpoint is in the directory, so a client that fetches the directory properly discovers ARI automatically — the design from Exercise A1.1 paying off.
• A window, not a deadline. The client picks a random moment inside it, which is what spreads load. If everyone renewed exactly at start, ARI would have recreated the thundering herd it exists to prevent.
• The client queries per certificate, identified by its issuer key hash and serial — the same (issuer, serial) identifier used for revocation in Module 09.
• Support is real but not universal. Certbot supports ARI; adoption across the wider client ecosystem was still growing through 2026.

🔑 The renewal rules that matter regardless of ARI, and these are the exam answer:

1. Renew early — at two thirds of lifetime, or when ARI says. Never at the last minute.
2. Check often — twice a day. Most runs do nothing; the point is that failures get dozens of retries.
3. Use --deploy-hook, not --post-hook — the former runs only when a certificate actually changed, the latter on every check.
4. The hook must reload the service (Module 08, B3), or the renewal achieves nothing.
5. Verify on the wire afterwards, not on disk.

certbot renew --deploy-hook "systemctl reload nginx"

Check frequently, renew early, reload on success, verify on the wire.

• Twice a day, via a systemd timer or cron. Most runs do nothing because certbot only renews within 30 days of expiry — but with a 90-day certificate that gives roughly 120 attempts over 60 days, so a transient failure is a non-event.
• Renew at about two thirds of lifetime, or when ARI tells you. Never at the last moment.
• --deploy-hook, not --post-hook. Deploy hooks fire only when a certificate actually changed; post hooks fire on every check, reloading nginx twice a day for nothing.
• The hook must reload the service. A renewal with no reload is the outage from Module 08 — new file on disk, old certificate still in memory, failure weeks later.
• Monitor the live endpoint, comparing the fingerprint on the wire with the one on disk.

The modern addition worth mentioning: ARI (RFC 9773) lets the CA suggest a renewal window rather than the client guessing. It spreads load, adapts automatically when lifetimes change, and — most importantly — gives the CA a channel to pull renewal forward across its whole population during a mass-revocation event, without anyone changing configuration.

classic      https://letsencrypt.org/docs/profiles#classic
shortlived   https://letsencrypt.org/docs/profiles#shortlived
tlsserver    https://letsencrypt.org/docs/profiles#tlsserver

What to read out of this.

• The CA advertises its profiles in the directory, so a client can discover what is on offer rather than being told out of band. Same discovery principle as every other endpoint.
• Requesting one is a field in the order. In certbot: --preferred-profile tlsserver. Omit it and you get classic.
• classic remains the default, which is the right choice — it is the most compatible, and changing the default under everyone would break things.

🔑 The shortlived profile is Module 09's conclusion made real. At six days a certificate qualifies under the Baseline Requirements as a Short-Lived Subscriber Certificate, which means no revocation mechanism is required at all — no CRL, no OCSP, nothing.

That is the industry's answer to Module 09 in its purest form: not better revocation, but a lifetime short enough that revocation is unnecessary.

⚠️ Only use shortlived if your automation is genuinely trustworthy. At six days, roughly 60 renewals a year per certificate, and any renewal failure becomes an outage within days rather than months. Let's Encrypt's own guidance is that it is for those who fully trust their automation. Run classic until your renewal pipeline has proved itself for months.

Profiles let the CA offer different certificate shapes from the same API. Let's Encrypt advertises three in its directory: classic (90 days, the default, includes Common Name and legacy fields for maximum compatibility), tlsserver (45 days, drops Common Name, keyEncipherment and Subject Key ID, limited to 25 names), and shortlived (about 6 days).

Every field tlsserver removes is one that modern TLS made obsolete: Common Name because RFC 9525 forbids using it for identification, keyEncipherment because TLS 1.3 removed RSA key transport, Subject Key ID because it is only an index and a leaf has nothing below it.

Would I use shortlived? Not immediately. At six days it qualifies as a Short-Lived Subscriber Certificate under the Baseline Requirements, which means no revocation mechanism is required at all — the cleanest possible answer to the fact that revocation does not work. But it means roughly 60 renewals a year per certificate, and any pipeline failure becomes an outage in days rather than months.

The judgement I would show: run classic until the renewal pipeline has proved itself over months — with monitoring on the live endpoint, deploy hooks that reload, and alerting on renewal failure rather than just expiry. Then move to shorter profiles. Adopting six-day certificates before the automation is trustworthy converts a rare risk into a frequent outage.

#!/usr/bin/env bash
# acme-health <certdir> <hostname>
set -uo pipefail
dir="${1:?usage: acme-health <certdir> <hostname>}"; host="${2:?}"
FC="$dir/fullchain.pem"
fail=0
ok()   { printf '  ✅ %-24s %s\n' "$1" "$2"; }
bad()  { printf '  ❌ %-24s %s\n' "$1" "$2"; fail=1; }
warn() { printf '  ⚠️  %-24s %s\n' "$1" "$2"; }

printf '\n  ACME health: %s\n  %s\n\n' "$host" "$(printf '=%.0s' {1..58})"

[ -r "$FC" ] || { bad "certificate" "cannot read $FC"; exit 1; }

# --- 1. lifetime elapsed ---
nb=$(openssl x509 -in "$FC" -noout -startdate | cut -d= -f2)
na=$(openssl x509 -in "$FC" -noout -enddate   | cut -d= -f2)
nbs=$(date -d "$nb" +%s 2>/dev/null) || { warn "dates" "BSD date - use gdate"; nbs=0; }
nas=$(date -d "$na" +%s 2>/dev/null || echo 0); now=$(date +%s)
if [ "$nbs" -gt 0 ] && [ "$nas" -gt "$nbs" ]; then
  total=$(( nas - nbs )); used=$(( now - nbs ))
  pct=$(( used * 100 / total )); left=$(( (nas - now) / 86400 ))
  life=$(( total / 86400 ))
  if   [ "$left" -lt 0 ];  then bad  "lifetime" "EXPIRED ${left#-} days ago"
  elif [ "$pct" -ge 95 ];  then bad  "lifetime" "${pct}% elapsed, ${left}d left of ${life}d - renewal is FAILING"
  elif [ "$pct" -ge 80 ];  then warn "lifetime" "${pct}% elapsed, ${left}d left of ${life}d - should have renewed by now"
  else                          ok   "lifetime" "${pct}% elapsed, ${left}d left of ${life}d"
  fi
fi

# --- 2. disk vs wire ---
disk=$(openssl x509 -in "$FC" -noout -fingerprint -sha256)
wire=$(openssl s_client -connect "$host:443" -servername "$host" </dev/null 2>/dev/null \
       | openssl x509 -noout -fingerprint -sha256 2>/dev/null)
if   [ -z "$wire" ];            then bad "disk vs wire" "could not reach $host:443"
elif [ "$disk" = "$wire" ];     then ok  "disk vs wire" "in sync"
else                                 bad "disk vs wire" "MISMATCH - renewed but NOT RELOADED"
fi

# --- 3. challenge path reachable over plain HTTP, not redirected ---
code=$(curl -sS -o /dev/null -w '%{http_code}' --max-time 10 \
       "http://$host/.well-known/acme-challenge/healthcheck-probe" 2>/dev/null)
case "$code" in
  404|403) ok   "challenge path" "reachable over HTTP (got $code - expected, no such token)" ;;
  30[0-9]) bad  "challenge path" "REDIRECTED ($code) - renewal breaks if HTTPS breaks" ;;
  000)     bad  "challenge path" "port 80 unreachable - HTTP-01 cannot work" ;;
  *)       warn "challenge path" "unexpected status $code" ;;
esac

# --- 4. which profile does this look like? ---
cn=$(openssl x509 -in "$FC" -noout -subject | grep -c 'CN *=' || true)
ku=$(openssl x509 -in "$FC" -noout -ext keyUsage 2>/dev/null | grep -ci 'Key Encipherment' || true)
ski=$(openssl x509 -in "$FC" -noout -ext subjectKeyIdentifier 2>/dev/null | grep -c ':' || true)
if [ "${life:-0}" -le 10 ]; then                       ok "profile" "looks like shortlived (~6d)"
elif [ "$cn" -eq 0 ] && [ "$ski" -eq 0 ]; then         ok "profile" "looks like tlsserver (no CN, no SKI)"
else                                                    ok "profile" "looks like classic (CN present)"
fi

# --- 5. CA reachable, ARI advertised ---
ari=$(curl -sS --max-time 10 https://acme-v02.api.letsencrypt.org/directory 2>/dev/null \
      | python3 -c "import json,sys; print(json.load(sys.stdin).get('renewalInfo','none'))" 2>/dev/null)
[ -n "$ari" ] && [ "$ari" != "none" ] && ok "CA directory" "ARI: $ari" \
                                      || warn "CA directory" "unreachable or no ARI"

printf '\n  %s\n\n' "$([ $fail -eq 0 ] && echo 'HEALTHY' || echo 'PROBLEMS FOUND')"
exit $fail

Try it:

chmod +x acme-health
./acme-health /etc/letsencrypt/live/shop.example.com shop.example.com

The five design decisions worth understanding.

1. It reports lifetime as a percentage, not days remaining. This is the key idea. "30 days left" means something completely different on a 90-day certificate (fine) versus a 6-day one (impossible). Percentage elapsed works across every profile, and 80% is the point at which renewal should already have happened — so it flags a broken renewal rather than an imminent expiry. Those are different alerts, and the first one is the useful one.

2. The disk-versus-wire check is Module 08's lesson, and it is the highest-value line here. Renewal succeeding while the service keeps the old certificate is the commonest ACME-adjacent outage, and nothing else detects it.

3. Getting a 404 on the challenge path is the success case. You are probing a token that does not exist, so 404 means "the path is reachable and served over plain HTTP". A 3xx is a failure, because a redirect means renewal depends on HTTPS working — and if HTTPS is broken, you cannot renew your way out of it.

4. Profile detection reads the certificate rather than trusting configuration. No Common Name plus no Subject Key Identifier means tlsserver; a very short lifetime means shortlived. That is the Module 03 field knowledge doing something useful.

5. It distinguishes ❌ from ⚠️. Expired, mismatched, redirected challenge path and unreachable port 80 are failures. Nearing renewal and an unreachable CA are warnings. A check that fails the build for a warning gets disabled by whoever is trying to ship.

Where this goes next: combine with certinfo (Module 03), tlsinfo (Module 06), tlsdiag (Module 07) and tlsdeploy-check (Module 08). Module 13 assembles them into one auditing tool.

--pre-hook PRE_HOOK   Command to be run in a shell before obtaining any
                      certificates. Intended primarily for renewal, where it
                      can be used to temporarily shut down a webserver...
--post-hook POST_HOOK Command to be run in a shell after attempting to
                      obtain/renew certificates. Can be used to deploy
                      renewed certificates, or to restart any servers that
                      were stopped by --pre-hook...
--deploy-hook DEPLOY_HOOK
                      Command to be run in a shell once for each
                      successfully issued certificate...

What to read out of this — the difference is in the last four words.

• --post-hook: "after attempting". It runs whether or not anything was renewed. With a twice-daily timer that is 730 nginx reloads a year, 728 of them pointless.
• --deploy-hook: "once for each successfully issued certificate". Fires only when a certificate actually changed. This is the one you want, and the wording is the only place the distinction is made clear.
• --pre-hook is for stopping a service so --standalone can bind port 80. If you use --webroot you do not need it, which is one more reason --webroot is the better default.

💡 --deploy-hook also runs once *per certificate*, so on a host with several certificates it fires several times. If your hook is expensive, make it idempotent — or use --post-hook guarded by a check that something actually changed.

A protocol (RFC 8555) for obtaining certificates with no human involved: the client proves domain control via an automated challenge and the CA issues in seconds.

It matters more each year because maximum lifetimes are falling — 200 days in March 2026, 100 in 2027, 47 in 2029. At 47 days manual renewal is eight times a year per certificate. Automation is no longer a convenience.

It is one JSON document listing every endpoint URL, so clients discover them rather than hard-coding them. Let's Encrypt inserts a random key deliberately, to break clients that hard-code URLs or choke on unexpected fields — a client that fails on it would fail on the next real addition.

Identity, not authority. It identifies you to the CA and carries your rate limits, but grants no right to any domain — every order still needs a fresh challenge.

A stolen account key cannot get certificates for your domains, but can revoke existing ones and burn your quota. The domain-control proof is the real security boundary.

HTTP-01 by default — no credentials, simplest failure modes. DNS-01 if you need a wildcard (the only option) or the host is unreachable on port 80. TLS-ALPN-01 only for a TLS-terminating proxy that cannot spare port 80.

DNS-01's cost is DNS API credentials; mitigate with CNAME delegation to a throwaway zone.

Because a wildcard covers a whole namespace, and only control of the DNS zone proves control of a namespace. Serving a file on one host proves control of that host and nothing else.

Practical consequence: asking for a wildcard is really asking for DNS API automation, with the broader credential exposure that brings.

The CA fetches it over plain HTTP on port 80. If it is redirected and your HTTPS is broken or expired, renewal depends on the very thing that is broken — and you cannot renew your way out of it.

Serve that one path directly over HTTP; redirect everything else.

Duplicate certificates: 5 per week for the same exact set of names. Renewal fails, someone retries against production while debugging, and the sixth attempt locks them out for seven days with the certificate still expiring.

Avoid it by debugging in staging — --dry-run / --test-cert. Also relevant at scale: 50 certificates per registered domain per week, shared across all subdomains.

--deploy-hook runs only when a certificate was actually issued. --post-hook runs after every attempt, so a twice-daily timer reloads nginx 730 times a year for nothing.

Use --deploy-hook, and make sure it reloads — a renewal without a reload is the Module 08 outage.

Because certbot only renews within 30 days of expiry, so most runs do nothing — the point is retries. Twice daily over 60 days gives roughly 120 chances, so a transient DNS or network failure is a non-event.

Automation beats a calendar reminder not because it is cleverer but because it retries.

ACME Renewal Information, RFC 9773 (September 2025). The CA returns a suggestedWindow telling the client when to renew, instead of the client guessing.

It spreads renewal load, adapts automatically when lifetimes change, and — most importantly — gives the CA a channel to pull renewal forward across its entire population during a mass-revocation event, with no configuration change anywhere.

classic (90 days, default, includes Common Name and legacy fields, up to 100 names), tlsserver (45 days, no Common Name, no keyEncipherment, no Subject Key ID, 25 names), and shortlived (~6 days).

Every field tlsserver drops is one modern TLS made obsolete. shortlived qualifies as a Short-Lived Subscriber Certificate, requiring no revocation mechanism at all.

Not until the pipeline has proved itself over months. It means roughly 60 renewals a year per certificate, and any failure becomes an outage in days rather than months.

Prerequisites first: monitoring on the live endpoint, deploy hooks that reload, and alerting on renewal failure rather than expiry. Then shorten. Adopting it early converts a rare risk into a frequent outage.

Question selection was cross-referenced against publicly published 2026 SSL/TLS and DevOps interview question sets, then rewritten and deepened:

• InterviewPrep — Top 25 SSL Certificate Interview Questions and Answers
• ClimbTheLadder — 15 PKI Interview Questions and Answers
• ClimbTheLadder — 10 SSL Certificate Interview Questions and Answers
• Devinterview.io — Web Security interview questions for 2026

The ACME directory output in Exercise A1.1 is the live production directory, fetched from acme-v02.api.letsencrypt.org while writing this module — including the deliberate random entry (PeiDSJ6MPvc), the renewalInfo ARI endpoint, and the three advertised profiles. The rate limits in Part C2 were read from Let's Encrypt's live rate-limits page rather than recalled, and the profile lifetimes and field differences from the profiles documentation.

Standards and current status were verified against primary sources: RFC 8555 for the protocol, Let's Encrypt's challenge-types documentation for the port and wildcard constraints of each challenge, RFC 9773 and Let's Encrypt's ARI announcement for renewal information, and the certbot documentation for hook semantics.

certbot itself was not run for this module — the sandbox has no public DNS name and could not complete a challenge — so the certbot outputs are documentation-verified rather than execution-verified. The curl-based directory and rate-limit exercises are live and reproducible.

Answers were rewritten and deepened rather than reproduced — published versions are usually correct but shallow, and the added operational detail is what actually differentiates a candidate in the room.