A certificate authority can issue a replacement successfully while a load balancer continues serving the old certificate. Certificate lifecycle management has to cover discovery, issuance, deployment, renewal, and verification. The handoff between those steps is where many operational surprises occur.
Start with the systems that serve certificates
Inventory public endpoints, internal service endpoints, and the stores or appliances that hold their certificates. For each one, record the issuer, owner, renewal method, and deployment target. If the inventory comes exclusively from a certificate authority, add discovery from the network or relevant infrastructure. A certificate can still be in use even if it was issued outside your usual process.
Match the controller to the estate
| Tool | Typical fit | What to verify |
|---|---|---|
| cert-manager | Kubernetes workloads that declare certificate requirements | The issuer can complete validation and the application picks up the updated Secret |
| AWS Certificate Manager | TLS certificates used with supported AWS services | Renewal eligibility and the deployment path for each certificate type |
| Keyfactor Command | Centralized discovery and lifecycle management across mixed environments | Connector coverage for your authorities, key stores, and deployment targets |
Imported certificates in AWS Certificate Manager require a separate renewal process. Document who obtains the replacement and who reimports it, then confirm the endpoint actually presents the new certificate chain. Treat private-key access and backup separately from the inventory of public certificates.
Rehearse a failed renewal
Force a renewal on a test endpoint and watch it from a client. Confirm the replacement serial number, hostname, trust chain, and time remaining. Then deliberately break an issuer or deployment permission and check that the right owner receives an actionable alert. The pilot is complete when the team can detect the failure and recover before users encounter it.