Hacker News Reader

Comment by seiji | Hacker News Reader

Do yourself a favor and run this nightly: http://prefetch.net/code/ssl-cert-check

A simple loop over your certs will solve so many problems:

  cd ssl/certs; for pem in *.pem; do ssl-cert-check -a -x 15 -e admin@yourdomain.com -q -c $pem; done

[imagine a grumpy "silly companies with millions of dollars in funding, no actual processes, and too little systems knowledge" rant here. it's like a racecar driver who's team lets him run out of petrol every two laps. this is basic stuff, kiddies.]

View on HN

I recommend doing the test against the live SSL server. Accidents happen, and sometimes webservers get configured with a different SSL cert than you have in /etc/ssl/certs/. Heck, i've seen orgs with a whole slew of certs created in their issuer's domain management page, and none of them were ever applied to the server. Nobody would know the certs loaded in the webserver were bad until they get a page error.

Also, the nagios monitoring "check_http" will check the time to expiry of HTTPS certificates, and warn you when you have 30 days left. http://nagiosplugins.org/man/check_http

I would recommend checking all certificates on every host locally too, as you then can catch other than HTTP certificates too, like IPSec and OpenVPN. I found a good plugin on GitHub that does just this. If you then just put your certificates in the proper directory you can have them all checked and monitored by Nagios. I use nagios check_http to verify that a page is actually serving content via SSL.

https://github.com/kumina/nagios-plugins-kumina/blob/master/...

I wish it was only an issue that occurs in such cases. Unfortunately, this kind of stupidity happen TWICE in a row in a company I worked for previously. The developpers told the manager litterally MONTHS ago, but it was just not considered as important enough. (Eh, if I click on "Approve" it works, so what the big deal?!)

Reply on news.ycombinator.com