$ guides / apache-httpd / apache-httpd-certificate-expired ▌

Operations Guides

Apache SSL certificate expired: the total, preventable HTTPS outage

Every HTTPS client is failing at once. Browsers show NET::ERR_CERT_DATE_INVALID, API clients throw certificate validation errors, monitoring probes time out, and your access logs have gone quiet because no TLS handshake ever completes. Apache itself is running fine: the process is up, workers are idle, and port 443 accepts TCP connections. The failure is at the TLS layer, before any HTTP request exists.

This is one of the most deterministic outages in operations. A certificate has a notAfter date baked into it at issuance. The moment that date passes, every client that validates certificates rejects the connection. There is no degraded mode and no partial failure. It works until the second it does not, and then it works for nobody.

It is also one of the most preventable outages. The expiry date is knowable months in advance with a single openssl command. The fix is fast, but the post-incident question matters more: why did a date you could have known 90 days ago take the site down?

What this means

Clients validate the server certificate during the TLS handshake, before Apache processes any request. When the certificate is expired, the client aborts the handshake. From Apache’s perspective, almost nothing happened: a TCP connection opened, some TLS bytes were exchanged, and the client went away. The failed requests never appear in the access log, which is why an expired cert looks like a traffic cliff with no corresponding error spike in the places most teams watch first.

Two properties make this failure operationally distinct:

Cert expiry is not an Apache metric. mod_status exposes nothing about certificate validity. The scoreboard, worker states, and error counters will all look healthy. You need an external check, either against the live listener with openssl s_client or against the certificate file on disk.
Each SSL virtual host can have its own certificate. Checking the default vhost tells you nothing about the others. A green checkmark on one hostname can hide an expired cert on another vhost served from the same Apache instance.

A related failure: a hostname or SNI mismatch, where the certificate is valid but for the wrong name, also fails client-side during the handshake and is similarly invisible in access logs.

Common causes

Cause	What it looks like	First thing to check
Auto-renewal failed silently	On-disk cert is expired; renewal tool logs show failed attempts	Renewal tool logs (e.g. certbot) for the failing domain
Renewal succeeded but Apache still serves the old cert	On-disk cert is valid; served cert is expired	Compare the served cert enddate to the on-disk file
Failed config reload after renewal	Error log shows no recent “resuming normal operations”; configtest errors	`apachectl configtest` and the error log around reload time
Config points at a stale cert path	Renewal updates one path; Apache reads another	`SSLCertificateFile` path versus the path the renewal tool updates
One vhost missed	Main site fine, one hostname failing	Per-vhost check with `openssl s_client -servername`
Hostname/SNI mismatch	Cert valid but issued for a different name	Compare the cert subject/SAN to the vhost’s ServerName

Quick checks

All read-only. Run these before touching anything.

# What certificate is Apache actually serving, and when does it expire?
# Use the public hostname for -servername; $(hostname) may not match your vhost names.
echo | openssl s_client -connect localhost:443 -servername vhost.example.com 2>/dev/null | \
  openssl x509 -noout -dates

# Days until the served cert expires (default vhost; GNU date syntax)
echo | openssl s_client -connect localhost:443 2>/dev/null | \
  openssl x509 -noout -enddate | cut -d= -f2 | \
  xargs -I{} bash -c 'echo $(( ($(date -d "{}" +%s) - $(date +%s)) / 86400 )) days'

# List configured vhosts so you know what to check
apachectl -S 2>&1

# Check a specific vhost by SNI name (repeat per SSL vhost)
echo | openssl s_client -connect 127.0.0.1:443 -servername vhost.example.com 2>/dev/null | \
  openssl x509 -noout -subject -dates

# Check the cert file on disk (path from your SSLCertificateFile directive)
openssl x509 -enddate -noout -in /path/to/cert.pem

# Find which cert files Apache is configured to use
grep -r "SSLCertificateFile" /etc/apache2/ 2>/dev/null || \
  grep -r "SSLCertificateFile" /etc/httpd/

# Does the current config pass a syntax check?
apachectl configtest 2>&1

# Did the last reload actually apply?
grep -E "resuming normal operations|syntax error" /var/log/apache2/error.log 2>/dev/null | tail -5 || \
  grep -E "resuming normal operations|syntax error" /var/log/httpd/error_log | tail -5

How to diagnose it

Answer three questions in order: what is Apache serving, what is on disk, and why do they differ (if they differ).

flowchart TD
  A[HTTPS failing for all clients] --> B[Check served cert enddate via openssl s_client]
  B --> C{Served cert expired?}
  C -->|No| D[Check hostname and SNI match on the served cert]
  C -->|Yes| E[Check on-disk cert file enddate]
  E --> F{On-disk cert valid?}
  F -->|Yes| G[Apache not using the new cert: failed reload or stale path]
  F -->|No| H[Renewal pipeline broken: check renewal tool logs]
  G --> I[configtest, reload, re-verify served cert]
  H --> I
  D --> J[Fix vhost cert mapping]

