CrtMgr Blog - SSL/TLS Certificate Management Insights

Expert insights on SSL/TLS certificate management, types, deployment, and best practices

SSL/TLS Certificate Lifecycle Management Best Practices

SSL TLS Certificate Management Security Best Practices

Proper SSL/TLS certificate lifecycle management is critical for maintaining secure, reliable web services. Poor certificate management leads to outages, security vulnerabilities, and compliance issues. This guide covers best practices for every stage of the certificate lifecycle.

Understanding the Certificate Lifecycle

The SSL/TLS certificate lifecycle consists of several key stages:

  1. Planning: Determining certificate requirements
  2. Issuance: Obtaining certificates from Certificate Authorities
  3. Deployment: Installing certificates on servers and applications
  4. Monitoring: Tracking certificate status and expiration
  5. Renewal: Replacing certificates before expiration
  6. Revocation: Invalidating compromised or obsolete certificates
  7. Retirement: Removing and archiving expired certificates

Each stage requires careful attention to maintain security and availability.

Stage 1: Planning and Preparation

Inventory Your Assets

Before obtaining certificates, create a comprehensive inventory:

What to Track:

  • Domain names and subdomains
  • IP addresses requiring certificates
  • Applications and services needing certificates
  • Server locations and platforms
  • Certificate types needed (DV, OV, EV)

Tools for Inventory:

  • Network scanning tools (Nmap, Masscan)
  • Certificate discovery services
  • Asset management databases
  • CrtMgr for ongoing tracking

Determine Certificate Requirements

Certificate Types:

  • Domain Validated (DV): Basic validation, quick issuance
  • Organization Validated (OV): Business verification included
  • Extended Validation (EV): Highest validation level, green bar in old browsers
  • Wildcard: Covers all subdomains (*.example.com)
  • Multi-Domain (SAN): Covers multiple specific domains

Key Size Selection:

  • RSA 2048-bit: Industry standard, good balance
  • RSA 4096-bit: Extra security, more CPU overhead
  • ECDSA P-256: Efficient, modern alternative
  • ECDSA P-384: Higher security ECDSA option

Certificate Lifetime:

  • Industry maximum: 398 days
  • Let’s Encrypt: 90 days (encourages automation)
  • Internal certificates: Follow organizational policy

Choose Certificate Authorities

Factors to Consider:

  • Trust: Browser and OS trust store inclusion
  • Price: Ranges from free (Let’s Encrypt) to expensive (EV certificates)
  • Support: Technical support availability
  • Features: Automation support (ACME), warranty, validation speed
  • Compliance: Meets industry requirements (PCI DSS, HIPAA, etc.)

Popular CAs:

  • Let’s Encrypt (free, automated)
  • DigiCert (enterprise, high trust)
  • Sectigo (formerly Comodo)
  • GlobalSign
  • GoDaddy
  • Entrust

Stage 2: Certificate Issuance

Generate Private Keys Securely

Best Practices:

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

# Generate RSA key with encryption
openssl genrsa -aes256 -out private.key 2048

# Generate ECDSA key (modern alternative)
openssl ecparam -genkey -name prime256v1 -out private.key

Security Considerations:

  • Generate keys on secure systems
  • Use hardware security modules (HSMs) for critical keys
  • Never reuse private keys across certificates
  • Protect keys with filesystem permissions (chmod 600)
  • Consider key escrow for disaster recovery

Create Certificate Signing Requests

# Generate CSR for single domain
openssl req -new -key private.key -out request.csr \
  -subj "/C=US/ST=California/L=San Francisco/O=Example Inc/CN=example.com"

# Generate CSR with Subject Alternative Names
openssl req -new -key private.key -out request.csr \
  -subj "/C=US/ST=California/L=San Francisco/O=Example Inc/CN=example.com" \
  -addext "subjectAltName = DNS:example.com,DNS:www.example.com,DNS:mail.example.com"

CSR Best Practices:

  • Provide accurate organization information
  • Include all required SANs (Subject Alternative Names)
  • Use appropriate Common Name (CN)
  • Keep CSR for documentation

Submit and Validate

Validation Methods:

  1. Email Validation:

    • CA sends email to admin@domain, webmaster@domain, etc.
    • Click link to verify control
  2. DNS Validation:

    • Add TXT record to DNS
    • CA verifies record presence
    • Best for automated systems (ACME)
  3. HTTP Validation:

    • Upload file to website
    • CA retrieves and verifies file
    • Works well with web servers
  4. File Validation:

    • Similar to HTTP validation
    • Upload verification file to specific path

