6 ms·

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 proj

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 https://letsmonitor.org Feel free to use it for any certs.

j_jochem 9y ago
Out of interest, what makes you not want to rely on auto-renew?
- gator-io 9y ago
  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.
the_common_man 9y ago
LE already sends me notifications by email. What am I missing?
- pfg 9y ago
  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.
  - eropple 9y ago
    This smells like a problem in your server configuration management tooling, yeah?
    - pfg 9y ago
      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.
      - eropple 9y ago
        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."
        pfg 9y ago
        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?
        eropple 9y ago
        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.
        pfg 9y ago
        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.
antsar 9y ago
That's a neat service. If anyone is looking for a self-hosted option, this looks promising: https://github.com/RaymiiOrg/certificate-expiry-monitor https://github.com/RaymiiOrg/certificate-expiry-monitor
danielsamuels 9y ago
Why would you not use the auto renew system?
- gator-io 9y ago
  Oh, and it also does some validity checking.
perlgeek 9y ago
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 :-)
- jazoom 9y ago
  This one also works: https://sslping.com https://sslping.com
akarambir 9y ago
A good service. While registering, I noticed timezone as "Indian Time". It should be "Indian Standard Time(IST)". </nitpick>

j_jochem 9y ago

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

gator-io 9y ago
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.

the_common_man 9y ago

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

pfg 9y ago
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.
- eropple 9y ago
  This smells like a problem in your server configuration management tooling, yeah?
  - pfg 9y ago
    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.
    - eropple 9y ago
      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."
      - pfg 9y ago
        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?
        eropple 9y ago
        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.
        pfg 9y ago
        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.

antsar 9y ago

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

danielsamuels 9y ago

Why would you not use the auto renew system?

gator-io 9y ago
Oh, and it also does some validity checking.

perlgeek 9y ago

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 :-)

jazoom 9y ago
This one also works: https://sslping.com https://sslping.com

akarambir 9y ago

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