Skip to content

Best Practices for Certificate Renewal

Set Renewal Thresholds That Match Your Risk Tolerance

A renewal threshold of 30 days gives reasonable lead time for most environments, but the right value depends on:

  • Certificate lifetime — for 90-day certificates, a 30-day threshold means you renew at two-thirds of the lifetime. For 1-year certificates, 30 days is a smaller fraction.
  • Deployment complexity — if renewal requires co-ordinating multiple teams or manual steps, a longer threshold (45–60 days) gives more runway.
  • ACME certificates — certificates issued via ACME protocols typically use shorter lifetimes (60–90 days) and rely on automated renewal. Ensure your ACME renewal threshold allows multiple retry attempts before expiry.

Avoid thresholds that are too short (for example, 7 days) — this leaves no recovery window if automated renewal fails on the first attempt.

Automate Renewal for All Managed Certificates

Manual renewal does not scale and introduces operational risk. Configure automated renewal for every certificate managed through the platform. The combination of automated renewal and automated deployment via a Bridge means certificates are replaced without operator involvement.

Reserve manual renewal for exceptional cases — for example, certificates that require a new key algorithm or updated Subject Alternative Names.

Rotate Keys at Every Renewal

Each renewal should generate a new key pair. Do not reuse the private key from the previous certificate. Key rotation at renewal limits the exposure window of any given key to at most one certificate lifetime.

The platform generates a new key pair by default for each certificate issuance. Do not override this behaviour unless you have a verified operational requirement.

Monitor Renewal Failures Promptly

Automated renewal can fail for various reasons — the Back Control Plane may be unavailable, the CA may reject the CSR, or the Bridge may fail to deploy the renewed certificate. A failed renewal that is not caught promptly will result in an expiring certificate.

Configure alerting for renewal failures. Use the platform's audit log and the reporting system to monitor renewal success rates. Investigate any failed renewal immediately rather than waiting for the next automated retry.

Test the Full Renewal Cycle Before Production

Before relying on automated renewal in a production environment, test the complete cycle:

  1. Issue a certificate with a short validity period in a staging environment.
  2. Wait for the automated renewal threshold to be reached.
  3. Confirm that the renewal completes and the new certificate is deployed to the target system.
  4. Verify the deployed certificate using openssl s_client.

This confirms that the full path — from renewal trigger through to deployment — works correctly before it is needed in production.

Revoke the Old Certificate When Replacing Due to Compromise

Renewal in response to a suspected key compromise requires an extra step: revoke the original certificate immediately, even before the renewal is complete. Do not wait for the renewed certificate to be deployed before revoking the old one.

For certificates not related to a compromise, revocation of the old certificate is optional. Expired certificates are already untrusted by relying parties, but explicitly revoking superseded certificates reduces the number of active certificates in the inventory and simplifies auditing.

Keep Issuance Infrastructure Available

Automated renewal requires the Back Control Plane and the issuing CA to be available at the time of renewal. For Local PKI, this means the intermediate CA must be active. For external CAs, the CA's API must be reachable from the Back Control Plane.

Treat intermediate CA availability as a critical dependency of your certificate lifecycle automation. Monitor CA status and respond to any issues promptly.