Use ACME Protocol for Automation

ACME (Automatic Certificate Management Environment) enables automated issuance:

# Using Certbot (Let's Encrypt)
certbot certonly --standalone -d example.com -d www.example.com

# Using acme.sh
acme.sh --issue -d example.com -d www.example.com --webroot /var/www/html

# Using lego
lego --email="[email protected]" --domains="example.com" --http run

ACME Benefits:

  • Fully automated issuance
  • Automatic validation
  • Easy renewal
  • No manual intervention

Stage 3: Deployment

Pre-Deployment Testing

Before deploying to production:

# Verify certificate content
openssl x509 -in certificate.crt -noout -text

# Check certificate and key match
openssl x509 -in certificate.crt -noout -modulus | openssl md5
openssl rsa -in private.key -noout -modulus | openssl md5

# Verify certificate chain
openssl verify -CAfile ca-bundle.crt certificate.crt

Secure Deployment Process

Deployment Checklist:

  • Backup existing certificates
  • Verify certificate files are correct
  • Test in staging environment first
  • Plan rollback procedure
  • Schedule deployment during maintenance window
  • Have monitoring in place

Server-Specific Deployment:

Nginx:

ssl_certificate /etc/ssl/certs/fullchain.pem;
ssl_certificate_key /etc/ssl/private/privkey.pem;

Apache:

SSLCertificateFile /etc/ssl/certs/certificate.crt
SSLCertificateKeyFile /etc/ssl/private/private.key
SSLCertificateChainFile /etc/ssl/certs/chain.pem

Tomcat (requires Java keystore):

# Import into keystore
keytool -importkeystore -srckeystore cert.p12 -srcstoretype PKCS12 \
  -destkeystore keystore.jks -deststoretype JKS

Post-Deployment Verification

# Test HTTPS connectivity
curl -I https://example.com

# Verify certificate served
echo | openssl s_client -connect example.com:443 -servername example.com

# Check expiration date
echo | openssl s_client -connect example.com:443 2>/dev/null | \
  openssl x509 -noout -dates

# Test from multiple locations
# Use online tools: SSL Labs, Security Headers

Stage 4: Monitoring

Continuous Monitoring Setup

What to Monitor:

  • Certificate expiration dates
  • Certificate validity (not revoked)
  • Certificate chain completeness
  • Protocol and cipher configuration
  • Server availability

Monitoring Tools:

  1. CrtMgr:

    • Add domains to dashboard
    • Set expiration alerts (30, 7, 1 days)
    • Public status pages for transparency
    • Email notifications
  2. Nagios/Icinga:

    check_ssl_cert -H example.com -w 30 -c 7
    
  3. Prometheus:

    - job_name: 'ssl_expiry'
      metrics_path: /probe
      params:
        module: [http_2xx]
      static_configs:
        - targets:
          - https://example.com
    
  4. Custom Scripts:

    #!/bin/bash
    DOMAIN="example.com"
    WARN_DAYS=30
    
    EXPIRY=$(echo | openssl s_client -connect $DOMAIN:443 -servername $DOMAIN 2>/dev/null | \
             openssl x509 -noout -enddate | cut -d= -f2)
    
    EXPIRY_EPOCH=$(date -d "$EXPIRY" +%s)
    NOW_EPOCH=$(date +%s)
    DAYS_LEFT=$(( ($EXPIRY_EPOCH - $NOW_EPOCH) / 86400 ))
    
    if [ $DAYS_LEFT -lt $WARN_DAYS ]; then
        echo "Warning: Certificate expires in $DAYS_LEFT days"
        # Send alert
    fi
    

Alert Configuration

Multi-Threshold Alerts:

  • 60 days: Info notification
  • 30 days: Warning notification
  • 14 days: Warning + escalation
  • 7 days: Critical alert
  • 1 day: Emergency alert + multiple channels

Alert Channels:

  • Email notifications
  • SMS/text messages
  • Slack/Teams/Discord
  • PagerDuty/OpsGenie
  • Webhook integrations

Certificate Transparency Monitoring

Monitor Certificate Transparency logs for unauthorized certificates:

# Check CT logs for your domain
curl "https://crt.sh/?q=example.com&output=json"

# Use monitoring services
# - SSLMate Certspotter
# - Facebook Certificate Transparency Monitoring
# - Google CT Monitor

Stage 5: Renewal

Renewal Strategy

When to Renew:

  • Start renewal process at 2/3 of certificate lifetime
  • 90-day cert: Renew at 60 days
  • 398-day cert: Renew at 265 days
  • Never wait until last week

