Certificate lifecycle

Doctrine

• All certificate issuance is tied to owner, environment, and validity constraints.
• Renewal and rotation are tested in pre-production before production cutover.
• Revocation decisions include blast radius and customer impact estimation.
• Retirement requires cleanup of trust stores and ingress references.

Decision tree

1. Is the certificate near expiry threshold?
   • Yes → perform staged renewal and readiness checks.
   • No → keep it in monitored steady-state.
2. Did renewal complete without chain drift?
   • Yes → validate handshakes across all ingress routes.
   • No → pause rollout and inspect SAN/issuer and intermediates.
3. Is revocation required?
   • Yes → revoke immediately and publish trust updates.
   • No → archive evidence and plan expiry-based retirement.

Diagnostics pathway

1. Inspect validity windows and subject names:

   openssl x509 -in /etc/ssl/certs/site.pem -noout -dates -text | rg -i "not before|not after|dns:"

2. Validate chain behavior:

   openssl verify -CAfile /etc/ssl/certs/ca-chain.pem /etc/ssl/certs/site.pem

3. Test live handshake and protocol negotiation:

   echo | openssl s_client -connect app.example.com:443 -servername app.example.com

4. Dry-run renewal:

   certbot renew --dry-run

Operational checks

• Collect inventory and ownership weekly with expiry risk classification.
• Block promotion if renewal cannot be validated in staging.
• Keep post-rotation proof artifacts: cert hashes, handshake logs, and service health snapshot.

Related routes