Certificate Lifecycle Management Checklist

TLS certificates are not a set-and-forget configuration. Every certificate has a lifecycle -- issuance, deployment, monitoring, renewal, and eventual replacement. With the CA/Browser Forum's decision to reduce maximum certificate lifespans to 47 days by 2029, effective lifecycle management is transitioning from a best practice to an operational requirement.

This checklist covers every stage of the certificate lifecycle, from building your inventory to automating renewal and preparing for the 47-day transition.

Certificate Inventory

You cannot manage certificates you do not know about. Building and maintaining a complete inventory is the foundation of lifecycle management.

Discovery Checklist

• Scan all domains for TLS certificates using CyberShield or similar tools
• Query certificate transparency logs for all certificates issued to your domains
• Check all web servers (production, staging, development)
• Check all load balancers and reverse proxies
• Check CDN configurations (Cloudflare, AWS CloudFront, Akamai, Fastly)
• Check email servers (SMTP, IMAP, POP3 with STARTTLS/TLS)
• Check VPN concentrators and remote access gateways
• Check API endpoints and microservice-to-microservice communications
• Check IoT and embedded devices with TLS capability
• Check third-party hosted services using your domain certificates

Inventory Documentation

For each certificate, record:

• Domain names (Common Name and Subject Alternative Names)
• Issuing certificate authority
• Certificate serial number
• Issuance date and expiration date
• Key type and size (RSA-2048, RSA-4096, ECDSA P-256, etc.)
• Deployment location(s) -- which servers, load balancers, or services use it
• Renewal method -- manual or automated (and which automation tool)
• Responsible team or individual
• Whether the certificate is wildcard or single-domain

Inventory Maintenance

• Review inventory monthly for accuracy
• Add new certificates as infrastructure is deployed
• Remove entries for decommissioned services
• Cross-reference against CT log discoveries for unknown certificates
• Flag certificates approaching expiration (30-day, 14-day, 7-day thresholds)

Certificate Issuance

Standardize your issuance process to ensure consistent quality and security.

CA Selection

• Select certificate authorities based on automation support (ACME protocol)
• Publish CAA records restricting issuance to authorized CAs only
• Document the approved CAs and their use cases

example.com.  IN  CAA  0 issue "letsencrypt.org"
example.com.  IN  CAA  0 issue "digicert.com"
example.com.  IN  CAA  0 issuewild "letsencrypt.org"
example.com.  IN  CAA  0 iodef "mailto:security@example.com"

Key Generation Standards

• Generate private keys on the server that will use them (never transfer keys)
• Use RSA-2048 as minimum key size (RSA-4096 for high-security applications)
• Prefer ECDSA P-256 for better performance with equivalent security
• Generate new private keys for each certificate renewal (do not reuse keys)
• Protect private keys with appropriate file permissions (readable only by the service user)

# Generate ECDSA private key
openssl ecparam -genkey -name prime256v1 -out server.key

# Generate RSA-2048 private key
openssl genrsa -out server.key 2048

# Set appropriate permissions
chmod 600 server.key

Certificate Request Standards

