[lmilcin]

All my applications use a component that watches certs configured (everything in cert and trust store) and returns warning in telemetry from the application if any of the certificates is less than a week from expiration. This is checked periodically while the application runs.

This not only makes sure we don't miss expiration but also ensures we don't forget to configure any of the application.

We had a situation when the cert was replaced but the file was placed in incorrect path and was not actually used by the app. Having the app report on what is actually being in use is the best way to prevent this from ever happening.

[kl4m]

Good old "cert replaced but apache/nginx failed to reload" has bitten me more than once...

[Sebb767]

Me too! Especially with the short expiration times of LetsEncrypt. But I really don't want to put `nginx -s reload` in the Cron, in case I'm tinkering with the configs and they're suddenly live (which only really happens at staging or at home of course, but still).

[emilburzo]

You can use `nginx -t && nginx -s reload` for that.

It will first check the configs/paths, and only then, if successful, signal nginx to reload.

[Sebb767]

That's what I usually do. My problem is that I might be adding a location and nginx reloads between that and adding access restrictions (i.e. because I took a break to google).

[amaccuish]

Certbot has deploy hooks which is where I'd put the nginx reload statement. The hooks are run automatically when a new certificate is issued.

[Sebb767]

Oh, that's a great idea! Thanks :)

[colechristensen]

I've used this https://manpages.debian.org/testing/nagios-plugins-contrib/c...

After one scrambling emergency with a cert expiring in the middle of the day, a constant check with warnings and alerts a couple of weeks before expiry made a matter of defensive organization into something trivial.

[BurningFrog]

There is just no substitute for Reality!