ACME automation is not certificate monitoring
ACME automates the issuance and renewal of public TLS certificates. Teams still need to inventory certificates outside that process, assign responsibility for them, and configure expiration alerts.
acme.sh renewed the certificate, but Nginx still serves the old one
cert-manager: Certificate is Ready, but the Ingress serves the wrong certificate
Traefik serves the wrong certificate: check SNI, routers and ACME
Certbot renewed the certificate, but Nginx still serves the old one
What ACME automates
RFC 8555 defines ACME as a protocol for automating identifier validation and certificate issuance between a certificate authority and an applicant. Shorter certificate lifetimes leave less time to carry out those steps manually.
ACME Renewal Information, standardized in RFC 9773, improves the renewal side. An ACME server can provide suggested renewal windows, and a client can report that it has successfully renewed and replaced a certificate. Let’s Encrypt recommends checking ARI frequently and using it instead of hardcoded renewal timing when possible.
ACME covers
- Requesting a certificate from an ACME server.
- Proving control of identifiers through supported challenges.
- Receiving the issued certificate and, depending on the client, renewing it automatically.
- Revocation and account-level certificate management functions.
Monitoring still checks
- Which certificate is actually served on each host, port, and SNI name.
- Which public and internal endpoints, files, and Kubernetes TLS material are inside the inventory boundary.
- Whether the chain, issuer, SAN set, key type, or TLS policy changed unexpectedly.
- Which team owns the endpoint and receives alerts in time to renew its certificate.
- Which internal certificates, private PKI endpoints, and manually installed certificates are outside the ACME path.
Check certificates after issuance
ACME can confirm that a certificate was issued or renewed. It does not inventory endpoints, private hosts, or clusters outside that ACME workflow. Those locations need their own checks.
api-01.example.com- New certificate68 days left
api-02.example.com- Previous certificate still served7 days left
Issuance succeeded. Deployment still needs checking on each endpoint.
Failure modes automation does not remove
Assets outside the ACME path
VPNs, appliances, private APIs, manually installed certificates, and internal PKI can remain outside both the automated inventory and its alert route.
Only some services are automated
The public web server is automated, but the VPN, appliance, admin panel, internal API, or customer tenant endpoint is still manual.
No owner when it breaks
The renewal job belongs to one team, the endpoint belongs to another, and the alert goes to a shared mailbox nobody treats as operational.
Wrong renewal assumptions
A hardcoded schedule or old client behavior works for 90-day certificates, then becomes fragile as lifetimes shrink and renewal windows change.
A practical operating model
- Use ACME for issuance and renewal wherever the endpoint and CA support it.
- Use ARI-aware clients when available so the CA can signal suggested renewal windows and early replacement needs.
- Monitor the live endpoint independently of the ACME client.
- Track owners, alert destinations, observed sources, and renewal methods for every certificate.
- Bring internal certificates and endpoints that do not use public ACME into the same operational inventory.
- Alert on what users and systems actually see, not only on whether the issuance job succeeded.
Where Nocert fits
Nocert monitors certificates presented by reachable public and internal TLS endpoints, as well as certificates found in files and Kubernetes. You can track expiration dates for certificates managed by ACME and by other tools. Business and Custom also show the results of Compliance policy checks. Nocert does not replace your ACME client, certificate authority, or deployment tools.
After an ACME renewal, check that the expected certificate is served by the endpoints you monitor.
Primary sources
This note is based on the ACME standard, the ACME Renewal Information extension, Let’s Encrypt integration guidance, and Let’s Encrypt rate-limit documentation.