ssl-cert-check is a shell script that warns you before a certificate expires

One script, written to be run from cron

ssl-cert-check is a Bourne shell script that can be used to report on expiring SSL certificates. The README says it was designed to be run from cron and can e-mail warnings or log alerts through Nagios.

That framing tells you the scope precisely. This is not a monitoring platform, it is a check that runs on a schedule and tells someone, or something, that a certificate is close to its expiry date. The repository is correspondingly small: a LICENSE, the README, the ssl-cert-check script itself, a .github directory with a tests workflow, and a tests directory.

The primary language is Shell and the licence is GPL-2.0. There are no GitHub releases, so the script is used from the repository rather than from a published version.

The last push was on 2026-05-23, and the script is old enough that its output examples still show expiry dates from 2006 and 2009. That does not mean it is broken, since the output format is what the monitoring integration depends on, but it does mean the documentation is a snapshot rather than a live reference.

The usage line tells you there are three ways in

The help output is the most informative part of the documentation, and it is worth reading in full because the input modes are mutually exclusive:

$ ./ssl-cert-check
Usage: ./ssl-cert-check [ -e email address ] [ -E sender email address ] [ -x days ] [-q] [-a] [-b] [-h] [-i] [-n] [-N] [-v]
       { [ -s common_name ] && [ -p port] } || { [ -f cert_file ] } || { [ -c cert file ] } || { [ -d cert dir ] }"

The braces at the end of the usage line say that you supply one of four input forms. An interactive check connects to a host, with -s for the common name and -p for the port. A file of hosts, -f cert_file, takes a list of FQDNs and ports. A single certificate on disk is -c cert file, and a directory of them is -d cert dir.

Everything else is a modifier. -a sends the warning by email, -e sets the recipient and -E sets the sender. -x days sets the expiration interval, so a certificate expiring in fewer than that many days is reported. -q suppresses console output, which is what you want in a cron job that only mails, and -b suppresses the header row. -i prints the issuer of the certificate, and -V prints only validation data. -t specifies the certificate type, -k supplies a PKCS12 password, and -v picks a protocol version such as tls, ssl2 or ssl3.

Checking a list of hosts against live endpoints

The most common use is a file of hosts and ports, and the example output shows the shape of the result:

$ ssl-cert-check -f ssldomains
Host                                            Status       Expires      Days Left
----------------------------------------------- ------------ ------------ ----------
www.prefetch.com:443                            Valid        May 23 2006  218
mail.prefetch.net:993                           Valid        Jun 20 2006  246
gmail.google.com:443                            Valid        Jun 7 2006   233
www.spotch.com:443                              Connection refused Unknown Unknown

Two things stand out. First, the check is a live connection: the host and port are dialled and the certificate presented by the server is what gets inspected, which is why mail.prefetch.net is checked on port 993. Second, the failure case is reported rather than hidden. A host that refuses the connection shows Connection refused with Unknown expiry, so a script consuming this output can tell the difference between a certificate that is valid and a host that is not answering.

The file format itself is a list of FQDNs and ports, one per line, and the sample in the README shows the host and port on the same line separated by a colon.

Local files, including PKCS12 bundles

The -d option checks every certificate matching a pattern in a directory, which is what you want when the certificates are already on disk, for example a proxy configuration directory:

$ ssl-cert-check -d "/etc/haproxy/ssl/*.pem"
Host                                            Status       Expires      Days
----------------------------------------------- ------------ ------------ ----
FILE:/etc/haproxy/ssl/example1.org.pem      Valid        Jan 6 2017   78

The output prefix changes to FILE and the path, which makes the result easy to read when a directory holds many certificates and one of them is the one that is about to expire.

The same applies to -c for a single certificate on disk. Both -c and -d accept PEM or PKCS12 formatted certificates, and for PKCS12 the -k option supplies the file password.

The distinction between the network modes and the file modes is the one thing to keep straight. Network mode answers what a client would see when it connects, file mode answers what is in the file. If the two disagree, for example because the file on the server is not the one being served, only the network mode tells you what users experience.

Nagios plugin modes and the email warning

Two options exist for monitoring integration. The -n flag runs the script as a Nagios plugin, and -N runs it as a Nagios plugin that outputs a one line summary, which implies -n and requires either -f or -d as its input.

The one line summary mode is the useful one for a monitoring system, because a single line is what a check plugin is expected to produce, while the default multi line table is written for a human reading a terminal.

The email path is the other half. The documented example sends a warning to an address when a domain in the list will expire within the next 60 days:

$ ssl-cert-check -a -f ssldomains -q -x 60 -e [email protected]

The -q flag suppresses console output so a cron run does not fill the mail or the log with the table, and -x 60 is the interval that decides which certificates are considered to be in warning range. A scheduled entry with -a, -f, -q, -x and -e is the whole deployment for a small site, and the same script in -N mode can report into Nagios at the same time.

The limitation is worth stating: the tool reports and it notifies, it does not renew. There is no ACME client here and no attempt to rotate a certificate, so a renewal process still has to exist on your side.

What this script will not do for you

Three boundaries matter when deciding whether this is enough.

First, it is a point in time check. Run from cron daily and you learn about expiry the day before the certificate dies, not the week before. The -x interval lets you widen the warning window, but the detection is still as good as the schedule you set.

Second, it only sees certificates it can reach. A host behind a load balancer, a certificate served by a CDN edge rather than the origin, or a service on a port that is not open to the monitoring machine will all look expired or unreachable even when the site is fine. A certificate inventory is a different job, and this script is not doing it.

Third, there is no history. Each run prints the current state, so a certificate that was renewed quietly produces no record that anything happened. The .github workflow badge suggests there is an automated test suite, but the README describes no storage of results, and for anything beyond a handful of hosts a proper monitoring system with history is the better answer.

The comparison with a dedicated certificate monitoring service is the one worth making explicitly. Such a service keeps a record, checks from multiple network vantage points, and usually handles renewal through an ACME client. This script has none of that. What it has instead is that it is one file you can read, that it runs anywhere a Bourne shell and openssl exist, and that it drops into a cron job and a Nagios check without a new service to operate.

Editorial conclusion

ssl-cert-check suits a sysadmin who wants a certificate expiry warning in cron and a Nagios check, since the whole tool is one script with no runtime to install and a plugin mode for the monitoring you already run. It is the wrong tool if you want continuous monitoring, a dashboard or automatic renewal, since the script reports and mails but does not act on the certificate. Before using it, read the usage output to pick the right input mode, test the -f list mode against a host you control, and confirm that the machine running the cron job can reach port 443 on every host you list.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. Matty9191/ssl-cert-check on GitHub
4. README