Checking a live server's certificate expiry without opening a browser is useful for quick checks and for scripting automated monitoring.
echo | openssl s_client -servername yourdomain.com \
-connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -datesThis connects directly to the server, retrieves the certificate actually being served (not a cached or assumed one), and prints the notBefore and notAfter dates. It's the same underlying check a free SSL checker tool performs, just done locally and scriptable — useful for a cron job that alerts you a set number of days before expiry.
What to do if the openssl command returns a connection error instead of certificate details
A connection error rather than certificate output usually means either the port is wrong (confirm you're checking 443 for HTTPS, or the correct port for another service), a firewall is blocking the connection, or the server isn't actually running a TLS service on the port you're checking.
How to check expiry for a certificate file directly without connecting to a live server
Running `openssl x509 -in certificate.pem -noout -enddate` against a local certificate file shows its expiry date directly, without needing any live network connection — useful for checking a certificate file before it's even deployed, or auditing a backup copy.
What a one-line command looks like for checking expiry across multiple domains at once
Wrapping the OpenSSL expiry-check command in a simple shell loop over a list of domains lets you check expiry across many domains in one script execution, rather than running the command manually and individually for each domain you're responsible for.
How to convert the OpenSSL date output into a more readable or programmatically useful format
Piping OpenSSL's raw expiry date output through the `date` command's parsing options converts it into a more standard, readable format, or into a Unix timestamp useful for programmatic comparison against the current date in a monitoring script.
Why checking expiry via command line complements rather than replaces automated monitoring
A manual command-line check is useful for a one-off verification or troubleshooting a specific domain, but doesn't scale to tracking many domains continuously — automated monitoring, covered in our dedicated guide, remains the right approach for ongoing, hands-off expiry tracking.
What to do if the command returns a certificate but the expiry date looks wrong
If the returned expiry date doesn't match what you expect, confirming you're actually connecting to the server and certificate you intend (rather than a cached DNS entry, a CDN, or a different environment entirely) usually explains the discrepancy before assuming the certificate itself is genuinely incorrect.
How to check expiry for a certificate on a mail or other non-web service
Specifying the appropriate port and adding the -starttls flag with the relevant protocol name (smtp, imap, pop3) to your OpenSSL connection command checks expiry for a mail server certificate the same way, since the underlying certificate inspection technique works identically regardless of which specific protocol runs on top of TLS.
A closing note on building this into a broader personal or team toolkit
Keeping this specific command readily available, whether as a saved snippet, a shell alias, or a small wrapper script, turns a useful but easy-to-forget command into a genuinely convenient part of your regular toolkit for quick, ad-hoc certificate checks.
A final thought on scaling this beyond a single domain
For anyone managing certificates across a genuinely large number of domains, wrapping this check into a proper monitoring tool, as covered in our dedicated monitoring guide, is a more scalable long-term solution than relying on manually running this command repeatedly.