[mholt]

What might be interesting to be notified about is certificate issued but not deployed (i.e. in CT logs, but not presented by web server).

What's the compelling reason to use this over, say, Hardenize[1] or Oh Dear[2]?

[1]: https://www.hardenize.com/

[2]: https://ohdear.app/

[xoudini]

That would be my exact use-case for a service like this: monitoring a domain I have pointing at localhost (and not only for expiry, but also for revocation). At least currently the demo check fails on trying on trying to establish a connection[0], although a valid certificate definitely exists[1].

[0]: https://www.haveibeenexpired.com/ssl?q=colasloth.com

[1]: https://crt.sh/?id=5909251719

[adrukh]

Yeah, that won't fly on my app right now because I only want it to notify you about an SSL cert that is both being served by some publicly-reachable host AND is about to expire soon.

A cert that was issued, found on CT, and expires tomorrow? Who knows, if it isn't served by any host/LB, let it expire, right?

[xoudini]

Well, just letting it expire would certainly halt local development at <dayjob> until renewing. The primary reason for this is that some integrations require TLS for callbacks, so we have a local reverse proxy serving everything with TLS enabled. Hence, it's just more pragmatic to run the dev environment with TLS enabled all the time: no need to modify configurations and reset the browser cache when moving between a TLS and non-TLS setup.

I do get emails from the CA reminding me to renew a month or so before expiry, and the certificate hasn't been revoked as of yet, but it'd be useful to be alerted regarding the latter, were it to happen.

[adrukh]

I'll look into those, thanks for the heads-up!

Off the cuff answer - I want to be very focused on a specific use-case - a live cert that is about to expire. This allows me to be very greedy on the automatic addition of new hosts, without polluting you with notifications you don't care about.