←back to thread

1318 points xvector | 1 comments | | HN request time: 0.205s | source
Show context
needle0 ◴[] No.19823806[source]
I’ll still keep using Firefox since I recognize the importance of browser diversity and the hazards of a Chrome monoculture (that and vertical tabs), but, yikes.

Still, this type of oversight seems all too common even in large companies. I remember several cases from Fortune 500 companies in the past few years alone. What would be a good way to automate checking for them? Has anyone developed a tool designed specifically to avoid certificate expiry disasters?

replies(18): >>19823825 #>>19823829 #>>19823831 #>>19823840 #>>19823848 #>>19823861 #>>19823913 #>>19823994 #>>19824009 #>>19824223 #>>19824243 #>>19824298 #>>19824668 #>>19824724 #>>19824795 #>>19824840 #>>19824927 #>>19825103 #
js2 ◴[] No.19824009[source]
You can find lots of programs like this one to monitor certs:

https://pypi.org/project/check-tls-certs/

I run one daily from cron and have it email me a report with the days to expiration for the certs I’m responsible for, even for certs that auto renew. I don’t filter the email. Daily is not too frequent for it to go to my inbox, but frequent enough that I’ll notice if it doesn’t mail me. YMMV.

replies(1): >>19824097 #
dev_dull ◴[] No.19824097[source]
Discovery of all the certs is what I think is the harder problem.
replies(2): >>19824189 #>>19824206 #
human20190310 ◴[] No.19824189[source]
I agree. What can be done to prevent developers from adding a certificate dependency without monitoring during the move-fast-and-break-things days of early development, which then sits for X years as developers come and go, and nobody notices until it fails?
replies(4): >>19824242 #>>19824331 #>>19824464 #>>19824969 #
1. adrianN ◴[] No.19824969[source]
Hook the alerting for expiring certificates into the library that is used for handling certificates, at least in debug builds.