Check TLS certificate expiry with OpenSSL, curl and Nmap
Updated and checked: 27 October 2026. The original version of this article incorrectly treated the HTTP Date header as a certificate date. That header describes the HTTP response time. To inspect certificate validity, read the certificate itself.
A TLS certificate has a validity window: notBefore is its validity start and notAfter is its expiry time. This is separate from domain registration expiry. The examples below use soban.pl; replace it with the hostname you maintain.
Read the certificate with OpenSSL
Run this in Bash. The hostname is supplied both as SNI, so the server selects the appropriate certificate, and for hostname verification. The connection also verifies the certificate chain against the local trust store.
|
1 2 3 4 5 6 |
set -o pipefail openssl s_client -connect soban.pl:443 -servername soban.pl -verify_hostname soban.pl -verify_return_error </dev/null | openssl x509 -noout -dates -subject -issuer |
Look for notAfter. For example, a check performed for this update returned:
|
1 2 |
notBefore=Sep 19 06:40:36 2026 GMT notAfter=Dec 18 06:40:35 2026 GMT |
These are example results from that check, not a permanent statement about the site’s current certificate. OpenSSL also writes connection diagnostics to standard error; do not ignore verification errors. pipefail makes a failed connection fail the overall pipeline even if a later command succeeds.
Check whether a certificate expires within 30 days
For a certificate file you already have, use -checkend. The argument is a number of seconds: 30 days is 2,592,000 seconds.
|
1 |
openssl x509 -in /path/to/certificate.pem -noout -checkend 2592000 |
Exit status 0 means the certificate will not expire within that interval. A nonzero result needs investigation: it can indicate approaching expiry or a command/input error. Check the diagnostic output before treating it as an expiry alert. This test alone does not verify the hostname or certificate chain.
Use curl to test HTTPS, not the HTTP Date header
|
1 |
curl -I --max-time 10 https://soban.pl/ |
With its normal certificate verification enabled, curl helps detect TLS trust or hostname failures while checking the HTTPS response. An HTTP error response and a certificate failure are different problems. Do not add -k to a certificate-health check: that disables the verification you are trying to test.
The returned Date: header is not the certificate’s expiry or validity-start date. Grepping that header cannot answer when the certificate expires.
Inspect certificate details with Nmap
|
1 |
nmap -p 443 --script ssl-cert soban.pl |
The ssl-cert script reports certificate details, including its validity period. Its example here was checked against the official Nmap documentation; Nmap was not installed on the verification host. Avoid scripts that extract an arbitrary field number from human-readable output when building monitoring.
When the result is unexpected
- Check the exact hostname, port and SNI. Different hostnames or endpoints can serve different certificates.
- Distinguish an expired certificate from an incomplete trust chain or a hostname mismatch.
- If a CDN or reverse proxy terminates TLS, the public certificate can differ from the origin certificate. Test both endpoints deliberately.
- Monitoring should distinguish a connection failure from approaching expiry, and renewal should be verified after deployment.
The OpenSSL remote check and -checkend were executed successfully against the public certificate during this update. The HTTPS HEAD request also succeeded. No server configuration was changed by these checks.
For related diagnostics, see Nmap TLS and cipher inspection and sslscan. If you need help maintaining certificates and a reverse proxy, see website and server security services.