• Include all necessary domain names as Subject Alternative Names (SANs)
• Use wildcard certificates only when the use case justifies it (wildcard exposure risk)
• Prefer shorter validity periods (90 days via Let's Encrypt is already best practice; see our guide on the 47-day certificate revolution for what comes next)
• Verify domain ownership through the strongest available validation method

Certificate Deployment

Proper deployment ensures the certificate works correctly across all clients.

Pre-Deployment Verification

• Verify the certificate chain is complete (server cert + all intermediates)
• Verify the private key matches the certificate
• Test the certificate with multiple clients (browsers, curl, openssl s_client)

# Verify certificate and key match
openssl x509 -noout -modulus -in server.crt | openssl md5
openssl rsa -noout -modulus -in server.key | openssl md5
# Both MD5 hashes must match

# Test full chain
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

Server Configuration

Follow the TLS protocol and cipher hardening guide for detailed Nginx, Apache, and HAProxy examples:

• Configure TLS 1.2 as minimum protocol version
• Enable TLS 1.3
• Disable TLS 1.0 and TLS 1.1
• Configure strong cipher suites with forward secrecy
• Enable OCSP stapling

Nginx configuration:

ssl_certificate     /etc/ssl/certs/server-fullchain.pem;
ssl_certificate_key /etc/ssl/private/server.key;
ssl_protocols       TLSv1.2 TLSv1.3;
ssl_ciphers         'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
ssl_prefer_server_ciphers on;
ssl_stapling on;
ssl_stapling_verify on;

Apache configuration:

SSLCertificateFile    /etc/ssl/certs/server.crt
SSLCertificateKeyFile /etc/ssl/private/server.key
SSLCertificateChainFile /etc/ssl/certs/chain.pem
SSLProtocol           all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite        ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
SSLUseStapling on
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"

Post-Deployment Verification

• Verify certificate is served correctly via browser inspection
• Verify full chain with openssl s_client
• Run a CyberShield scan to confirm TLS module findings are clean
• Verify HSTS header is present and correct
• Check from multiple geographic locations if using CDN

HSTS Deployment

• Add Strict-Transport-Security header to all HTTPS responses
• Use minimum max-age of 31536000 (1 year)
• Include includeSubDomains directive
• Consider HSTS preload submission after confirming all subdomains support HTTPS

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Certificate Monitoring

Continuous monitoring catches issues before they cause outages.

Expiration Monitoring

• Alert at 30 days before expiration
• Alert at 14 days before expiration (escalated)
• Alert at 7 days before expiration (critical)
• Alert at 1 day before expiration (emergency)
• Monitor independently of the renewal system (the renewal system failing is what you are trying to detect)

Configuration Monitoring

• Schedule regular CyberShield scans (weekly for production)
• Alert on protocol version changes (unexpected TLS 1.0/1.1 re-enablement)
• Alert on cipher suite changes (weak ciphers appearing)
• Alert on HSTS removal or weakening
• Alert on certificate chain changes (missing intermediates)

Certificate Transparency Monitoring

• Monitor CT logs for new certificates issued to your domains
• Alert on certificates from unexpected CAs (compared to CAA records)
• Alert on certificates for unknown subdomains
• Investigate unexpected certificate issuance promptly

Certificate Renewal

Renewal is the highest-risk phase of the lifecycle, especially as lifespans shorten. Our TLS certificate management guide covers Certbot setup, automated renewal, and emergency procedures in detail.

Automation with ACME

For certificates that support ACME-based automation:

• Install and configure an ACME client (Certbot, acme.sh, Caddy, cert-manager)
• Verify automatic renewal is scheduled (systemd timer, cron job, Kubernetes operator)
• Configure renewal to happen well before expiration (at least 30 days for 90-day certs)
• Set up post-renewal hooks to reload services

Certbot renewal verification:

# Check timer is active
systemctl list-timers | grep certbot

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

# Configure post-renewal hook
cat > /etc/letsencrypt/renewal-hooks/deploy/reload.sh << 'EOF'
#!/bin/bash
systemctl reload nginx
EOF
chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload.sh

For Kubernetes with cert-manager:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: example-tls
spec:
  secretName: example-tls-secret
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
    - example.com
    - www.example.com
  renewBefore: 360h  # Renew 15 days before expiry

Manual Renewal Process

For certificates that cannot be automated:

• Document the renewal procedure step by step
• Assign a primary and backup responsible person
• Set calendar reminders at 60, 30, and 14 days before expiration
• Maintain a renewal checklist specific to each certificate
• Test the renewed certificate in staging before production deployment
• Plan for migrating these certificates to ACME automation

Renewal Failure Handling

• Define escalation procedures for failed renewals
• Maintain emergency contact information for your CAs
• Have backup certificates or a rapid re-issuance process documented
• Test renewal failure scenarios in staging environments
• Monitor for ACME rate limits that could block bulk renewals

Preparing for 47-Day Certificates

The CA/Browser Forum's SC-081 ballot mandates phased reductions in maximum certificate validity:

Date	Maximum Validity
Current	398 days
March 2026	200 days
March 2027	100 days
March 2029	47 days

Readiness Assessment

• Audit all certificates and classify by renewal method (automated vs manual)
• Identify all manually renewed certificates
• Evaluate ACME support for each infrastructure component
• Identify middleboxes, appliances, or services that do not support ACME
• Calculate renewal frequency at each validity milestone

Migration Plan

• Prioritize automating manually renewed certificates
• Deploy ACME for all web servers and load balancers
• Evaluate CDN and cloud provider automatic certificate management
• Plan replacements for infrastructure that cannot support ACME
• Test renewal pipelines under 47-day constraints
• Implement monitoring that accounts for shorter validity windows

Organizational Preparation

• Communicate timeline and impact to IT leadership
• Budget for automation tooling and infrastructure upgrades
• Train operations teams on ACME client management
• Update incident response procedures for certificate-related outages
• Establish SLAs for renewal failure response

Revocation and Key Compromise

When a private key is compromised, certificates must be revoked immediately.

Revocation Checklist

• Revoke the compromised certificate through your CA's revocation process
• Generate a new private key (never reuse a potentially compromised key)
• Issue a new certificate with the new key
• Deploy the new certificate to all affected services
• Verify OCSP stapling reflects the revocation
• Investigate how the key was compromised and remediate the root cause

Key Compromise Indicators

• Unauthorized certificates in CT logs signed with your key
• Unexpected TLS connections from unknown sources
• Private key files with unexpected modification timestamps
• Security incidents on servers where private keys are stored

Decommissioning

Properly retiring certificates prevents security gaps and inventory confusion.

Decommission Checklist

• Confirm the certificate is no longer serving any active service
• Remove the certificate and private key from all servers
• Revoke the certificate if it has remaining validity
• Remove associated ACME renewal configuration
• Remove monitoring alerts for the decommissioned certificate
• Update inventory to reflect removal
• Remove or update DNS records (TLSA, CAA) if applicable

Verification With CyberShield

CyberShield's TLS module validates your certificate lifecycle management effectiveness:

• Certificate validity: Confirms certificates are current and not approaching expiration
• Protocol versions: Verifies TLS 1.2+ enforcement across all services
• Cipher suites: Checks for strong ciphers with forward secrecy
• Certificate chains: Validates complete chains from server to root
• HSTS: Confirms Strict-Transport-Security is deployed
• OCSP stapling: Checks for OCSP response in the TLS handshake

Run CyberShield scans after every certificate change to verify correct deployment. Schedule weekly scans to catch expiration issues before they affect service availability. Use score trends to confirm your certificate management practices are maintaining consistent TLS health.