ACME automation is not certificate monitoring
ACME is the right foundation for short-lived public TLS certificates. It automates issuance and renewal. It does not, by itself, inventory every public and internal certificate, identify the right owner, or ensure that each asset is covered by an alert route that can act.
What ACME actually solves
RFC 8555 defines ACME as a protocol that a certificate authority and an applicant can use to automate identifier validation and certificate issuance. That matters: without automation, shorter certificate lifetimes become operationally unrealistic.
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.
- Who owns the endpoint and which alert route can fix it before the renewal window closes.
- Which internal certificates, private PKI endpoints, and manually installed certificates are outside the ACME path.
The monitoring boundary extends beyond issuance
The important boundary is simple: ACME can tell you that a certificate was issued or renewed. It cannot inventory every endpoint users and internal systems reach, or every certificate stored in a private host or cluster outside that ACME workflow.
This becomes more important as certificate lifetimes shrink. Renewal stops being a quarterly calendar task and becomes a normal infrastructure loop. A working loop needs issuance automation, deployment automation, and independent observation.
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.
Automated in one place only
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 does not replace ACME clients, certificate authorities, or deployment automation. It monitors certificates presented by reachable public and internal TLS endpoints and adds filesystem and Kubernetes discoveries to the same inventory. Teams can then track expiration across both ACME-managed and non-ACME assets. Business and Custom workspaces also add Compliance policy posture.
That makes it useful beside ACME, not instead of ACME. The clean model is to let ACME handle issuance and renewal, then use independent monitoring to confirm the result on the endpoints that matter.
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.