A certificate can renew on schedule while an application keeps serving the old one. A standby appliance may miss the update. A restarted service may load the certificate but omit an intermediate that its clients need.
Design certificate automation around the service the organisation relies on. At Quokka, we want the operating team to be able to trace the change from request through deployment, verify it from a client and recover when part of that process fails.
Shorter lifetimes change the workload
The CA/Browser Forum’s maximum validity for publicly trusted TLS server certificates is now 200 days. It falls to 100 days for certificates issued from 15 March 2027 and 47 days from 15 March 2029. These limits apply to the public TLS ecosystem; they do not set the lifetime of every private PKI or industrial device certificate. See the validity schedule.
Shorter cycles increase the cost of a process that depends on an engineer remembering an expiry, finding the right appliance and working through a manual change. Automate the normal path and make the failure path clear enough for the on-call team to use.
Start with the service and its owner
Record the certificate’s issuer, names, expiry and key location alongside the service owner. Include where it terminates, which nodes serve it, which clients trust it and how the service picks up a replacement.
Trace shared dependencies. One wildcard certificate may cover several applications. A private issuing CA may support staff authentication, equipment access and application connections. Replacing a leaf certificate and changing a trust anchor require different rollout plans.
Include standby nodes, management interfaces and devices that discovery tools cannot query. Give those exceptions a named owner, a renewal procedure and enough lead time to use an approved maintenance window.
Build the renewal path with limited authority
ACME, specified in RFC 8555, provides a protocol for automating certificate management. Where the CA and client support it, the ACME Renewal Information extension, RFC 9773, lets the CA communicate a suggested renewal window.
Choose a supported enrolment method for each environment. Scope the automation account to the certificates and validation records it needs. Keep private keys and validation credentials in protected storage, with access and rotation procedures the team can explain.
Plan retries, issuer outages and failed validation before expiry approaches. Agree how much recovery time the service needs, then alert on remaining headroom and repeated failures. A successful scheduled job should mean the required action completed, with evidence of the result.
Prove deployment across the service
Use a supported reload or replacement method. For a service with several nodes, update a small part of the deployment first and check it before continuing. Confirm the standby path as well as the node carrying traffic.
Connect from the client’s side of the boundary. Check the certificate identity, chain, expiry and hostname, then perform a representative service transaction. For mutual TLS, test both directions of authentication and the permissions that follow.
Retain the certificate identifier, deployment targets and verification result. The support team should be able to tell which version each node serves without exposing private keys or credentials in logs.
Make failure and recovery part of acceptance
Exercise a rejected renewal, an unreachable node, a failed reload and a client with an incomplete trust chain in a representative environment. Show that the rollout stops where it should and that the right person receives a useful alert.
A recovery procedure might restore a previously working deployment only while its certificate and key remain valid and trusted. After key compromise or revocation, issue and deploy a replacement under the incident procedure. Restoring compromised material would restore the exposure.
For disconnected and operational environments, document how the team transfers approved material, checks its integrity and renews within the available change window. Test the impact with operations before introducing automatic restarts or changes to a live process.
A useful first acceptance test
Renew one representative service end to end.
Have its owner witness renewal, deployment to active and standby paths, a client connection and a controlled failure. Record who recovers the service and how long they have before expiry. Expand the approach after that test passes.
This operating discipline also helps with future cryptographic changes. Read the companion note on preparing for post-quantum cryptography, where algorithms, protocols and device support need their own assessment.