Renewal Methods:

  1. Manual Renewal (not recommended):

    • Generate new CSR
    • Submit to CA
    • Deploy new certificate
  2. Semi-Automated:

    • Automated renewal script
    • Manual deployment review
    • Good for critical systems
  3. Fully Automated (recommended):

    • ACME protocol
    • Automated deployment
    • Automatic rollback on failure

Automated Renewal Implementation

Certbot with Hooks:

# Renewal with pre/post hooks
certbot renew --deploy-hook "/etc/letsencrypt/renewal-hooks/deploy/restart-services.sh"

Deploy hook script:

#!/bin/bash
# /etc/letsencrypt/renewal-hooks/deploy/restart-services.sh

# Reload web server
systemctl reload nginx

# Reload other services using certificates
systemctl reload postfix
systemctl reload dovecot

# Log renewal
echo "$(date): Certificate renewed for $RENEWED_DOMAINS" >> /var/log/cert-renewal.log

Acme.sh with Auto-Renewal:

# Install and configure
acme.sh --install --auto-upgrade

# Issue certificate with auto-renewal
acme.sh --issue -d example.com --nginx --renew-hook "systemctl reload nginx"

Testing Renewal Process

Regular Testing:

# Dry-run renewal (Certbot)
certbot renew --dry-run

# Force renewal for testing
certbot renew --force-renewal --cert-name example.com

# Test specific domain
acme.sh --renew -d example.com --force

Post-Renewal Verification:

  • Check new certificate is served
  • Verify expiration date is updated
  • Test application functionality
  • Confirm monitoring shows new expiration

Stage 6: Revocation

When to Revoke

Revoke certificates immediately if:

  • Private key is compromised
  • Certificate was issued incorrectly
  • Domain ownership changed
  • Server was breached
  • Key was exposed in code repository
  • Compliance requirement

Revocation Process

Using CA Portal:

  1. Log into CA account
  2. Find certificate to revoke
  3. Provide revocation reason
  4. Confirm revocation
  5. Wait for CRL/OCSP update

Using ACME:

# Revoke certificate (Certbot)
certbot revoke --cert-path /etc/letsencrypt/live/example.com/cert.pem

# Revoke with specific reason
certbot revoke --cert-path /path/to/cert.pem --reason keyCompromise

Revocation Reasons:

  • unspecified: No specific reason
  • keyCompromise: Private key was compromised
  • caCompromise: CA was compromised
  • affiliationChanged: Subject details changed
  • superseded: Certificate replaced
  • cessationOfOperation: Service discontinued

Post-Revocation Steps

  1. Deploy New Certificate:

    • Generate new private key
    • Obtain new certificate
    • Deploy immediately
  2. Verify Revocation:

    # Check OCSP status
    openssl ocsp -issuer chain.pem -cert cert.pem \
      -url http://ocsp.ca.com -header "HOST" "ocsp.ca.com"
    
    # Expected: "revoked"
    
  3. Update Monitoring:

    • Remove revoked certificate from monitoring
    • Add new certificate
    • Update documentation
  4. Incident Response:

    • Document incident
    • Review access logs
    • Implement preventive measures

Stage 7: Retirement and Archiving

Proper Certificate Retirement

When to Retire:

  • Certificate has expired
  • Service has been decommissioned
  • Certificate has been replaced

Retirement Process:

  1. Verify certificate is no longer in use
  2. Remove from active servers
  3. Update DNS records if needed
  4. Archive certificate and related documentation
  5. Update inventory and monitoring

Archival Best Practices

What to Archive:

  • Certificate files
  • Private keys (encrypted)
  • CSR used for issuance
  • CA documentation
  • Deployment history
  • Incident reports

Archival Storage:

# Create encrypted archive
tar -czf cert-archive-$(date +%Y%m%d).tar.gz \
  certificate.crt private.key request.csr \
  | gpg --encrypt --recipient [email protected] > cert-archive.tar.gz.gpg

# Store securely
# - Encrypted backup system
# - Off-site storage
# - Access-controlled location

Retention Policies:

  • Keep archives for compliance period (typically 3-7 years)
  • Encrypt archived private keys
  • Implement access controls
  • Document chain of custody
  • Periodic audit of archives

Automation and Tools

Certificate Management Tools

For Small to Medium Scale:

  • CrtMgr: Simple monitoring and alerts
  • Certbot: Let’s Encrypt automation
  • acme.sh: Lightweight ACME client

For Enterprise Scale:

  • HashiCorp Vault: Full PKI and secrets management
  • Venafi: Enterprise certificate lifecycle platform
  • Cert-Manager: Kubernetes-native certificates
  • AWS Certificate Manager: AWS-integrated solution

