SSL Certificate Monitoring and Management Guide

SSL certificates expire. When they do, browsers show full-screen security warnings that stop visitors in their tracks. No amount of good content or fast servers matters when your users see "Your connection is not private" instead of your website.

The problem is not that teams forget certificates exist. The problem is that certificate management has become more complex at the same time that certificate lifetimes have gotten shorter. In 2015, certificates lasted up to five years. Today, the industry standard is 90 days for Let's Encrypt and heading toward even shorter lifetimes. [1] Managing a handful of certificates manually was possible. Managing dozens or hundreds with 90-day lifetimes requires a system.

This guide covers everything you need to monitor, how to build workflows around certificate management, and what to do when something goes wrong.

---

Why certificate monitoring matters

An expired certificate does not just cause a browser warning. It causes a cascade of failures that affect your users, your revenue, and your reputation.

The immediate impact

When a certificate expires, browsers refuse to establish a secure connection. Users see a warning page that requires them to click through multiple screens to proceed, and most will not. Studies consistently show that 80 to 90 percent of visitors leave immediately when they encounter an SSL error. [2]

The impact goes beyond your website. Expired certificates can break:

• API connections. If your API uses TLS (and it should), expired certificates cause connection failures for every client. Mobile apps stop working. Integrations fail. Webhook deliveries bounce.
• Email delivery. Mail servers that use TLS for transport encryption may reject connections when certificates expire, causing email delivery failures.
• Internal services. Microservices communicating over TLS, VPN connections, database connections with TLS, and internal tools all depend on valid certificates.
• CDN and load balancer connections. If the certificate on your CDN or load balancer expires, your entire site goes down for all users, even if your origin server is perfectly healthy.

For real-world examples of these failures, see famous SSL expiry disasters.

Why auto-renewal is not enough

The most common response to certificate monitoring concerns is "we have auto-renewal set up." Auto-renewal is essential, but it is not a complete solution. There are many scenarios where auto-renewal fails silently:

