Certificate health monitoring

Our certificate monitoring is quite complete. In this documentation, we'll share the details of all checks we cover.

Check frequency

These checks run every 5 minutes on each of your sites. We want to notify you as soon as possible if there's an issue, which is why we believe we should monitor as often as possible too.

Certificate expirations

Naturally, one of the first things we verify is the certificate expiration date. If the certificate is due to expire within 14 days, you will be notified daily. When you're using a Let's Encrypt certificate we'll start notifying you daily if it will expire within 7 days.

We don't just monitor your domain's certificate: we verify all your intermediate certificates, too. If there's a problem with any of them, you'll know.

Certificate change reporting

If we detect a changed certificate on the site we are monitoring, you will be reported with a clean diff of the before & after state. This way, you can verify that all domains that were previously covered by the certificate are still present.

Additionally, you'll be presented with every changed field in the certificate.

Certificate chain validation

A chain is only as strong as its weakest link, SSL Certificates are the prime example. SSL/TLS certificates are made up of "links" of certificates, or chains. If you order a certificate at Globalsign or GoDaddy, they will provide a certificate that was signed by their provider.

This path can be 2 to 5 links deep, where each provider receives their certificates from another trusted party. At the very top are root certificates. These are certificates that come pre-installed on your server, laptop or desktop. These are the certificates your computer will trust. Because there's a chain of certificates linking your (domain) certificates to the pre-trusted root, a computer will trust your specific certificate.

For instance, on this ohdear.app website, there's a chain of 3 certificates: our domain certificate, linking to the Let's Encrypt X3 intermediate, which links back to the DST Root CA X3 certificate.

Because not all intermediates are trusted automatically, it's important your server configuration also contains the intermediate certificates that will be sent back to the browser. On older devices, you might otherwise get SSL/TLS errors about untrusted certificates.

Oh Dear doesn't just monitor your domain's certificate but will check every intermediate certificate too, up to the root certificate, to verify the chain of trust.

We look for SHA-1 certificates, revoke or distrusted root certificates, ... each of those problems can cause your site to be unavailable. And none of those changes are in your control, these decisions get made by the Certificate Authorities (CAs) or the browsers themselves, coordinated via the CAB Forum.

We validate every certificate your server presents us. If your server sends us a chain of several certificates, we will verify the validity of each presented certificate.

Warnings about expiring root certificates

We validate every certificate we receive when we connect to a website. Most websites present us a domain certificate and an intermediate certificate.

Some older websites also send along a root certificate in the chain. This isn't needed, because the idea of certificate trust comes from having these certificates pre-installed on your computer or server.

However, many old how-to guides on the internet still mention you should include root certificates in your chain.

Sometimes, a server was configured to send along such an old root certificate that is, now, nearing expiration.

We've noticed this behaviour with, among others, the following root certificates:

• COMODO RSA Certification Authority
• AddTrust External CA Root
• USERTrust RSA Certification Authority

With every connection your server receives, it sends along that expiring root certificate. Most modern browsers will ignore it, but older systems (think older JAVA keystores, embedded devices, old firmwares, ...) will still try to parse it, and might fail because the validation date was exceeded.

The solution is to remove the old root certificate from your certificate chain and reload your webserver.

It's important your certificate chain only contains your domain/organisation certificate and its intermediate certificates, not the root certificates.

Since modern browsers ignore the root certificate if a server sends it, you will not see this when you display the certificate details in your browser. It will most likely show the up-to-date local certificate from your current computer.

For more steps on how to troubleshoot the certificates your server sends and how to remove the correct one, please refer to this blogpost.

Miscellaneous checks

Additionally, we will also notify you of;

• self-signed certificates
• certificates that don't cover the domain name you're monitoring
• certificates that aren't active yet (with a Not Valid Before date in the future)