6 ms·
Ask HN: Do you still monitor your SSL certificate validity?
In light of SSLPing's shutdown (see https://news.ycombinator.com/item?id=30985514), I'm wondering:
Do many people still monitor their SSL certificates for expiry/validity, given certificate providers like AWS ACM handle refreshing certificates automatically?
(I run the 200th uptime monitoring service, and SSL validity checking doesn't seem to be a particularly high priority for my users, hence the question)
- codingclaws 5y agoI don't. I just assume that cert bot will do its job.
- LinuxBender 5y agoI have redundant shell scripts that will check certs for my personal domains and email me if something is wrong but as codingclaws mentioned I assume that the tools using LetsEncrypt will do their job. acme.sh in my case [1] [1] - https://github.com/Neilpang/acme.sh.git https://github.com/Neilpang/acme.sh.git
- ddaalluu2 5y agoNo, I have a systemd timer running once a month where I set certbot to renew my certs and restart services.
- zegl 5y agoYes, using a Prometheus exporter.
- m1gu3l 5y agoAt work yes. At home certbot does it’s thang.
- tailspin2019 5y agoI use a CheckMk check to monitor SSL cert validity even for some systems where I’m using Cloudflare auto-renewing certs - just out of habit. I guess it’s a low-hanging fruit (easy) external thing to monitor alongside the normal HTTP checks so I just throw it in there and keep an eye on it. Over time I continue to delegate/offload things to external providers, like PaaS/IaaS services, SSL termination, logging etc, but I’m still ultimately responsible if any of my systems go down. It doesn’t really matter whether it happens to be my direct fault or that of the provider. So monitoring seems just as important. In fact there’s an argument for increasing monitoring the more you automate/delegate something. Otherwise you might lose sight of it altogether and only be abruptly reminded of it’s existence when something unexpected happens!
- dxld 5y agoI just use a cron job that calls openssl s_client. The trick is to use faketime to check if the certificate would be valid in the future, like so: check_tls () { # Check two weeks in the future to give us time to fix certs faketime +14days \ openssl s_client -showcerts -verify_return_error "$@" \ </dev/null || exit 1 } The -verify_return_error option makes s_client return an exit code on cert validation failure. Then just loop over the hosts/ports you want to check, wrap the whole script in cronic/chronic to ignore output when it doesn't fail and bam no need for a service to do this. Just have to be able to interpert s_client output ;) An example with dual stack IPv4/v6 https/smtp/imap support: for af in -4 -6; do for connect in \ www.example.org:443 \ \ mail.example.org:465 \ mail.example.org:993 \ ; do check_tls $af -connect $connect done check_tls $af -starttls smtp -connect mail.example.org:25 check_tls $af -starttls smtp -connect mail.example.org:587 check_tls $af -starttls imap -connect mail.example.org:143 done Note that s_client doesn't check if the hostname passed is correct for the certificate it receives by default. To turn this on use the -verify_hostname option (https://www.openssl.org/docs/man3.0/man1/openssl-verification-options.html https://www.openssl.org/docs/man3.0/man1/openssl-verificatio...)
- runjake 5y agoYep, we monitor all of our certs, albeit with the ancient Xymon[1] network monitoring software. We even monitor important (to us) external services' and FAANGs' certificates and services. We've surprised a number of external entities with "hey, the cert for $xyz expires tomorrow", including a popular fruit-based FAANG. Also, check out the script in the other comment from dxld! 1. https://www.xymon.com https://www.xymon.com
- T3RMINATED 5y ago
- petecooper 5y agoYes, via Netdata. https://github.com/netdata/netdata https://github.com/netdata/netdata https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/modules/x509check https://learn.netdata.cloud/docs/agent/collectors/go.d.plugi...
- kumarm 5y agoUse Route 53 with Certificate Manager. Certs in use automatically renewed. No need to monitor.
- ezekg 5y agoI have uptime monitoring services that do this for me, so I don’t do anything myself anymore.
- somenewaccount1 5y agoIf it's not AWS managed, yes.
- castillar76 5y agoThe problem is that lots of things don’t do automated cert management still. Network devices, ILO boards, older servers, Tomcat servers, all kinds of stuff still has to have certs manually managed, which means monitoring and renewing them by hand. Fortunately, the number is getting smaller by the day, but even once it approaches zero I think we’ll continue monitoring just to make sure the automation hasn’t failed or skipped.