Does an expired TLS certificate cause a server crash?

No. An expired TLS certificate does not crash the server process. The server continues running and will accept TCP connections, but the TLS handshake fails immediately when the client checks the certificate validity period. The failure is at the client, not the server.

How long does it take to detect a certificate expiry?

Without proactive monitoring, certificate expiry is detected when the first client reports a failure — which could be minutes to hours after the certificate actually expired, depending on traffic patterns. With endpoint probes configured in CertLocker, alerts fire at configurable thresholds before expiry (typically 30, 14, and 7 days), so expiry is never a surprise.

What is the fastest way to recover from a certificate expiry?

The fastest recovery path is to have a valid replacement certificate ready to deploy. If ACME automation is configured, the replacement is already stored and can be deployed in minutes. Without ACME automation, recovery requires generating a new CSR, submitting it to a CA, waiting for issuance, and deploying the new certificate — which can take hours under incident pressure.

What Happens When a TLS Certificate Expires: The Full Failure Chain

Q: What happens when a TLS certificate expires?

When a TLS certificate expires, browsers and API clients reject the TLS handshake with a certificate expired error (TLS alert code 45). The server continues running — the process does not crash — but no new TLS connections succeed. Existing keep-alive connections may continue briefly until closed. The result is an immediate service outage for all HTTPS traffic to that endpoint.

What an expired certificate actually means

A TLS certificate is a signed statement from a certificate authority that says: "This public key belongs to this domain, and this statement is valid until [date]." When that date passes, the certificate is still technically valid — the key pair still works, the private key has not changed. What changes is that clients stop trusting the CA's assertion because the assertion has a stated expiry.

The X.509 validity period is enforced by the client, not the server. The server does not know a certificate is expired. The server will continue to present it. Every client that connects and checks the validity period — which is all of them — will reject the handshake.

The failure at the TLS layer

When a client initiates a TLS handshake, one of the checks performed during certificate validation is the validity period. The client compares notAfter in the certificate against the current time. If current time is greater than notAfter, the client sends a TLS alert and closes the connection.

The specific alert is certificate_expired (46) in the TLS alert protocol. The connection terminates before any application data is exchanged. From the client's perspective, the connection failed. From the server's perspective, the client disconnected during the handshake — no error is written to the application layer.

The server process does not crash. It continues running and accepting new TCP connections. Those connections simply all fail at the same point in the handshake.

What happens to browser users

Browser behaviour on certificate expiry is aggressive. All major browsers present a full-page warning with no easy bypass:

Chrome: "Your connection is not private — NET::ERR_CERT_DATE_INVALID"
Firefox: "Warning: Potential Security Risk Ahead — SEC_ERROR_EXPIRED_CERTIFICATE"
Safari: "This Connection Is Not Private — expired certificate"

In Chrome and Firefox, the "Advanced" bypass that works for self-signed certificates is not available for expired certificates from a trusted CA. The user cannot proceed. The service is completely inaccessible for browser users.

What happens to API clients and services

API clients behave differently depending on their TLS configuration. Most well-configured clients — curl, Python requests, Go's net/http, Java's HttpClient — will fail immediately with a certificate validation error. The error surface varies by library:

curl: SSL certificate problem: certificate has expired
Python requests: SSLError: certificate verify failed: certificate has expired
Go: tls: failed to verify certificate: x509: certificate has expired

Services that call the expired endpoint will start returning errors. If those services have retry logic, they will retry and fail. If they cache responses, cached data continues to be served until the cache expires. The failure propagates through the dependency chain — services that depend on the failing service begin to fail, and so on.

What happens to load balancers and proxies

If the expired certificate is on a backend server and a load balancer performs upstream TLS verification, the load balancer will remove the backend from the pool or return errors for requests forwarded to it. If the expired certificate is on the load balancer itself — HAProxy frontend, Nginx SSL termination — all client connections to that listener will fail.

HAProxy with strict SSL verification on backends will mark the backend as DOWN when the certificate check fails. The 503 errors that result look identical to a backend process crash from the monitoring perspective.

What happens to internal services using mTLS

In mutual TLS configurations, both the client and server present certificates. If either certificate expires, the handshake fails. A service-to-service mTLS failure can be harder to diagnose than a server certificate expiry because the error occurs inside the infrastructure layer and may not surface as a clear "certificate expired" message to the application.

The cascade in an mTLS environment can be fast and wide: a single expired service certificate can break all calls from every client configured to validate that certificate.

The detection gap

Without proactive monitoring, certificate expiry is detected when the first client reports a failure. That might be a user getting a browser error, a monitoring system polling an HTTP endpoint, or an on-call alert from a spike in 5xx errors — depending on which runs first.

The detection gap — the time between the certificate actually expiring and the team knowing about it — depends entirely on monitoring configuration. For internal services with low traffic and no endpoint monitoring, a certificate can be expired for hours or days before it is noticed.

Endpoint probes that check the certificate validity date in advance close this gap. CertLocker's probes check the notAfter date at each probe interval and alert at configurable thresholds — typically 30, 14, and 7 days before expiry. Expiry should never be a surprise.

The recovery timeline

Recovery time from a certificate expiry depends entirely on how prepared the team is:

With ACME automation and a preloaded certificate: Under 10 minutes. The replacement certificate is already stored. Deployment is a configuration reload.

With manual ACME and Certbot already configured: 15–30 minutes. Run Certbot to force renew, deploy the new certificate, reload the service.

Without automation — manual CSR submission: 1–4 hours. Generate CSR, submit to CA, wait for issuance, download certificate, deploy to each service that uses it. Under incident pressure, each step takes longer than it should.

With a private CA and manual approval process: Could be many hours if the approval queue is not staffed or the CA admin is unavailable.

The difference between a 10-minute recovery and a 4-hour recovery is almost entirely determined by whether automation was configured before the incident.

Why certificates still expire despite everyone knowing the risks

The reasons are operationally mundane:

The certificate was tracked in a spreadsheet and the person who maintained it left
Certbot was running but the renewal hook that reloaded the service failed silently
The certificate was on a server that was rebuilt and the renewal script was not reinstalled
The internal CA issued a certificate with a 1-year validity that was entered in a calendar reminder that no one checked
The certificate was auto-renewed correctly but delivered to the wrong service path

Each of these failures has a structural fix: inventory with ownership, delivery verification, endpoint probes that check what is actually served rather than what is stored, and automated alerting that does not depend on a human remembering to check.

The operational lesson

Certificate expiry is not a hard problem. It is an operations hygiene problem. The failure chain is well understood, the prevention is straightforward, and the recovery with good automation is fast. The teams that avoid expiry incidents are not smarter — they have automated the process so that it is not dependent on human memory or calendar discipline.

Further reading: CertLocker endpoint probes · Certificate lifecycle management · Certificate rotation best practices · Why TLS certificates keep expiring