Certificate Renewal Best Practices

A certificate that expires is doing its job.

This sounds backward. Expiration feels like a problem—something to manage, automate away, prevent from causing outages. But expiration exists because a certificate is a proof of domain control, and proofs go stale. A certificate that lives forever only proves you controlled your domain once. One that expires forces you to prove it again.

Modern best practices embrace short certificate lifetimes. The goal isn't to minimize renewal work—it's to maximize how often you prove you're still you. Automation is what makes this sustainable.

Automation Is the Foundation

With certificate lifetimes capped at 13 months and trending toward 90 days (or shorter), manual renewal is already impossible at scale. But automation isn't just about keeping up—it's about making short lifetimes practical so you can choose them.

The ACME protocol (Automatic Certificate Management Environment) handles the entire certificate lifecycle without human intervention. Clients like Certbot and acme.sh can:

• Detect when renewal is needed
• Prove domain control automatically via HTTP, DNS, or TLS challenges
• Obtain new certificates
• Deploy them to web servers, load balancers, and CDNs
• Reload services to pick up the new certificates

Once this pipeline works, certificate lifetime becomes a choice rather than a constraint. Some organizations renew weekly. Some renew daily. The automation doesn't care.

Renew Early, Not Just On Time

Automation can fail. DNS APIs change. Firewall rules get modified. Services restart at the wrong moment. If renewal fails the day before expiration, you have a crisis. If it fails 30 days before expiration, you have time.

For 90-day certificates, renew when 30 days remain. For 13-month certificates, start at 60-90 days out. This buffer isn't about convenience—it's about converting renewal failures from emergencies into tickets.

Early renewal also creates overlap: both old and new certificates are valid simultaneously. If the new certificate causes problems (wrong SANs, deployment glitch), you can roll back to the old one while you debug.

New Keys Every Time

When you renew, generate a fresh private key. Don't reuse the old one.

Reusing keys is technically valid, but it defeats part of the purpose of renewal. If your old key was compromised without your knowledge, a new certificate with the same key is still compromised. A new key starts clean.

Most ACME clients generate new keys by default. If you're managing certificates manually, make key generation an explicit step in your renewal process.

Monitor What You Automated

Automation fails silently. The renewal script ran, but the DNS challenge failed because someone rotated the API token. The certificate was issued, but the deployment hook couldn't reach the load balancer. The new certificate was installed, but the service wasn't reloaded.

You need monitoring that checks the actual deployed certificate from outside your infrastructure:

• External probes that connect to your services and verify certificate validity
• Alerts at multiple thresholds: 60 days, 30 days, 14 days, 7 days
• Escalation that ensures alerts reach someone who can act

Internal monitoring (checking certificate files on disk) catches different failures—like a renewal that succeeded but wasn't deployed. Both matter.

Test Before You Need It

Don't discover your renewal process is broken when your production certificate has 3 days left. Test it when you have months of buffer.

• Use Let's Encrypt's staging environment to verify your automation without burning through rate limits
• Run dry-run renewals that simulate the process without actually obtaining certificates
• Trigger actual renewals in production early, while you still have time to debug failures

The best time to find a bug in your renewal pipeline is when it doesn't matter yet.

Know What You Have

Certificates accumulate. A load balancer here, an internal service there, a legacy system someone forgot about. Certificate sprawl means surprise outages when something expires that wasn't in your automation.

Maintain an inventory:

• Every certificate's domain names, issuer, and expiration date
• Where each certificate is deployed
• What automation manages it (or if it's manual)

Periodically scan your infrastructure to discover certificates your inventory missed. When you decommission a service, revoke its certificate and remove it from tracking.

Complete the Chain

A certificate alone isn't enough. You need the complete chain: your certificate plus all intermediate certificates up to (but not including) the root.

An incomplete chain works for some clients (those that have the intermediates cached) and fails mysteriously for others. This is one of the most common deployment mistakes.

• Include all intermediates in your deployment
• Send them in order: end-entity certificate first, then intermediates
• Verify with SSL Labs or similar tools after every deployment

Coordinate Dependencies

Renewal doesn't happen in isolation. It touches:

• DNS providers: For DNS validation, you need working API credentials
• Firewalls: For HTTP validation, port 80 must be accessible to the CA
• Load balancers and CDNs: Deployment automation needs access to push new certificates
• On-call rotation: Someone needs to be available when alerts fire

Each dependency is a potential failure point. When renewal breaks, check these first.

Prepare for When It Breaks

It will break eventually. Have a plan:

• A documented manual renewal process for when automation fails
• CA support contact information for urgent issues
• A rollback procedure to restore the previous certificate
• Clear ownership of who responds to certificate alerts

The goal isn't to prevent all failures—it's to ensure failures don't become outages.

Shorter Is Better

Don't request maximum validity just because you can. A 398-day certificate from a commercial CA isn't a feature—it's 398 days during which a compromised key remains trusted, a revoked certificate might not be checked, and your domain control proof grows stale.

Let's Encrypt's 90-day lifetime is the current best practice. Some organizations go further: 30-day certificates, weekly renewals, treating certificates almost like session tokens. If your automation is solid, shorter lifetimes are pure upside.

The industry is moving toward even shorter maximums. Building automation now means you're ready.