ACME automates certificate requests and domain validation. Successful renewal still depends on the client, validation route and server deployment. This is a protocol explanation and operator checklist, not a DechoNet incident account.
What issuance proves
A domain-validated certificate binds a public key to validated names; it does not establish a website’s honesty. RFC 8555 defines orders, authorizations, challenges, CSR submission and certificate download. The account key authenticates signed ACME requests; the certificate key in the CSR has a separate role. JWS requests carry replay-protection nonces. Directory discovery and nonce retrieval are exceptions to signed POST requests.
An authorization may already be valid and reusable within CA policy, so issuance need not run a new challenge every time. Downloading the certificate and configuring the TLS server to serve it are separate steps.
Choose a validation route you can maintain
These choices follow Let’s Encrypt’s challenge documentation. Support varies by CA and client.
| Challenge | Validation route | Constraint |
|---|---|---|
| http-01 | Challenge resource on port 80 | Public reachability; no wildcard validation |
| dns-01 | TXT under _acme-challenge | Wildcards supported; DNS credentials and propagation matter |
| tls-alpn-01 | Special TLS response on port 443 | Explicit support at the TLS termination point |
For dns-01, prefer narrowly scoped credentials or a delegated validation zone over a full-zone token on the web server. Check TXT visibility before validation; a successful DNS API write does not prove every authoritative server serves the update.
RFC 8737 defines tls-alpn-01’s acme-tls/1 negotiation and special certificate extension. Ordinary HTTPS on port 443 is insufficient: the terminating proxy or server must handle this challenge. It cannot validate wildcards.
Shorter certificates still need monitoring
CA/Browser Forum requirements §6.3.2 cap newly issued public TLS certificates at 200 days from March 15, 2026, 100 days from March 15, 2027 and 47 days from March 15, 2029. Existing certificates are not shortened retroactively. Let’s Encrypt’s separate schedule puts its classic profile at 64 days on February 10, 2027 and 45 days on February 16, 2028; its opt-in tlsserver profile has an earlier schedule.
Follow the CA/client’s renewal guidance instead of a universal sixty-day rule. Monitor failed renewals and the served certificate, not just the file the client produced. Short lifetimes limit remaining certificate validity after key compromise; they do not replace revocation or key replacement.
Domain validation is a security boundary
Protect the account key, certificate key, challenge path and DNS credentials. Domain validation risks existed before ACME. Forum §3.2.2.9 requires multi-perspective checks using a quorum, rather than every vantage point agreeing. They reduce some localized validation attacks; they do not make abusive issuance impossible.
When issuance succeeds but HTTPS fails
- Compare the requested names with the SANs in the certificate obtained from a TLS connection to the intended endpoint using the requested hostname (SNI). The SSL tool is a supporting check: if direct certificate inspection is unavailable, it may display CT issuance records. CT records alone do not confirm which certificate the server currently serves. A proxy, CDN or another instance may still serve an older certificate.
- Check expiry, chain trust and TLS separately. Hostname mismatch and issuer or chain errors require different fixes.
- Use DNS lookup to confirm the intended endpoint, then inspect challenge routes and client logs. DechoNet’s public checks do not run ACME validation or inspect your renewal job.
- Verify reload/deployment after renewal and alert on failures. Keep DNS permissions narrow and clean up obsolete challenge records according to the client workflow.
ACME reduces repetitive issuance work. Reliable operation still requires a maintained validation route and evidence that the renewed certificate reached the endpoint users visit.