Infrastructure as Code

Terraform Example:

resource "acme_certificate" "certificate" {
  account_key_pem = file("account.key")
  common_name     = "example.com"
  
  subject_alternative_names = [
    "www.example.com",
    "mail.example.com"
  ]
  
  dns_challenge {
    provider = "route53"
  }
}

Ansible Example:

- name: Ensure SSL certificate
  community.crypto.acme_certificate:
    account_key_src: /path/to/account.key
    csr: /path/to/csr.pem
    dest: /path/to/certificate.crt
    challenge: dns-01
    acme_directory: https://acme-v02.api.letsencrypt.org/directory

Common Pitfalls and How to Avoid Them

1. Certificate Expiration

Problem: Certificates expire unexpectedly, causing outages

Prevention:

  • Use monitoring tools like CrtMgr
  • Set multiple alert thresholds
  • Automate renewal process
  • Test renewal regularly
  • Have emergency procedures

2. Incomplete Certificate Chains

Problem: Browsers show “Certificate not trusted” errors

Prevention:

  • Always include intermediate certificates
  • Verify chain before deployment
  • Test from multiple browsers
  • Use SSL Labs for validation

3. Private Key Exposure

Problem: Private keys committed to repositories or stored insecurely

Prevention:

  • Use .gitignore for key files
  • Scan repositories for exposed keys (git-secrets, truffleHog)
  • Implement proper file permissions
  • Use HSMs for critical keys
  • Regular security audits

4. Weak Cryptography

Problem: Using outdated protocols or weak ciphers

Prevention:

  • Disable SSLv3, TLS 1.0, TLS 1.1
  • Use modern cipher suites
  • Regular security configuration reviews
  • Follow Mozilla SSL Configuration Generator
  • Test with SSL Labs

5. Lack of Documentation

Problem: Certificate configurations undocumented, causing confusion

Prevention:

  • Document all certificates and locations
  • Maintain runbooks for common tasks
  • Track certificate properties in database
  • Use version control for configurations
  • Implement change management

Compliance and Audit

Regulatory Requirements

Common Standards:

  • PCI DSS: Requires encryption of cardholder data
  • HIPAA: Mandates encryption for healthcare data
  • GDPR: Requires protection of personal data
  • SOC 2: Security controls for service organizations

Audit Preparation

What Auditors Check:

  • Certificate inventory completeness
  • Expiration monitoring evidence
  • Renewal procedures documentation
  • Incident response records
  • Key management practices
  • Revocation procedures

Audit Readiness:

# Generate certificate inventory report
for cert in /etc/ssl/certs/*.crt; do
    echo "Certificate: $cert"
    openssl x509 -in "$cert" -noout -subject -issuer -dates
    echo "---"
done > certificate-inventory.txt

# Document certificate locations
# Create process flowcharts
# Maintain change logs
# Keep renewal evidence

Metrics and KPIs

Track Certificate Health

Key Metrics:

  • Certificate Coverage: Percentage of assets with valid certificates
  • Time to Renewal: Days before expiration when renewed
  • Renewal Success Rate: Percentage of successful automatic renewals
  • Mean Time to Deploy: Time from issuance to deployment
  • Incident Rate: Certificate-related incidents per month

Reporting:

# Generate monthly report
#!/bin/bash

echo "Certificate Management Monthly Report"
echo "====================================="
echo "Date: $(date)"
echo ""
echo "Total Certificates: $(count_certificates)"
echo "Expiring in 30 days: $(count_expiring 30)"
echo "Expired: $(count_expired)"
echo "Successful Renewals: $(count_renewals)"
echo "Failed Renewals: $(count_failures)"

Conclusion

Effective certificate lifecycle management requires:

  1. Planning: Comprehensive inventory and requirements
  2. Automation: ACME protocol and automated renewal
  3. Monitoring: Continuous tracking with tools like CrtMgr
  4. Process: Documented procedures for all stages
  5. Security: Protection of private keys and proper revocation
  6. Compliance: Meeting regulatory requirements

Key Takeaways:

  • Automate everything possible
  • Monitor certificates continuously
  • Renew early (at 2/3 of lifetime)
  • Document all processes
  • Test procedures regularly
  • Use proper tools (CrtMgr, Certbot, etc.)
  • Plan for incidents

With proper lifecycle management, certificates become a security enabler rather than a source of outages and incidents. Tools like CrtMgr simplify monitoring, while automation handles the repetitive tasks, allowing you to focus on security and reliability.

Related Articles