• DNS validation failures. If your DNS provider has an outage or your API credentials have expired, automated DNS-01 challenges fail. The renewal attempt errors out, and the certificate continues ticking toward expiry.
• HTTP validation failures. If your server configuration has changed, if a WAF is blocking the validation path, or if a CDN is caching the challenge response incorrectly, HTTP-01 challenges fail.
• Credential rotation. The API keys or service account credentials used by your ACME client get rotated, and nobody updates the renewal automation.
• Server changes. You migrate to a new server or container and the renewal job does not come with it.
• Wildcard certificates. Wildcard certs require DNS-01 validation, which is more fragile than HTTP validation because it depends on DNS API access.
• Multiple certificate sources. Your organization uses certificates from different providers (Let's Encrypt for some, DigiCert for others, AWS ACM for cloud resources). Auto-renewal works differently for each one, and any of them can fail independently.

For a deeper look at these failure modes, see why auto-renew is not enough.

Monitoring is the safety net that catches renewal failures before they become outages. Monitor your website uptime as well, since certificate-caused downtime is one of the most preventable categories of outage.

What to monitor

Effective SSL monitoring goes beyond checking the expiry date. A certificate can be unexpired and still cause problems. Here is everything you should be watching.

Expiry dates

The most obvious metric. Every certificate has a notAfter field that defines when it expires. Your monitoring should alert you well before that date, with escalating urgency:

• 30 days before expiry: Informational alert. Renewal should happen automatically, but this is your early warning.
• 14 days before expiry: Warning alert. If auto-renewal was going to work, it should have by now. Investigate.
• 7 days before expiry: Urgent alert. Manual intervention is likely needed.
• 3 days before expiry: Critical alert. Escalate to on-call.
• 1 day before expiry: Emergency. Drop everything.

For how to check expiry dates manually, see how to check SSL expiration date. For a systematic approach, see SSL monitoring explained.

Certificate chain validity

A certificate is only as trustworthy as its chain. The certificate chain connects your server certificate to a trusted root certificate through one or more intermediate certificates. If any link in the chain is missing, expired, or untrusted, browsers reject the connection.

Common chain issues to monitor:

• Missing intermediate certificates. Your server certificate is valid, but the server is not sending the intermediate certificate. Some browsers cache intermediates and work fine; others do not. This creates intermittent failures that are hard to diagnose.
• Expired intermediate certificates. Less common but devastating when it happens. The root CA may have rotated its intermediate, and your server is still sending the old one.
• Cross-signed chain changes. Let's Encrypt's transition from the DST Root CA X3 cross-sign to its own ISRG Root X1 caused issues for older Android devices. Chain monitoring catches these transitions.

For how to inspect the chain manually, see how to decode an SSL certificate.

Certificate revocation

A certificate can be revoked before it expires if the private key is compromised, if the certificate was issued incorrectly, or if the domain ownership changes. Revoked certificates should not be trusted, but revocation checking is inconsistent across browsers. [3]

Monitor for:

• CRL (Certificate Revocation List) status. The traditional method where CAs publish lists of revoked certificates.
• OCSP (Online Certificate Status Protocol) status. A more modern method where browsers check a specific certificate's status in real time.
• OCSP stapling. Your server fetches the OCSP response and "staples" it to the TLS handshake, which is faster and more privacy-preserving. Monitor that stapling is working correctly.

TLS configuration

The certificate itself is only part of the equation. Your TLS configuration determines which protocols and cipher suites are offered. Monitor for:

• Protocol versions. TLS 1.0 and 1.1 are deprecated. Your server should only offer TLS 1.2 and TLS 1.3. If a server change or update re-enables old protocols, you want to know.
• Cipher suite strength. Weak cipher suites (like those using RC4 or 3DES) should be disabled. Monitor for configuration drift that re-enables them.
• HSTS headers. If you have implemented HTTP Strict Transport Security, monitor that the header continues to be served correctly. A missing HSTS header after a server change means browsers may stop enforcing HTTPS.

CAA records

Certificate Authority Authorization (CAA) DNS records specify which CAs are allowed to issue certificates for your domain. If an attacker or unauthorized team member requests a certificate from a CA not in your CAA record, the CA is required to refuse.

Monitor your CAA records to ensure they remain correct. If you switch CAs, you need to update CAA records first. If someone accidentally removes them, any CA can issue certificates for your domain.

Building a monitoring workflow

Knowing what to monitor is step one. Building a workflow that actually catches problems before they affect users is step two.

Inventory your certificates

You cannot monitor what you do not know about. Start with a complete inventory:

1. Production web servers. Every domain and subdomain that serves HTTPS traffic.
2. API endpoints. Internal and external APIs, including partner-facing endpoints.
3. Load balancers and CDNs. Certificates terminating TLS at the edge.
4. Mail servers. Certificates on SMTP, IMAP, and POP servers.
5. Internal services. VPNs, internal tools, development environments, CI/CD infrastructure.
6. Third-party services. SaaS tools on your custom domain, white-label services, and embedded content.
7. Wildcard certificates. Track which services depend on each wildcard cert.

For organizations with many certificates, see bulk SSL certificate tracking.

Centralize monitoring

Scattered monitoring creates gaps. If your web team monitors web server certificates, your DevOps team monitors infrastructure certificates, and nobody monitors the marketing team's landing page subdomains, you have blind spots.

Centralize certificate monitoring into a single dashboard that covers all certificates across all teams. This provides:

• Single source of truth. One place to see every certificate's status and expiry date.
• Consistent alerting. The same escalation thresholds applied everywhere, not different standards per team.
• Gap detection. Missing certificates are visible when everything is in one place.

Set up alerting

Alerts should be:

• Escalating. Earlier alerts go to the responsible team. Later alerts escalate to management and on-call.
• Actionable. Each alert should include the domain, the current expiry date, and a link to the management interface where the certificate can be renewed.
• Multi-channel. Do not rely on email alone. Use Slack, PagerDuty, SMS, or whatever your team uses for operational alerts.
• Tested. Periodically verify that alerts are working. A monitoring system that silently fails is worse than no monitoring because it creates false confidence.

Assign ownership

Every certificate should have a clear owner. Not a team, but a specific person (with a backup). When an alert fires at 2 a.m., ambiguity about who is responsible causes delays.

Document ownership in your certificate inventory. Update it when people change roles. Review it quarterly.

Let's Encrypt automation

Let's Encrypt has fundamentally changed certificate management by providing free, automated certificates with 90-day lifetimes. Getting automation right with Let's Encrypt eliminates most manual certificate work, but getting it wrong creates a fast-moving failure mode where certificates expire every 90 days instead of every year.

ACME protocol basics

Let's Encrypt uses the ACME (Automated Certificate Management Environment) protocol. [5] Your server runs an ACME client (Certbot is the most common) that automatically:

1. Generates a key pair
2. Proves domain ownership through a challenge (HTTP-01 or DNS-01)
3. Requests the certificate from Let's Encrypt
4. Installs the certificate on your server
5. Schedules automatic renewal

Common automation failures

• Certbot cron job not running. The renewal is scheduled via cron or systemd timer. If the timer gets disabled during a server update, renewals stop silently. Check that the timer is active, not just that it exists.
• Permission issues. Certbot needs write access to the certificate directory and read access to the webroot (for HTTP-01) or DNS API credentials (for DNS-01). Permission changes break renewal.
• Rate limits. Let's Encrypt enforces rate limits (50 certificates per domain per week, among others). [5] If your automation has a bug that causes repeated requests, you can hit rate limits and be unable to get a new certificate until the window resets.
• Port 80 blocked. HTTP-01 validation requires port 80 to be open. Firewall changes that block port 80 break renewal.
• Webroot path changed. If your web server's document root changes (new deployment, container rebuild), the HTTP-01 challenge file is placed in the wrong directory.

Best practices for Let's Encrypt automation

1. Renew at 60 days, not 89. Attempting renewal at 30 days before expiry gives you a full month to fix problems before the certificate actually expires.
2. Test renewal with --dry-run. Certbot's dry-run flag simulates a renewal without actually requesting a certificate. Run this in CI or as a periodic health check.
3. Monitor the renewal timer. Do not just set up the cron job and forget it. Monitor that it runs successfully.
4. Use DNS-01 for wildcards. Wildcard certificates require DNS-01 validation. Set up DNS API credentials and test the full flow.
5. Keep Certbot updated. ACME protocol changes and Let's Encrypt infrastructure updates require current client software.
6. Post-renewal hooks. Certbot supports --deploy-hook scripts that run after successful renewal. Use these to reload your web server, push certificates to CDNs, or notify your monitoring system.

Bulk certificate management

Organizations with more than a handful of certificates face a management challenge that individual certificate monitoring does not address.

The scale problem

A mid-sized company might have 50 to 200 certificates across production websites, staging environments, APIs, internal tools, and SaaS integrations. A large enterprise can have thousands. At this scale:

• Spreadsheet tracking fails because it depends on humans updating it
• Individual certificate monitoring tools become overwhelming with hundreds of alerts
• Certificates get provisioned by different teams with different tools and different renewal processes
• Shadow IT creates certificates that nobody in the security team knows about

For approaches to this problem, see bulk SSL certificate tracking and SSL certificate management strategy.

Certificate transparency logs

Certificate Transparency (CT) logs are public, append-only logs of every certificate issued by participating CAs. [6] You can monitor CT logs to:

• Discover certificates you did not know about. If someone issues a certificate for your domain, it will appear in CT logs.
• Detect unauthorized issuance. If a CA issues a certificate for your domain and you did not request it, this could indicate a security compromise.
• Track certificate inventory. CT log monitoring gives you a continuously updated view of all certificates issued for your domains.

Tools like Facebook's Certificate Transparency Monitoring, Censys, and crt.sh make it straightforward to set up CT log monitoring.

Multi-provider management

Many organizations use certificates from multiple sources:

• Let's Encrypt for most web properties
• DigiCert or Sectigo for EV (Extended Validation) certificates
• AWS ACM for services behind AWS load balancers
• Cloudflare for sites behind Cloudflare's edge
• Self-signed certificates for internal development environments

Each provider has different renewal processes, different management interfaces, and different failure modes. Your monitoring needs to cover all of them uniformly.

Incident response for certificate failures

When a certificate expires or fails, you need a fast, structured response. The mean time to detection and mean time to resolution directly determine how many users are affected.

Detection

Your monitoring should catch certificate failures before users do. But if monitoring misses it (or if monitoring itself is the service that failed), the first sign is usually:

• A spike in support tickets about "security warnings"
• Uptime monitoring alerts showing HTTPS endpoints as down
• API consumers reporting connection failures
• A team member noticing the warning while browsing the site

Immediate response

1. Confirm the issue. Check the certificate from multiple locations and devices. Use browser inspection, openssl s_client, or a certificate checking tool. See how to check an SSL certificate and how to check SSL in a browser.
2. Determine the scope. Is it one domain, multiple subdomains (wildcard cert), or multiple domains? Which services are affected?
3. Identify the cause. Expired certificate, revoked certificate, missing intermediate, misconfigured server, or a combination? See how to fix SSL errors and invalid SSL certificate for diagnosis steps.
4. Renew or replace. For expired certificates, renew immediately. For Let's Encrypt, run certbot renew --force-renewal. For other CAs, follow their renewal process. See the SSL certificate renewal guide.
5. Verify the fix. After installing the new certificate, verify from multiple locations that the certificate is valid, the chain is complete, and TLS is working correctly. See how to validate an SSL certificate.
6. Communicate. Notify affected users, partners, and API consumers. If the outage was significant, post a public status update.

Post-incident review

After resolving the immediate issue:

• Root cause analysis. Why did the certificate expire or fail? Was it a renewal automation failure, a human process gap, or a configuration error?
• Monitoring gap analysis. Why did monitoring not catch this earlier? Was the certificate not being monitored, or was the alert ignored?
• Process improvement. What changes to monitoring, alerting, or renewal processes will prevent this from happening again?
• Documentation. Update your certificate inventory, renewal procedures, and incident playbook.

Certificate lifecycle management

Effective certificate management covers the entire lifecycle from provisioning to decommissioning.

Provisioning

When provisioning a new certificate:

1. Choose the right certificate type: DV, OV, or EV based on your needs.
2. Decide between single-domain, wildcard, or SAN (Subject Alternative Name) based on your domain structure.
3. Select a certificate provider appropriate for your use case.
4. Configure DNS CAA records to restrict which CAs can issue for your domain.
5. Add the new certificate to your monitoring system immediately after installation.
6. Document the certificate's purpose, owner, and renewal process.

Renewal

For each certificate type:

• Let's Encrypt: Automated via ACME client. Monitor that automation is running.
• Commercial DV/OV: Typically annual renewal. Set calendar reminders and monitoring alerts.
• Commercial EV: Annual renewal with additional validation steps. Start the renewal process 30 days early because validation takes time.
• AWS ACM: Automatic renewal for DNS-validated certificates. Monitor via AWS health checks.
• Cloudflare Universal SSL: Managed by Cloudflare. Monitor via Cloudflare dashboard or API.

See the SSL renewal checklist for a step-by-step process.

Decommissioning

When a certificate is no longer needed:

1. Confirm that no services depend on it. Check DNS records for the associated domain.
2. Remove it from your monitoring to avoid false alerts about expected expiry.
3. If the associated domain is being retired, also check domain expiry to ensure the domain registration is handled appropriately.
4. Revoke the certificate if the private key may have been exposed.
5. Update your certificate inventory to reflect the decommission.

Security considerations

Certificate monitoring is also a security practice. Certificates are a key part of the trust infrastructure of the internet, and mismanagement creates security vulnerabilities.

Preventing unauthorized issuance

• CAA records. Configure DNS CAA records to restrict certificate issuance to authorized CAs only.
• CT log monitoring. Watch for certificates issued for your domains that you did not request.
• DNSSEC. If your domain supports DNSSEC, enable it to prevent DNS spoofing attacks that could be used to pass domain validation challenges.

Private key management

• Never share private keys across certificates or environments.
• Store private keys securely with appropriate file permissions (readable only by the web server process).
• Rotate private keys when renewing certificates, rather than reusing the old key.
• If a private key is compromised, revoke the certificate immediately and issue a new one with a new key.

Certificate pinning considerations

Certificate pinning (HPKP) is deprecated and should not be used. It was removed from Chrome in 2018 because the risks of misconfiguration (locking users out of your site permanently) outweighed the security benefits. [7] If you have legacy HPKP headers in place, remove them.

---

References

1. CA/Browser Forum, "Ballot SC-081: Introduce Schedule of Reducing Validity and Data Reuse Periods," April 2025. https://cabforum.org/2025/04/14/ballot-sc-081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/
2. Google, "HTTPS encryption on the web," Google Transparency Report. https://transparencyreport.google.com/https/overview
3. A. Langley, "Revocation checking and Chrome's CRL," Imperial Violet Blog. https://www.imperialviolet.org/2012/02/05/crlsets.html
4. Keyfactor, "2024 PKI and Digital Trust Report." https://www.keyfactor.com/resources/reports/pki-digital-trust-report/
5. Let's Encrypt, "ACME Protocol Documentation." https://letsencrypt.org/docs/
6. B. Laurie, A. Langley, E. Kasper, "Certificate Transparency," RFC 6962, IETF, June 2013. https://datatracker.ietf.org/doc/html/rfc6962
7. Google, "Intent to Remove: HTTP-Based Public Key Pinning," Chrome Platform Status, 2018. https://www.chromestatus.com/feature/5903385005916160
8. CA/Browser Forum, "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates." https://cabforum.org/baseline-requirements/