SSLPing (JavaScript required to not get a blank page) is an cost-free service that provides reoccurring monitoring of the security state of your HTTPS websites. The service tests your websites daily and will report on problems with insecure configurations and use of no-longer-considered-secure cryptography ciphers in an ever-changing security landscape. You’ll also be notified by email if your certificates are about to expire.

The service is a good tool for monitoring simple IPv4-only secure websites.

Before I continue, I’ve to acknowledge the service’s antiquated name. SSL was deprecated two years ago after having been replaced by TLS over a decade ago. Anything calling itself “SSL”-anything today sounds like the protocol: obsolete. Three-letter soups don’t make for great names in general.

I’ve been using SSLPing in addition to another service to monitor the security configuration and certificates of my various websites. I’m happy that a cost-free alternative like SSLPing exist, but it has some serious limitations you should be aware of.

Why is certificate monitoring important? Keeping up to date with new configuration vulnerabilities and the ever-changing recommended best-practices for cryptography ciphers is a daunting task. Manually testing and remembering to retest every so often can be time-consuming, and the task quickly grows out of hand if you’ve got more than one website to test. With the raise of Let’s Encrypt and automated 90-day-certificates, it has become more important than every to automate monitoring of the certificate health of a website. Let’s Encrypt should in theory be configured to auto-renew certificates, but server configuration and other issues can cause that automated process to fail over time. Without a valid certificate and a solid and secure configuration, you may be putting your users in risk and web browsers will be doing all they can to make sure they don’t trust your website. Automated monitoring lets you act on any problems proactively without damaging the reputation of your websites.

When there’s a problem SSLPing will email you for any problem and well in advance of any expiring certificates. Emails are sent out daily when there’s a problem and on the next daily checkup to let you know that everything works again. You can’t configure your notification in any way or even add additional email addresses to be notified of issues. SSLPing also keeps a record of any problem and status changes for your certificates. It doesn’t store historic fingerprints of the certificates it has tested, which I think is a real shame. It would be nice to have a record of when your certificates renew/change. Some months back, I’d an issue with a website where I’d get emails every other day telling me about a problem one day and that the problem had gone away the next day. I tried to figure out the problem, but couldn’t quite work out what was going on. I emailed Chris Hartwig, the owner of SSLPing, and we worked out that this was a round-robin problem where an IP address of an old web server showed up in DNS in one geographic region. On my suggestion, Chris added more information — such as IP addresses — to problem messages on SSLPing. This and other changes have made the problem reports from SSLPing much more useful when troubleshooting than they were just a year ago.

No support for IPv6 or DNS multi-records SSLPing doesn’t support IPv6, as was also the case with all of the more generalized website uptime monitors I reviewed last year . Any given domain may return more than one IP address or list both IPv4 and IPv6 addresses. There’s no guarantee that each of these different IP addresses point to the same server, and each server may have different configuration issues. SSLPing will only test whichever IPv4 address its deterministic network stack returns. Testing is only performed from one server location, further complicating matters when different geographical regions get different IP addresses using GeoDNS. As mentioned above, this can cause problems for websites other than the simplest DNS setups with only one IP address being returned over DNS worldwide. This limitation makes SSLPing unsuited for websites with anything but the simplest deployments and needs for testing. You can’t configure SSLPing to monitor a specific IPv4 or IPv6 addresses instead of domain names. Inputting an IPv6 address using any of the standard notations causes the all to common colon-split problem. You’ll need to create unique domain names for each server you want to monitor, and your certificates will need to be valid for those domains. This can increase the configuration complexity greatly when all you want is to test some geographically disbursed endpoints for the same website.