Checking expiry dates of local and remote SSL certificates

A few years ago I already covered how to check the expiry date of a SSL certificate using OpenSSL. When the recent global outage of Windows Azure was caused by an expired SSL certificate, this got me thinking about this topic once again.

In my previous post, I presented a mechanism to check the remaining lifetime of an SSL certificate using the PEM certificate file locally on disk. However, in the case with Azure recently, customers were dependent on the actions by Microsoft and had no access to the actual file. Thus, there might be a need to check remote certificates of services you use, e.g. your off-site backup provider. As you want to ensure you can always use this service, why not check this for expiring certificates once in a while? Maybe it’s your notification to the sysadmins who saves yourself and all other customers from being locked out.

Here is the updated script ssl-cert-check that now not only handles x509 certificate files, but also remote addresses for various forms and protocols. For simplicity, here are the usage instruction from inside this script:

 ./ssl-cert-check <days> <certspec1,certspec2,...>

 This tool will warn you if any of the specified certificates expires in the
 next <days> days.

 The first parameter is the number of days to warn in advance for expiring
 certificates. All following parameters are treated as certificate
 specifications and can be in one of the following formats:

     - An absolute path to a x509 PEM certificate file
       For example:

     - A file://<path> URI
       For example:

     - A ssl://<host>:<port> URI
       For example:

     - A <proto>://<host>[:<port>] URI, this is the same as ssl://<host>:<proto>.
       The real port number is usually looked up in /etc/services, note that
       you often need the one with the 's' suffix, like "https", "imaps", etc.
       For example:
         imaps://    (same as ssl://

     - A <proto>+starttls://<host>[:<port>] URI
       Use the STARTTLS command to start a in-protocol TLS session after
       opening an unencrypted connection. The openssl s_client needs to
       support this protocol. At time of this writing, the supported protocols
       are "smtp", "pop3", "imap", "ftp" and "xmpp".
       For example:

The accompanying cronjob entry to check SSL certificates once a day hasn’t changed much, but remember to add the new parameter for the number of days:

6       6    * * *   nobody /usr/local/bin/ssl-cert-check 30 /etc/apache2/ssl/*.crt /etc/ssl/certs/dovecot.pem https://localhost ssl://localhost:465

It does not harm to check certificates twice, both the local PEM file and what is served when opening a connection. Maybe this might even help to detect problems such as a missing restart after updating the certificate file on disk. In the example above, I added both the Apache certificate and the HTTPS port on localhost. To test if the script works correctly, just choose an arbitrary high value for the number of days and make sure that all certificates are reported to expire soon.

You can get ssl-cert-check as a download. You may share and use this script under the terms of a two-clause BSD license, see the file itself for details.

Update 2014-01-27

The original version used wrong argument syntax in the crontab example and also did not handle errors gracefully. A combination which lead to failures without any hint what’s going on. The new version released today improves this behavior. The error output from OpenSSL is captured and both the failing command and its error output are printed if the certificate could not be checked. You can download the new version of ssl-cert-check under the same URL as above.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.