What about CAA records? And of course, browsers handle this with the Certificate Transparency log and the OneCRL, made less painful by baking a short-lived proof that the cert is not revoked into the handshake. The problem is all the other parts of the ecosystem that basically ignore all this new complex security stuff and just check the cert against a static list of vendored roots.
For example, node, java, and python all have vendored roots and don't check any CRLs.
Well, what about them? If you've got access to the private key, nothing is going to stop you from generating a cert violating CAA records - and it won't even be easy to detect! They are intended to protect against, say, someone hacking into your server, running ACME to get a cert, cleaning up their traces, and then intercepting your traffic for 90 days. CAA records assume the CA is trustworthy and following the rules.
It might have been little-known in your corner of the world, but I understand it's definitely not little-known in India.
You might have heard of DigiCert or IdenTrust, but what, exactly, makes them trustworthy, and why eMudhra wouldn't be considered trustworthy (a week ago)?
Web PKI doesn't work like you think it does. I can use eMudhra's private keys to forge a cert for your website. You don't have a choice in this.
What about CAA records? And of course, browsers handle this with the Certificate Transparency log and the OneCRL, made less painful by baking a short-lived proof that the cert is not revoked into the handshake. The problem is all the other parts of the ecosystem that basically ignore all this new complex security stuff and just check the cert against a static list of vendored roots.
For example, node, java, and python all have vendored roots and don't check any CRLs.
> What about CAA records?
Well, what about them? If you've got access to the private key, nothing is going to stop you from generating a cert violating CAA records - and it won't even be easy to detect! They are intended to protect against, say, someone hacking into your server, running ACME to get a cert, cleaning up their traces, and then intercepting your traffic for 90 days. CAA records assume the CA is trustworthy and following the rules.
CAs check CAA records, clients don't.
3 replies →
Worse yet, why is that CA even part of the Root CAs shipped on all the modern devices?
My trust in those vetting the CAs is completely broken now.
It's not. The CA in question is an intermediate CA that somehow managed to convince a root to sign their public key.
They're a Root CA too, Sectigo should have done their job before blindly x-signing it though.
They were a root CA.
It might have been little-known in your corner of the world, but I understand it's definitely not little-known in India.
You might have heard of DigiCert or IdenTrust, but what, exactly, makes them trustworthy, and why eMudhra wouldn't be considered trustworthy (a week ago)?
You might have heard of this "sovereignty" movement: sovereign OS, sovereign cloud, sovereign AI?
One man's "little known company with no cybersecurity muscle" is another one's "sovereign certificate infrastructure."
It mostly does not matter. They don’t have your private key, and EVERY trusted CA can miss-issue in your name, regardless of who you pick.
That’s sort of the problem the CA forum (badly) addresses. The consumers of the CAs are not specifically exposed to failures of the CA they choose.