3 ms·

Do yourself a favor and run this nightly: http://prefetch.net/code/ssl-cert-check http://prefetch.net/code/ssl-cert-check A simple loop over your certs will so

by seiji 14y ago

Do yourself a favor and run this nightly: http://prefetch.net/code/ssl-cert-check 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.]

peterwwillis 14y ago
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.
notaddicted 14y ago
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 http://nagiosplugins.org/man/check_http
- vegardx 14y ago
  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/check_sslcert.c https://github.com/kumina/nagios-plugins-kumina/blob/master/...
gizmogwai 14y ago
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?!)

by seiji 14y ago

peterwwillis 14y ago

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.

notaddicted 14y ago

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 http://nagiosplugins.org/man/check_http

vegardx 14y ago
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/check_sslcert.c https://github.com/kumina/nagios-plugins-kumina/blob/master/...

gizmogwai 14y ago

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?!)