ACME renewal in CertLocker: what happens after the cert is issued?
Part one showed the ACME order flow. Part two is about the bit that matters in production: renewal, scoped delivery, and proving that the right certificate reached the right service.
Video walkthrough
Watch the renewal flow
The new video walks through ACME renewal in CertLocker using the same model as the first ACME article: certificates live in inventory, edge systems authenticate with scoped certificate tokens, and the ACME gateway handles delivery without giving every server broad API access.
The first ACME walkthrough covered order creation: pick an issuer, complete DNS-01 or HTTP-01, watch the workflow state change, and land the issued certificate in CertLocker inventory. That is important, but it is still only the first half of certificate automation.
The operational question is what happens next. A certificate that issues once but cannot renew safely is still a future incident. Renewal needs to be repeatable, visible, and constrained to the service that actually needs the certificate.
Renewal is a delivery problem, not just an issuance problem
Most certificate incidents do not happen because ACME as a protocol cannot issue a certificate. They happen because the renewed certificate does not reach the right target, the service does not reload, the wrong chain is served, or nobody notices until the old certificate expires.
CertLocker separates those concerns. Issuance and inventory live in the platform. Delivery happens through an ACME endpoint that infrastructure already understands. HAProxy, win-acme on IIS, and other RFC 8555 clients can request the certificate they are allowed to fetch, using a token scoped to that certificate.
What the part two video covers
The video focuses on the renewal side of the workflow. The useful thing to watch is not just that an ACME client can request a certificate. It is how the request maps back to inventory, tokens, audit, and service delivery.
- Certificate inventory: the certificate has a known owner, hostname set, issuer, expiry date, and metadata.
- Scoped ACME token: the client presents a token that is tied to the certificate it is allowed to retrieve.
- ACME gateway: CertLocker speaks the protocol the client expects, while enforcing the platform-side access rules.
- Renewal handoff: the edge system receives the certificate and can install or reload using its normal ACME behaviour.
- Audit evidence: registration, order, finalize, download, and token activity are visible instead of buried in a local cron log.
Why scoped renewal matters
A broad platform API key on a load balancer is convenient until that host is compromised. At that point, the problem is no longer one certificate. It is every certificate and secret the credential can reach.
CertLocker is deliberately narrower. The renewal client should have access to the certificate it serves and no more. If the token needs to be revoked, you revoke that delivery path without rotating unrelated infrastructure credentials.
That model also makes ownership clearer. When a certificate renews, you can trace which token was used, which service requested it, and which inventory item was delivered.
What to verify before trusting renewal
A green ACME run is not enough. Before you depend on renewal in production, verify the whole chain:
- The client points at the right directory: hosted CertLocker uses
https://trust.certlocker.io/rest/acme/directory. - The token is certificate-scoped: avoid general-purpose credentials on edge hosts.
- The key material matches the client behaviour: HAProxy-style flows may need key reuse depending on how the certificate is delivered.
- The service reload is real: confirm the new certificate is actually being served, not just downloaded.
- The chain is complete: HAProxy and IIS both need the right certificate chain, not only the leaf certificate.
- The audit trail is readable: if a renewal fails at 02:00, an operator should know which step failed.
How this fits with shorter certificate lifetimes
As certificate lifetimes keep shrinking, manual renewal becomes less defensible. The work does not disappear; it moves into automation. That automation has to be observable and revocable.
If a team already uses ACME clients but still copies certificates around by hand, renewal is only half automated. The better pattern is to let the systems that terminate TLS pull the certificate through a constrained delivery channel, then verify the endpoint after the reload.
The takeaway
ACME is not just a way to get a certificate from a CA. In CertLocker, it is also a delivery protocol: a standard way for infrastructure to request the exact certificate it is allowed to serve.
That is the point of the part two video. Issuance gets the certificate into the platform. Renewal and delivery keep the service trusted after the first successful run.
Automate ACME renewal with scoped delivery
CertLocker gives infrastructure teams certificate inventory, ACME delivery, scoped tokens, probes, and audit history in one platform.