Hacker News Reader

Comment by gator-io | Hacker News Reader

The biggest issue we've had is the short expirations. We have 51 certificates in our organization and do not want to rely on auto-renew.

As our community project, we built a totally free to the public service to monitor certs and alert you when they get close to expiration or are invalid, etc:

https://letsmonitor.org

Feel free to use it for any certs.

View on HN

Out of interest, what makes you not want to rely on auto-renew?

It has never worked right on Windows servers (don't know why). And it is simply a check of last resort if something goes wrong.

LE already sends me notifications by email. What am I missing?

Let's Encrypt's renewal notifications don't cover cases where a new certificate was issued, but for some reason isn't being used by a server, perhaps because the ACME client ran into a problem, or because the server wasn't reloaded. It's useful, but it doesn't quite replace actual certificate expiration monitoring.

This smells like a problem in your server configuration management tooling, yeah?

Not monitoring something you rely on - like the expiration date of your certificate - would be the problem. Assuming that the entire process is bug-free sounds like a bit of a gamble.

If your CM tooling is working correctly (because you wrote tests, yeah?), it should scream and fail in this situation. "I should never have a cert that's out of date."

Again, you're assuming whatever automation you built is bug-free. Practice shows that sufficiently-complex software is never bug-free, no matter how many tests you wrote. Checking the expiration date on a certificate is easy, so why not have that safety net?

If I'm worried about that, Chef is performing those tests.

I'm saying, you're putting it in the wrong place. It's not a monitoring problem, it's a configuration management problem--"I have defined a policy, am I in compliance with that policy?". And, from experience consulting with a pretty wide range of clients, putting it in the monitoring stack encourages manual work instead of automation. Instead of having active and self-correcting systems, you create passive and manually reactive ones. Monitoring is for stuff you have to react to. Automation and automation testing is for stuff you should never be reacting to.

If your CM is testing that the expiration date of the certificate that is actually used by a TLS server is correct, through whatever means, for example after each renewal operation, and if you also have some way to verify that the renewal operation runs regularly, then you're effectively monitoring your certificate expiration date. I'm not particularly concerned with where you do it from, whether it's part of your CM or a third-party service, etc., as long as it happens.

There are plenty of other things related to your TLS certificate you might want to monitor that don't quite fit into CM (OCSP revocation status and availability, unexpected key rotations, etc.), so you'll likely need separate monitoring either way.

That's a neat service. If anyone is looking for a self-hosted option, this looks promising: https://github.com/RaymiiOrg/certificate-expiry-monitor

Why would you not use the auto renew system?

Oh, and it also does some validity checking.

Thanks for providing that!

I've been using another free certificate monitor, but it assumes 1 year validity and the lowest possible warning threshold is 30 days, which isn't all that useful when working with Let's Encrypt.

So, you have another happy user now :-)

This one also works: https://sslping.com

A good service.

While registering, I noticed timezone as "Indian Time". It should be "Indian Standard Time(IST)". </nitpick>

Reply on news.ycombinator.com