SSL Certificate Renewal Checklist

Which domain(s) does it cover? Check the Subject Alternative Names (SANs), not just the Common Name. A certificate for example.com might also cover www.example.com, api.example.com, and staging.example.com.

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName

Check who issued the current certificate:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null | openssl x509 -noout -issuer

Are you renewing with the same CA? Switching CAs? This affects the process.

Is it DV, OV, or EV? Single domain, multi-domain (SAN), or wildcard? The type determines the validation process and timeline.

List every server, load balancer, CDN, and service that uses this certificate. Common locations that get forgotten:

• Web servers (Nginx, Apache, IIS)
• Load balancers (AWS ALB/ELB, Cloudflare, Fastly)
• Reverse proxies
• Mail servers
• API gateways
• Docker containers with baked-in certificates
• Third-party services (CDNs, WAFs) where you uploaded the cert manually

If you're using Let's Encrypt with Certbot:

sudo certbot certificates

This shows all managed certificates and their renewal status. If auto-renewal is configured, verify the cron job or systemd timer is active:

sudo systemctl status certbot.timer

For most renewals, generate a fresh key pair:

openssl req -new -newkey rsa:2048 -nodes -keyout yourdomain.key -out yourdomain.csr -subj "/CN=yourdomain.com"

For certificates with multiple SANs, you'll need an OpenSSL config file or your CA's portal to specify all domains.

• Let's Encrypt: sudo certbot certonly --webroot -w /var/www/html -d yourdomain.com -d www.yourdomain.com (or use DNS validation for wildcard)
• Commercial CA: Log into the CA's portal, paste the CSR, select the renewal period, and complete payment
• AWS Certificate Manager: ACM auto-renews for certificates it manages. Verify in the console that renewal is in progress.

Depending on the validation method:

• HTTP validation: Place a file at a specific URL (Certbot does this automatically)
• DNS validation: Add a CNAME or TXT record to your domain's DNS
• Email validation: Respond to an email sent to admin@yourdomain.com or a similar address
• Organization validation (OV/EV): Respond to CA's verification calls and provide documentation

Once issued, download the certificate and any intermediate certificates. You need:

• The leaf certificate (your domain's cert)
• The intermediate certificate(s) (sometimes called the "CA bundle")
• Optionally, the root certificate (usually not needed -- it's in the browser's trust store)

Before touching your production server, confirm the new certificate is correct:

# Check that the key matches the certificate
openssl x509 -noout -modulus -in yourdomain.crt | openssl md5
openssl rsa -noout -modulus -in yourdomain.key | openssl md5

Both commands should output the same MD5 hash. If they don't, the key and certificate don't match.

# Verify the certificate chain
openssl verify -CAfile intermediate.crt yourdomain.crt

Most servers need a single file with the leaf certificate and intermediates concatenated:

cat yourdomain.crt intermediate.crt > fullchain.crt

Order matters: leaf certificate first, then intermediate(s), root last (if included).

Replace the old certificate files with the new ones and update the configuration if file paths changed.

Nginx:

ssl_certificate /etc/ssl/fullchain.crt;
ssl_certificate_key /etc/ssl/yourdomain.key;

Apache:

SSLCertificateFile /etc/ssl/yourdomain.crt
SSLCertificateKeyFile /etc/ssl/yourdomain.key
SSLCertificateChainFile /etc/ssl/intermediate.crt

Test the config before reloading:

# Nginx
sudo nginx -t

# Apache
sudo apachectl configtest

# Nginx
sudo systemctl reload nginx

# Apache
sudo systemctl reload apache2

Use reload not restart when possible -- reload applies the new certificate without dropping existing connections.

Remember that list from Phase 1? Go through every location where the certificate is installed:

• Upload to load balancers (AWS ALB/ELB, etc.)
• Update CDN configurations (Cloudflare, Fastly, CloudFront)
• Update any Docker images that include the certificate
• Update any services that pin the certificate

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null | openssl x509 -noout -dates -issuer

Confirm the notAfter date matches the new certificate, not the old one.

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null | grep "Verify return code"

Should return Verify return code: 0 (ok).

Check every domain covered by the certificate, not just the primary one:

for domain in yourdomain.com www.yourdomain.com api.yourdomain.com; do
  echo -n "$domain: "
  openssl s_client -connect $domain:443 -servername $domain </dev/null 2>/dev/null | openssl x509 -noout -enddate
done

Go to ssllabs.com/ssltest and run a full test. Verify you get an A or A+ grade. Check for chain issues, protocol warnings, and cipher suite problems.

If you're using SSL monitoring, verify the tool has picked up the new certificate and the expiry date has been updated. Some monitoring tools detect changes automatically; others need a manual refresh.

Delete or securely archive the old private key. There's no reason to keep it accessible after the certificate has been replaced.