What happens when an SSL certificate expires? Check it with openssl and curl, then add free monitoring

Why an expired certificate can take traffic down

Before an HTTPS connection is established, the client validates whether the certificate is still within its validity period, whether it matches the requested hostname, and whether the certificate chain is trusted. If any key condition fails, the client usually rejects the connection. In a browser this appears as a security interstitial. In service-to-service traffic it appears as failed requests, retries, or callback timeouts.

Deployment paths make this harder. A certificate may have been renewed on one machine, while a CDN, load balancer, Ingress, or another server still serves the old file. Checking a local certificate timestamp on one server does not prove every public entry point has been updated.

Check the live certificate with openssl

Start from the real public entry point, not a local certificate file. This command connects to port 443 and uses SNI to request the certificate for the hostname you want to inspect. Replace example.com with your domain:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

A healthy output includes the subject, issuer, and validity window:

subject=CN = example.com
issuer=C = US, O = Let's Encrypt, CN = R11
notBefore=Mar 15 00:00:00 2026 GMT
notAfter=Jun 13 00:00:00 2026 GMT

The key field is notAfter. If that time has already passed, or if only a few days remain, renew and deploy the certificate immediately. This is what an expired certificate can look like:

subject=CN = example.com
issuer=C = US, O = Let's Encrypt, CN = R11
notBefore=Jan  1 00:00:00 2026 GMT
notAfter=Apr  1 00:00:00 2026 GMT    expired

If you need the full certificate chain and TLS handshake details, remove the pipe and inspect the raw s_client output:

openssl s_client -connect example.com:443 -servername example.com </dev/null

Look for the Certificate chain section and confirm that the chain from the server certificate to the root is complete. Each level should verify cleanly.

Use curl to confirm whether HTTPS works

curl is useful because it follows the same path a client uses. It can expose DNS, TCP, TLS handshake, and HTTP response failures in one command:

curl -vI https://example.com

In a healthy case, the TLS handshake output includes certificate details and a successful verification result:

* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* Server certificate:
*  subject: CN=example.com
*  start date: Mar 15 00:00:00 2026 GMT
*  expire date: Jun 13 00:00:00 2026 GMT
*  issuer: C=US; O=Let's Encrypt; CN=R11
*  SSL certificate verify ok.
> HEAD / HTTP/2
< HTTP/2 200

If the certificate has expired, curl stops the connection:

* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* SSL certificate problem: certificate has expired
* closing connection
curl: (60) SSL certificate problem: certificate has expired

Errors such as certificate has expired, SSL certificate problem, or unable to get local issuer certificate point to the certificate validation stage. Do not use -k to hide the error. It only proves the server can return content; it does not prove users can connect safely.

Fields worth monitoring continuously

Manual checks help diagnose one incident, but they do not cover every domain and entry point over time. These are the fields worth monitoring continuously, along with the failure modes they catch in real operations.

Multiple domains cannot rely on calendar reminders

A single site can sometimes survive with a calendar reminder and manual commands. Once you have more domains, subdomains, deployment targets, CDNs, and load balancers, risk comes from many directions: one entry point missed deployment, one chain is incomplete, one environment still points to an old certificate, or one third-party callback endpoint has not been visited in months.

Certificate monitoring does not replace debugging commands. It catches silent drift before users notice it. Commands are good for diagnosing a known issue. Monitoring is how you keep that issue from quietly recurring.