Managing the TLS certificate lifecycle

A certificate is not finished when it is issued. A dependable HTTPS service needs an owner, an inventory record, a deployment check, renewal monitoring, and a retirement or revocation process. This guide connects those stages so teams can turn an isolated scan finding into an operational fix.

1. Discover and assign ownership

Start with every public hostname, load balancer, CDN, API endpoint, and certificate authority account. Record the service owner, environment, certificate authority, names covered, key type, renewal method, and next action. Ownership matters because an expiration warning without an accountable team is not a remediation plan.

2. Issue with the intended names and policy

Before requesting a certificate, confirm the exact DNS names, wildcard boundaries, validation method, key algorithm, validity policy, and deployment destinations. Separate public certificates from internal or private PKI records. A certificate issued for the wrong hostname can be perfectly valid and still fail every real client connection.

3. Deploy and verify the serving path

Installing a certificate on an origin is not enough when a CDN, reverse proxy, ingress controller, or load balancer serves the public connection. After deployment, test each important hostname with SNI, check the complete chain, compare all nodes, and confirm the endpoint presents the intended certificate rather than a stale or default one.

4. Monitor before the deadline

Monitor expiration, hostname coverage, chain behavior, trust results, and changes to the served certificate. Alert at intervals that match the organization’s renewal process rather than waiting for the final days. A monitor should identify the endpoint, owner, current certificate fingerprint, expiration date, and last successful check.

5. Respond to a finding

Classify the finding before changing production. An expired certificate needs urgent replacement; a hostname mismatch points to names, routing, or SNI; an incomplete chain often requires the correct intermediate bundle; and a legacy protocol or algorithm requires compatibility analysis before removal. Capture the evidence, change the serving configuration, retest, and record the result.

6. Retire and revoke deliberately

When a certificate is replaced, remove obsolete copies from active services and secrets stores according to your organization’s retention policy. If a private key was exposed or a certificate was issued incorrectly, follow the certificate authority’s revocation process and investigate every place the key or certificate was deployed. Expiration alone is not a substitute for revocation after compromise.

Use the inspector as one lifecycle checkpoint

Use the inspector after issuance, deployment, proxy changes, DNS changes, and TLS-policy changes. Pair the result with the expiration guide, chain guide, and hostname guide. For algorithm migration, see the post-quantum readiness guide.

Last reviewed: October 2026. Certificate-authority, browser, and platform requirements change; verify consequential changes against current provider documentation.