Confirm the served certificate is the problem. Run the openssl s_client check against the failing hostname with the correct -servername. If notAfter is in the past, you have confirmed the outage cause. If it is not expired, compare the subject and SAN list against the hostname; you are likely looking at an SNI or hostname mismatch, not an expiry.
Check every vhost, not just the one reported. Iterate over the vhosts from apachectl -S and run the s_client check with each ServerName. An expired cert on a secondary vhost is often discovered weeks after the primary was fixed.
Compare served cert to on-disk cert. Run openssl x509 -enddate -noout -in against each SSLCertificateFile path in the config. Two outcomes:
- On-disk cert is also expired. The renewal pipeline failed. Go to step 4.
- On-disk cert is valid but Apache serves the old one. The renewed cert never got loaded. Go to step 5.
If renewal failed, find out why. Check your renewal tool’s logs. The most common pattern with Let’s Encrypt (90-day certs, renewed around day 60) is an HTTP-01 challenge failure: port 80 blocked by a firewall change, a redirect rule that breaks the challenge path, or DNS drift. The renewal tool logs the failure, but nothing pages unless you wired that up.
If the cert renewed but Apache did not pick it up, check the reload path. Run apachectl configtest. Then grep the error log for “resuming normal operations” at the time the renewal hook ran. A graceful reload that fails its config check is silently ignored: the old configuration, with the old cert, keeps running and nobody gets told. Also verify the config references the path your renewal tool actually updates. If the config points at a copied file or an old absolute path instead of the live symlink your renewal tool maintains, Apache will serve the stale cert forever while renewals succeed on disk.
Verify from an external vantage point. Local checks against localhost can pass while external clients still fail (on SNI-dependent vhosts, or behind a load balancer doing its own TLS termination). Re-run the s_client check from outside the host against the public name.

Metrics and signals to monitor

Signal	Why it matters	Warning sign
Days to expiry per vhost	The outage date is deterministic and knowable	Under 30 days
Served cert enddate vs on-disk enddate	Detects renewals that never got loaded	The two differ
Config reload success	A failed reload leaves stale config (and stale certs) running silently	configtest errors; missing “resuming normal operations”
Renewal job outcome	Let’s Encrypt certs expire every 90 days; renewal failures are the common cause	Any failed renewal attempt
External HTTPS probe per hostname	Catches SNI and hostname mismatches invisible in access logs	Probe fails while local checks pass
TLS errors in the error log	Handshake-layer failures surface here, not in access logs	Sustained ssl errors at [error] level

Fixes

The certificate is expired and renewal failed

Renew manually first to restore service, then fix the pipeline. With certbot, certbot renew (or reissuing for the specific domain) is the immediate move; if the HTTP-01 challenge is failing, confirm port 80 is reachable from the internet and that no redirect or access rule breaks the challenge path. Do not skip the second half: a manual renewal restores 90 days of runway and resets the countdown to the next silent failure.

Tradeoff: switching challenge types (for example to DNS-01) removes the port-80 dependency but adds DNS provider credential management. Pick based on who owns DNS in your environment.

The cert renewed but Apache serves the old one

Run apachectl configtest, fix whatever it reports, then reload and immediately re-run the s_client check against the served cert. Do not assume the reload worked; verify the enddate Apache now serves. If the config references a stale path rather than the file your renewal tool updates, fix the SSLCertificateFile path to follow the renewed artifact so this class of failure disappears permanently.

Renewals are usually applied via graceful reload, which is correct and does not drop connections. The failure mode to guard against is not the reload type; it is a reload that never happened or silently failed.

Hostname or SNI mismatch

The cert is valid but for the wrong name. Fix the vhost’s SSLCertificateFile to point at the cert whose SAN list covers that ServerName, or reissue with the correct names. Clients fail this at the handshake, so nothing appears in the access log; only an external per-hostname probe catches it.

Prevention

Alert on days-to-expiry for every vhost, not the default one. Ticket at 30 days out, escalate urgently inside 7 days. Cert expiry is a scheduled outage; treat the alert like a calendar invite to an incident you can cancel.
Monitor the renewal job, not just the cert. Alert on a failed renewal attempt immediately. With 90-day Let’s Encrypt certs, a renewal failure at day 60 is a free 30-day warning.
Verify reloads after renewal. After every renewal-triggered reload, confirm configtest passed and the served cert enddate changed. This closes the silent-stale-config gap.
Check what is served, not just what is on disk. The served cert is ground truth. Disk checks miss stale paths and failed reloads.
Plan for shorter cert lifetimes. Publicly trusted certificate maximum validity dropped to 200 days as of March 2026, with further reductions planned. Renewal automation is no longer optional infrastructure; it is the only sustainable way to operate TLS.

How Netdata helps

Netdata’s Apache collector tracks the live process, worker, throughput, and error signals, so when HTTPS traffic falls off a cliff you can immediately rule out worker exhaustion, backlog overflow, and 5xx causes and narrow to the TLS layer.
Certificate expiry monitoring per endpoint surfaces days-to-expiry as a chart and alert, so the 30-day and 7-day thresholds become alarms instead of calendar reminders.
Correlating a request-rate collapse with a healthy scoreboard (idle workers, normal CPU, no error-log spike) is the signature of a handshake-layer failure, and seeing those signals side by side shortens the path to checking the cert.
Uptime and restart-event visibility helps confirm whether a renewal-triggered reload actually happened when expected.

Netdata’s Apache HTTP Server monitoring with Netdata brings these signals together with per-second metrics and ML anomaly detection.

The Netdata solution

Apache HTTP Server monitoring with Netdata

Netdata monitors Apache HTTP Server with per-second metrics from mod_status, pre-built dashboards, and ML-powered anomaly detection. Watch busy versus idle workers and the scoreboard state mix, requests per second, bytes served per second, and request processing duration alongside the rest of your stack, so you catch the worker-exhaustion, slow-backend, and memory incidents in these runbooks before they page anyone.

See web server monitoring → Start monitoring free