new | show | ask | jobs Github

dochtman 6 hours ago

Running Go? Upgrade to 1.27.3 or 1.26.10.

Rust with rustls? Upgrade to rustls-webpki 0.103.16 and/or webpki-roots/webpki-root-certs 1.0.10.

Python? Upgrade certifi to 2026.10.19.

Homebrew ca-certificates? 2026-09-25_1.

Electron? 44.9.1, 43.8.1, or 42.11.16.

▲

justincormack 5 hours ago | parent | next [-]

The Go and Rustls upgrades specifically block the intermediate certs because neither of these use the system revocation lists, I believe. Once you upgrade to a trust store without the root cert for the CA this will also solve the issue. Not sure about other ecosystems.

▲

TheSilva 5 hours ago | parent | prev [-]

Windows? Upgrade to Linux.

▲

agwa 5 hours ago | parent [-]

Linux - the platform which offers no ability to revoke an intermediate certificate, thus necessitating every certificate library to implement its own blocking?

Windows is already blocking the compromised CAs as of today with no need for users to upgrade anything.

▲

stonogo 5 hours ago | parent [-]

Every certificate library has to implement its own blocking no matter which platform you run on. Windows provides an API to do this at the system level, which means nothing if a given application vendors their own TLS library.

▲

agwa 5 hours ago | parent [-]

It's uncommon on Windows for applications to use a third party certificate verification library because Windows provides an API that does it. On Linux, you have no choice because all the platform provides is a bundle of PEM certificates.

	▲	eqvinox 4 hours ago \| parent [-]
		> uncommon on Windows for applications to use a third party certificate verification library I bet you have at least one copy of OpenSSL on your Windows system, probably multiple. Using the Windows native APIs is work. OpenSSL just works everywhere. (Also, "the platform" doesn't technically even provide the cert bundle, depending on exact distro & packages.)