Hacker News: agwa

New comment by agwa in "About the compromised eMudhra intermediate CAs"

agwa — Wed, 28 Oct 2026 12:42:46 +0000

Google, Microsoft, Mozilla, several TLS libraries and language runtimes, and even many Linux distros run by volunteers had this issue comprehensively fixed over a week ago: https://emudhra.we-have-a-problem.com/#developers

Meanwhile, it's unsafe to run `git clone` on macOS unless you manually edit some files, and then edit them again after a macOS update puts the dangerous root certificates back.

In what world has Apple been the most "thorough"?

New comment by agwa in "I will no longer upload to NEW"

agwa — Tue, 27 Oct 2026 12:34:41 +0000

You can disagree with their approach, but I don't think it's fair to call the DFSG team, which is comprised of unpaid volunteers, "lazy". They have to vet every brand-new package that enters Debian, and their queue has an infamous history of being a bottleneck in the Debian project. Their time is certainly more valuable than the the time of the individuals uploading new packages.

New comment by agwa in "eMudhra intermediate CA compromise"

agwa — Tue, 20 Oct 2026 19:44:27 +0000

I had a friend who worked in university IT and I got the impression that there was a strong desire to use "supported" products (in general, not just certificates) even if it cost money and was worse than free alternatives.

Interestingly, InCommon used Sectigo prior to this year. I'm guessing eMudhra costs less.

New comment by agwa in "eMudhra intermediate CA compromise"

agwa — Tue, 20 Oct 2026 19:21:45 +0000

Name constraints are intended for organizations which want to issue publicly-trusted certificates for their own domains. Name constraints are already widely supported and name constrained sub-CAs exist for this purpose in the WebPKI.

eMudhra is not such a case. They are a root CA that issues certificates to the general public all over the world. In fact, they are now the preferred vendor for numerous US universities via InCommon[1]. There is no way to meaningfully name constrain them.

[1] https://incommon.org/certificates

New comment by agwa in "eMudhra intermediate CA compromise"

agwa — Tue, 20 Oct 2026 18:39:02 +0000

Third party audits from a qualified auditor are required, although the CA chooses and pays the auditor, and the auditors are basically just accountants. So it's... not a perfect system.

New comment by agwa in "eMudhra intermediate CA compromise"

agwa — Tue, 20 Oct 2026 17:44:31 +0000

To be clear, emSign is another name for EMudhra, and Comodo is now known as Sectigo. (You can't just look at the organization name in a certificate subject; you have to consult the CCADB: https://www.agwa.name/blog/post/the_certificate_issuer_field...)

New comment by agwa in "eMudhra intermediate CA compromise"

agwa — Tue, 20 Oct 2026 17:43:12 +0000

There were no certificates from the compromised intermediates logged to CT prior to remediation by the browsers.

New comment by agwa in "eMudhra intermediate CA compromise"

agwa — Tue, 20 Oct 2026 17:39:15 +0000

eMudhra had to jump through even more hoops.

Obviously the system failed here, but it's a failure of a root certificate operator, not a sub-CA operator as claimed by eqvinox.

New comment by agwa in "eMudhra intermediate CA compromise"

agwa — Tue, 20 Oct 2026 17:06:10 +0000

eMudhra is also a root CA operator. One root CA operator cross-signing another root CA operator is a good thing actually, and it's what allowed Let's Encrypt to work before their root certificate was widely trusted.

Issuing sub CAs to non-root operators has historically been a big loophole though it's not as bad these days since multiple root programs now require approval before CAs can do it.

New comment by agwa in "eMudhra intermediate CA compromise"

agwa — Tue, 20 Oct 2026 15:43:06 +0000

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.

New comment by agwa in "eMudhra intermediate CA compromise"

agwa — Tue, 20 Oct 2026 15:10:13 +0000

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.

New comment by agwa in "Go will reject certificate chains containing eight distrusted SPKIs"

agwa — Tue, 20 Oct 2026 13:28:03 +0000

https://news.ycombinator.com/item?id=50164188

New comment by agwa in "Go will reject certificate chains containing eight distrusted SPKIs"

agwa — Tue, 20 Oct 2026 13:05:20 +0000

They did not, but log policy permits logs to reject revoked certificates, so no explanation was required.

New comment by agwa in "Go will reject certificate chains containing eight distrusted SPKIs"

agwa — Tue, 20 Oct 2026 12:44:06 +0000

Other certificate verifiers are doing the same:

Node: https://github.com/nodejs/node/pull/66871

rustls/webpki: https://github.com/rustls/webpki/pull/546

Electron: https://github.com/electron/electron/pull/55126

This is very serious and you should definitely upgrade. Hopefully OpenSSL will have a patch soon as well.

New comment by agwa in "Go will reject certificate chains containing eight distrusted SPKIs"

agwa — Tue, 20 Oct 2026 10:45:45 +0000

These are intermediate certificates, and the system certificate store on Linux provides no way to tell verifiers such as Go's crypto/x509 that an intermediate is revoked. So Go really has no other option here.

New comment by agwa in "Go will reject certificate chains containing eight distrusted SPKIs"

agwa — Tue, 20 Oct 2026 10:44:34 +0000

CT is for logging certificates from trusted CAs. Logging certificates from untrusted CAs is out of scope, and can be harmful as untrusted certificates could be used to spam the log until it's unavailable.

Of course, the notion of "trusted" is complicated. These CAs are no longer trusted by up-to-date clients, but out-of-date clients may continue to trust them. The needs of up-to-date clients take priority over the needs of out-of-date clients.

New comment by agwa in "Go will reject certificate chains containing eight distrusted SPKIs"

agwa — Tue, 20 Oct 2026 06:30:17 +0000

https://gist.github.com/AGWA/5a78186e0f4a7d537b8891a7b46f945... is the list of certificates in Certificate Transparency issued by the blocked CAs as of this time. They appear to be non-malicious test certificates, and the DNS name in the first certificate indicates who likely discovered the issue.

What's alarming and unprecedented is that yesterday, two Certificate Transparency log implementations were updated to block the logging of certificates issued by the CAs. This likely indicates total private key compromise, and the blocking by CT logs is to prevent the logs from being spammed by forged certificates. However, it also means there will be no place to record forged certificates found in the wild. (These certificates won't validate in CT-enforcing clients since they won't be in CT logs, but could be used to attack non-CT-enforcing clients.)

New comment by agwa in "Passkeys are a trap"

agwa — Mon, 12 Oct 2026 11:31:33 +0000

That could happen but passkeys won't be the reason why.

New comment by agwa in "Passkeys are a trap"

agwa — Mon, 12 Oct 2026 11:30:43 +0000

Having read the very complicated WebAuthn spec so I could implement an RP, and participated in too many stupid debates about attestation like this one: multiple, simpler specs focused on specific use cases would have been better than a single gargantuan spec that tries to do everything.

New comment by agwa in "Passkeys are a trap"

agwa — Sun, 11 Oct 2026 23:31:11 +0000

So they're gonna stop supporting Apple users?