SSL Certificate Renewal: Complete Process Guide

When to Start the Renewal Process

SSL certificates have fixed expiration dates. When that date passes, browsers display security warnings and users cannot reach your site without clicking through scary error messages. Most will leave instead. The renewal process should start well before expiration, not the day before.

Let's Encrypt certificates expire every 90 days. Certbot and other ACME clients attempt renewal when a certificate has 30 days remaining. This gives you a 30-day window to catch and fix any renewal failures before the certificate actually expires.

Commercial certificates (from DigiCert, Sectigo, GlobalSign, etc.) typically last 1 year, though the CA/Browser Forum has been progressively shortening maximum validity periods. Start the renewal process 30 to 90 days before expiration, depending on your organization's procurement and approval processes.

Why start early: Renewal can fail. DNS changes, server migrations, expired API tokens, and procurement delays all take time to resolve. Starting early means a failed renewal attempt is an inconvenience, not an emergency. For a complete checklist, see our SSL renewal checklist.

Our SSL/TLS guide covers the foundational concepts behind certificates and encryption if you need background.

Auto-Renewal with Let's Encrypt

Let's Encrypt changed SSL certificate management by making certificates free and automating the renewal process. If you use Let's Encrypt, auto-renewal should be your primary strategy.

How Certbot Auto-Renewal Works

Certbot installs a systemd timer (or cron job) that runs twice daily. Each run checks whether any managed certificates are within 30 days of expiration. If they are, Certbot attempts to renew them.

The renewal process:

1. Certbot checks the certificate's expiration date
2. If within 30 days, it requests a new certificate from Let's Encrypt
3. Let's Encrypt validates domain ownership (HTTP-01 or DNS-01 challenge)
4. A new certificate is issued and saved to disk
5. Certbot runs any configured deploy hooks (e.g., reloading Nginx or Apache)

# Verify the systemd timer is active
systemctl list-timers | grep certbot

# Or check the cron job
crontab -l | grep certbot

# Test that renewal would work without actually renewing
sudo certbot renew --dry-run

The --dry-run flag is essential. It simulates the entire process without issuing a certificate, catching configuration problems before they become real failures.

Setting Up Certbot Auto-Renewal

If you installed Certbot through your distribution's package manager, the timer or cron job is usually set up automatically. If you installed it manually, you need to create it yourself.

Systemd timer approach:

# Check if the timer exists
systemctl status certbot.timer

Cron job approach:

# Run twice daily; Certbot will only renew if needed
0 0,12 * * * root certbot renew --quiet --deploy-hook "systemctl reload nginx"

The --deploy-hook flag is important. Certbot can obtain a new certificate, but the web server will keep serving the old one until it is reloaded. Without a deploy hook, you have a new certificate on disk that nobody is using.

Other ACME Clients

Certbot is the most common ACME client, but it is not the only option.

acme.sh is a shell-based client that is popular in Docker environments and on systems where installing Certbot's Python dependencies is impractical. It has built-in support for dozens of DNS providers for DNS-01 validation.

Caddy has ACME built in. If you use Caddy as your web server, it handles certificate issuance and renewal automatically with zero configuration. You do not need Certbot or any external tool.

Traefik similarly integrates ACME and handles certificate management for all configured routes automatically.

When Auto-Renewal Fails

Auto-renewal is not foolproof. Common failure scenarios include DNS changes that break validation, expired API credentials for DNS-01 challenges, server migrations where the cron job was not recreated, and firewall changes that block the ACME challenge. Our detailed guide on why auto-renewal is not enough covers these failure modes in depth.

The defense against silent auto-renewal failures is monitoring. A monitoring tool that checks your live certificate's expiration date will catch failures regardless of the cause.

Manual Renewal for Commercial Certificates

If you use a paid certificate from a commercial CA, the renewal process involves more steps.

Step 1: Generate a New CSR

A Certificate Signing Request (CSR) contains your domain information and public key. Most organizations generate a new CSR for each renewal, which means generating a new key pair as well.

# Generate a new private key and CSR
openssl req -new -newkey rsa:2048 -nodes \
  -keyout example.com.key \
  -out example.com.csr \
  -subj "/CN=example.com/O=Your Company/L=City/ST=State/C=US"

Some organizations reuse the existing private key for renewals to simplify the process. This is technically valid but less secure than rotating keys. See the section on key rotation below.

Step 2: Submit the CSR to Your CA

Log into your CA's portal (DigiCert, Sectigo, GlobalSign, etc.) and submit the CSR. If you are renewing an existing certificate, most CAs have a "renew" workflow that pre-fills the domain and organization information.

Step 3: Complete Domain Validation

The CA will verify that you control the domain. Validation methods include:

• Email validation: The CA sends an email to an address at the domain (admin@, webmaster@, etc.)
• HTTP validation: Place a file at a specific URL on your server
• DNS validation: Create a specific CNAME or TXT record in your domain's DNS
• Organization validation (OV) or Extended validation (EV): Additional steps verifying the legal entity, which can take days

For DV (domain validation) certificates, this step takes minutes. For OV or EV certificates, plan for several days.

Step 4: Download and Install the New Certificate

Once issued, download the certificate and any intermediate certificates. Install them on your server.

Nginx:

