What Happens When an SSL Certificate Expires
An expired SSL certificate is one of the most preventable — yet surprisingly common — causes of website downtime. When your certificate expires, browsers immediately display a full-page security warning that blocks visitors from reaching your content. In Chrome, it's the infamous "Your connection is not private" error. In Firefox, a similar "Warning: Potential Security Risk Ahead" page takes over.
The consequences cascade quickly. Users lose trust instantly — most visitors will hit the back button rather than click through a security warning, even if they recognize your brand. For e-commerce sites, a certificate expiration during peak hours can mean thousands in lost revenue per minute. And the damage extends beyond immediate traffic loss.
Search engines take SSL seriously. Google has used HTTPS as a ranking signal since 2014, and an expired certificate can trigger a temporary drop in search rankings. Crawlers that encounter certificate errors may reduce crawl frequency or de-index pages entirely. Recovery after a certificate lapse can take days to weeks, depending on how long the expiration went unnoticed.
The irony is that most certificate expirations happen not because of technical complexity, but because of human oversight. Someone forgot to renew. The renewal email went to an ex-employee's inbox. The credit card on file expired. Auto-renewal was configured but silently failed. These are exactly the kinds of failures that automated monitoring is designed to catch.
Manual vs. Automated SSL Monitoring
The most basic way to check a certificate is the openssl command-line tool. You can inspect any domain's certificate details with a single command:
openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates
This returns the notBefore and notAfter dates, telling you exactly when the certificate was issued and when it expires. For a quick one-off check, this works fine. But it has obvious limitations: you have to remember to run it, you have to check every domain individually, and there's no alerting if you forget.
Some teams write cron jobs that run openssl checks on a schedule and send email alerts. This is a step up, but introduces its own maintenance burden — the monitoring script itself becomes another thing that can silently break. If the server running your cron job goes down, or the email delivery fails, you're back to square one.
Automated SSL monitoring services solve these problems by checking your certificates from external infrastructure, on a reliable schedule, with multiple notification channels. They don't depend on your own servers, and they catch issues that internal checks miss — like certificates that are valid but misconfigured, or intermediate chain problems that only affect certain clients.
How SSL Monitoring Works Under the Hood
When an SSL monitoring service checks your domain, it initiates a full TLS handshake — the same process a browser goes through when connecting to your site. During this handshake, the service retrieves the server's certificate chain and extracts critical metadata:
- Expiration date — The exact timestamp when the certificate becomes invalid
- Issuer — The Certificate Authority (CA) that signed the certificate
- Subject and SANs — The domains the certificate covers
- Chain completeness — Whether all intermediate certificates are properly served
- Protocol version — The TLS version negotiated during the handshake
The monitoring service then compares the expiration date against configurable thresholds. Most teams set up a cascading alert schedule: an initial heads-up at 30 days before expiration, a more urgent reminder at 14 days, and a critical alert at 7 days. This gives you multiple opportunities to act before the certificate actually expires.
The key advantage of external monitoring is perspective. Your monitoring service connects from outside your network, through the same path your users take. This means it catches issues like load balancers serving the wrong certificate, CDN misconfigurations, or DNS changes that point to a server with a different (or expired) cert.
Step-by-Step: Setting Up SSL Monitoring with GoPinger
Getting SSL certificate monitoring running takes less than a minute. Here's how to set it up:
- Create an HTTPS monitor — In your GoPinger dashboard, click "Add Monitor" and enter your full URL (e.g.,
https://yourdomain.com). The protocol must be HTTPS for SSL checks to activate. - Enable SSL certificate alerts — In the monitor settings, toggle on SSL certificate monitoring. This tells GoPinger to inspect the certificate on every check, not just the HTTP response.
- Configure expiration thresholds — Set when you want to be notified. The recommended setup is alerts at 30, 14, and 7 days before expiration. This gives your team enough runway to renew without panic.
- Choose notification channels — Route SSL alerts to email, Slack, webhooks, or all three. For certificate expirations specifically, it's worth sending alerts to a shared channel rather than an individual — you don't want renewal to depend on one person seeing an email.
- Verify the check — After saving, GoPinger immediately performs an initial check. You'll see your certificate's current expiration date, issuer, and validity status right in the dashboard.
The free plan includes SSL monitoring on all your monitors, so there's no reason to leave certificates unmonitored even on side projects or staging environments.
Monitoring Multiple Domains, Wildcards, and SANs
Modern web infrastructure rarely involves just one domain. You might have your main site on example.com, your API on api.example.com, a staging environment on staging.example.com, and a marketing site on a completely different domain. Each of these needs its own SSL monitoring.
Wildcard certificates (e.g., *.example.com) cover all subdomains under a single domain, which simplifies management. But they introduce a single point of failure — if the wildcard cert expires, every subdomain goes down simultaneously. This makes monitoring even more critical, not less.
SAN (Subject Alternative Name) certificates cover multiple specific domains on a single certificate. They're common with services like Cloudflare or cloud load balancers. When monitoring SAN certificates, verify that all the domains you expect are actually listed as alternative names. A certificate renewal that accidentally drops a SAN entry will cause failures on that specific domain while everything else looks fine.
The best practice is to create a separate monitor for each domain and subdomain you serve over HTTPS, even if they share the same underlying certificate. This way, you catch per-endpoint misconfigurations — like a load balancer node serving a stale certificate — that a single domain check would miss.
Common SSL Issues Beyond Expiration
Certificate expiration gets the most attention, but it's not the only SSL problem that can take down your site or erode user trust. Here are the other issues worth monitoring for:
Incomplete Certificate Chains
Your server needs to send not just your certificate, but also the intermediate certificates that link it to a trusted root CA. If an intermediate is missing, some browsers will still work (they cache intermediates), but others — especially mobile browsers and API clients — will fail with a trust error. This creates intermittent, hard-to-reproduce issues.
Mixed Content Warnings
Even with a valid certificate, loading resources (images, scripts, stylesheets) over plain HTTP triggers browser warnings and can break functionality. Modern browsers block mixed active content entirely. An SSL monitoring check that also verifies page content can catch these issues.
Deprecated TLS Versions
TLS 1.0 and 1.1 are officially deprecated and no longer supported by major browsers. If your server still negotiates these older protocols, security scanners will flag it, and some clients will refuse to connect. Ensure your server supports TLS 1.2 at minimum, with TLS 1.3 preferred.
HSTS Misconfiguration
HTTP Strict Transport Security (HSTS) tells browsers to only connect over HTTPS. Once set, it's enforced for the duration of the max-age header. If you deploy HSTS and then have a certificate issue, users literally cannot access your site — browsers won't allow them to click through the warning. Monitor your certificates more aggressively if HSTS is enabled.
Free vs. Paid SSL Monitoring Tools
There are several options for monitoring SSL certificates, ranging from free services to enterprise solutions. Here's how the most popular options compare:
| Tool | Price | Auto Alerts | Threshold Config | Chain Checks | Multi-Domain |
|---|---|---|---|---|---|
| GoPinger | Free tier available | Yes (email, Slack, webhook) | 30/14/7 day custom | Yes | Yes |
| SSL Labs | Free | No (manual scan) | N/A | Yes | One at a time |
| CertSpotter | Free (limited) | CT log alerts | No | No | Yes |
SSL Labs by Qualys is excellent for one-time deep analysis — it gives you a letter grade and detailed breakdown of your SSL configuration. But it's a manual tool with no ongoing monitoring or alerts. It's best used as a complement to automated monitoring, not a replacement.
CertSpotter monitors Certificate Transparency logs, which is useful for detecting unauthorized certificate issuance for your domains. However, it doesn't check your actual server configuration or alert on approaching expiration dates.
For most teams, the ideal setup is an automated monitoring service like GoPinger for continuous checks and alerts, combined with an occasional SSL Labs scan for deep configuration audits. You can see how GoPinger compares to other monitoring tools in our UptimeRobot comparison.
SSL Monitoring Checklist
Use this checklist to ensure your SSL monitoring covers all the bases:
- Every HTTPS domain and subdomain has an active SSL monitor
- Expiration alerts are set at 30, 14, and 7 days before expiry
- Alerts go to a shared channel (not just one person's email)
- Certificate chain completeness is verified on each check
- Wildcard certificates are monitored via individual subdomain checks
- Staging and development environments are monitored too
- TLS protocol version is TLS 1.2 or higher
- HSTS-enabled domains have extra-aggressive monitoring thresholds
- Auto-renewal is configured and monitored (don't assume it works)
- A quarterly SSL Labs scan is scheduled for configuration audits
An expired SSL certificate is never a technical problem — it's a process problem. Automated monitoring turns certificate renewal from a hope-based system into a reliable, alertable workflow. Set it up once, and you'll never wake up to a browser warning page again.
Start Monitoring Your Certificates Today
SSL certificate monitoring is one of the highest-value, lowest-effort improvements you can make to your site reliability. It takes seconds to set up, costs nothing on the free tier, and prevents one of the most embarrassing types of outages.
If you're already monitoring uptime, adding SSL checks is a natural next step. If you're not monitoring anything yet, SSL is a great place to start — it gives you immediate, tangible value with zero configuration complexity. For a broader approach, check out our guide on website monitoring best practices.
Start monitoring free — add your first HTTPS monitor and have SSL alerts running in under a minute.