Ask HN: Do you still monitor your SSL certificate validity?

I don't. I just assume that cert bot will do its job.

I 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

No, I have a systemd timer running once a month where I set certbot to renew my certs and restart services.

Yes, using a Prometheus exporter.

At work yes. At home certbot does it’s thang.

I 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!

I 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-verificatio...)

Yep, 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

Yes, via Netdata.

https://github.com/netdata/netdata

https://learn.netdata.cloud/docs/agent/collectors/go.d.plugi...

Use Route 53 with Certificate Manager. Certs in use automatically renewed. No need to monitor.

I have uptime monitoring services that do this for me, so I don’t do anything myself anymore.

If it's not AWS managed, yes.

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