ssl_certificate /etc/ssl/certs/example.com.crt;
ssl_certificate_key /etc/ssl/private/example.com.key;

Make sure the certificate file includes the full chain: your certificate followed by any intermediate certificates. An incomplete chain is one of the most common installation mistakes and will cause trust errors in some browsers and clients. Our guide on the SSL certificate chain explains how chains work and why order matters.

Apache:

SSLCertificateFile /etc/ssl/certs/example.com.crt
SSLCertificateKeyFile /etc/ssl/private/example.com.key
SSLCertificateChainFile /etc/ssl/certs/intermediate.crt

Step 5: Reload the Web Server

# Nginx
sudo nginx -t && sudo systemctl reload nginx

# Apache
sudo apachectl configtest && sudo systemctl reload apache2

Always test the configuration before reloading. A syntax error in the config will take the server down.

Key Rotation During Renewal

When you renew a certificate, you have two options regarding the private key.

Option 1: Generate a New Key Pair

This is the recommended approach. Each renewal uses a fresh private key. If the old key was ever compromised without your knowledge, the new certificate is unaffected. Most security best practices and the CA/Browser Forum recommend key rotation at each renewal.

Option 2: Reuse the Existing Key

You can generate a CSR using your existing private key and get a new certificate for the same key. This is simpler (no need to update key files on the server) and is sometimes used when key distribution is complex, such as when the same key is deployed to multiple servers or load balancers.

The risk is that if the key was compromised, reusing it means the new certificate is also compromised. Key rotation is a low-cost security improvement that most organizations should adopt.

Let's Encrypt and Certbot generate a new key for every renewal by default. If you use a commercial CA and manual renewal, you need to make this decision yourself.

Common Renewal Failures

Certificate and Key Mismatch

If you install a new certificate but forget to update the private key file (or vice versa), the web server will refuse to start or will serve the old certificate. Verify that the certificate and key match:

# These two commands should output the same modulus hash
openssl x509 -noout -modulus -in certificate.crt | openssl md5
openssl rsa -noout -modulus -in private.key | openssl md5

Incomplete Certificate Chain

The new certificate may come with different intermediate certificates than the old one. If you do not update the chain, browsers may show trust errors even though the leaf certificate is valid.

DNS Propagation Delays

If you use DNS validation and recently changed DNS providers, the validation records may not have propagated yet. Lower your TTL before making DNS changes to speed up propagation. If you are also renewing your domain, the domain renewal checklist covers how to coordinate both processes.

Expired Account or Payment

Commercial CA accounts may require active payment methods or subscriptions. An expired credit card or lapsed account can block renewal even when everything else is configured correctly.

Validation Email to the Wrong Address

If your CA uses email validation and the contact address has changed (the admin who set it up left the company), the validation email goes nowhere. Update your CA account contacts before the renewal window opens.

Post-Renewal Verification

Installing a new certificate is not the end of the process. You need to verify that everything works correctly.

Check the Certificate in a Browser

Visit your site in a browser and click the lock icon. Verify:

• The certificate is issued to the correct domain
• The expiration date is in the future (matching the new certificate, not the old one)
• The issuer is correct
• No certificate warnings appear

Test From Multiple Clients

Different clients handle certificate chains differently. Test with:

• Multiple browsers (Chrome, Firefox, Safari)
• curl from the command line
• An external SSL testing tool

# Quick check from the command line
curl -vI https://example.com 2>&1 | grep -A 5 "Server certificate"

# Detailed check with OpenSSL
openssl s_client -connect example.com:443 -servername example.com

Our guides on checking SSL certificates and using OpenSSL for verification cover these steps in detail.

Verify the Full Chain

Make sure the server is sending the complete certificate chain. Missing intermediates cause failures in some clients but not others, which makes them hard to diagnose.

# This shows the full chain
openssl s_client -connect example.com:443 -servername example.com -showcerts

Set Up Monitoring

After renewal, confirm that your SSL monitoring tool shows the new certificate and the updated expiration date. If you do not have monitoring, this is the time to set it up. Monitoring catches the next renewal failure before your users do.

A Renewal Timeline

Here is a practical timeline for managing SSL certificate renewals.

90 days before expiry: For commercial certificates, start the procurement or renewal process. For Let's Encrypt, verify that auto-renewal is configured and test with --dry-run.

30 days before expiry: Let's Encrypt auto-renewal should trigger. For commercial certificates, submit the CSR and complete validation. Monitor your certificate's expiration date to confirm renewal happened.

14 days before expiry: If the certificate has not been renewed, treat this as urgent. Diagnose the failure and renew manually if needed.

7 days before expiry: Emergency territory. Drop other work and get this resolved.

1 day before expiry: If you are reading this section in real time, renew immediately. Consider a quick manual renewal or temporary Let's Encrypt certificate to buy time.

For guidance on what happens if you miss the deadline entirely, see what happens when SSL expires. For a production-grade Let's Encrypt setup, our Let's Encrypt production guide covers the full configuration.

References

• Let's Encrypt Documentation, "Certificate Lifecycle," https://letsencrypt.org/docs/
• CA/Browser Forum, "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates," https://cabforum.org/baseline-requirements/
• Certbot Documentation, "Renewing Certificates," https://certbot.eff.org/docs/using.html#renewing-certificates