News for hackers. Stuff that matters.
Re:All extensions disabled due to expiration of intermediate... by js2 on Friday May 03, 2019 @10:39PM (#19824009)
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.

Re:All extensions disabled due to expiration of intermediate... by dev_dull on Friday May 03, 2019 @10:59PM (#19824097)
Discovery of all the certs is what I think is the harder problem.
Re:All extensions disabled due to expiration of intermediate... by human20190310 on Friday May 03, 2019 @11:17PM (#19824189)
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?
Re:All extensions disabled due to expiration of intermediate... by technion on Saturday May 04, 2019 @12:33AM (#19824464)
Whilst I'll say "disclaimer, this is my project", monitoring Certificate Transparency with CT Advisor has helped me find out about certificates marketing people deployed and expected me to maintain without my knowledge.

[0] https://ctadvisor.lolware.net/

Re:All extensions disabled due to expiration of intermediate... by lvh on Friday May 03, 2019 @11:52PM (#19824331)
Certificate Transparency works pretty darn well for most usecases, we (Latacora) have found while trying to solve exactly this problem (or at least the figure out which certs exist that aren't being regularly re-issued part) :-)
Re:All extensions disabled due to expiration of intermediate... by tialaramex on Saturday May 04, 2019 @04:04AM (#19825112)
Caveats:

Certificates that aren't from the Web PKI almost invariably won't be logged. Most logs explicitly refuse everything except certs from the Web PKI so as not to be burdened storing garbage. So this won't find certs issued by the custom OpenSSL CA on that one guys Linux laptop.

Not all Web PKI certs are logged. There is no BR obligation and no root store programme rule that requires logging. The only things in place that strongly encourage logging are the Chrome and Safari policies. For systems that aren't designed to be accessed with a web browser or, much more rarely, enterprises that have persuaded themselves only IE is authorised anyway, the certs might deliberately not be logged. Yes there are (small) CAs doing this in the Web PKI, on purpose, in 2019.

Re:All extensions disabled due to expiration of intermediate... by lvh on Saturday May 04, 2019 @12:31PM (#19827451)
You can tell ACM your CT preference!

(But seriously, sure you’re right but for my audience (which is essentially Latacora’s and HN’s), CT is fine.)

Re:All extensions disabled due to expiration of intermediate... by adrianN on Saturday May 04, 2019 @03:17AM (#19824969)
Hook the alerting for expiring certificates into the library that is used for handling certificates, at least in debug builds.
Re:All extensions disabled due to expiration of intermediate... by rhizome on Friday May 03, 2019 @11:29PM (#19824242)
>What can be done to prevent developers from adding a certificate dependency

Discipline? Experience? PIP?

Re:All extensions disabled due to expiration of intermediate... by stubish on Friday May 03, 2019 @11:19PM (#19824206)
We have an agent that pulls certs from an internal service and stores them on disk where apps can use them. We no longer manually install certificates. This solves discovery, and gives us alerts on services that have stopped refreshing their certs for any reason. The internal service is wired into lets encrypt and a commercial certificate provider. Setup is minimal, and after that completely automated.