4 ms·

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

by 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.

by 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.