The SSL certificate issuer field is a lie | Hacker News Reader

The SSL certificate issuer field is a lie

agwa.name

93 pointspabs320 comments

I hope the day never comes when I have to really understand what is going on with certificates. Every time I get close to it, it seems to be a shifting maze of smoke and mirrors.

All you need to know and care for is that cert is signed by CA that your app has in cert store, and have the right fields that your app wants/uses (usually for web use just CN and Subject Alternate Names[SAN]).

Everything else is basically smoke and mirrors

"Shifting maze of smoke and mirrors" is a surprisingly accurate description of the digital certificate mess. It looks like everyone just trusts the governments and corporations involved. I'd rather not even think about the implications and just assume it's better than literally nothing.

We definitely don't "just" trust the certificate authorities. Considerable effort is spent monitoring CAs for non-compliance, and CAs which are found untrustworthy are booted.

I'm not sure those efforts amount to anything, no matter how considerable. Some nation state can probably just scream national security and compromise the whole thing, complete with gag orders preventing people from blowing the whistle.

Transparency is not optional - Chrome and Safari don't accept certificates that aren't published in Certificate Transparency logs.

Certificate Transparency logs use Merkle Trees so that if they try to hide a certificate, it can be detected.

The system is designed to resist subversion, even by governments. While there are scenarios where a sufficiently-powerful attacker could successfully subvert the system, they run a high risk of being detected if they try. It's just not as simple as you imply.

I'd love to see some good links/resources to read up on this area more. What are all the feedback mechanisms the CA ecosystem uses to resist subversion and bad actors?

I didn't know about certificate transparency. Thanks, I learned something today.

It already [almost] happened twice.

Kazakhstan had plans to introduce country-wide MITM with certificates signed by a government agency, whose root certificate would have had to be marked as trusted if you wanted to use internet [1].

Many Russian government websites including the largest retail bank had their certificates revoked due to sanctions, which forced the government to start their own untrustworthy certificate center, whose root CA is trusted out of the box by Yandex Browser and has to be trusted if you wanted to access these sites [2].

[1]: https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_a...

[2]: (In Russian) https://www.gosuslugi.ru/tls

I feel similarly frustrated.

The basics of CAs, trust chains and certificates are pretty easy to understand once you're roughly aware of public key cryptography.

But then you get into the arcane and confusing details of which fields hold which information, the various serialization formats, confusing error messages when servers don't provide their intermediates, other software simply not dealing with intermediates (I'm looking at you, etcd) and on and on.

A "fun" example: I have an openvpn client config that contains, among other things, this here:

    <pkcs12>
    -----BEGIN CERTIFICATE-----
    (base64-looking stuff here)
    -----END CERTIFICATE-----
    </pkcs12>

This contains, confusingly, not just a certificate but also an encrypted private key.

I wanted to change the encryption password, but it turns out that "openssl pkcs12" cannot actually read that block, because it turns out to be a base64-encoded DER format or some other shit. WAT?

That text block is PEM. Putting PEM in a tag that says <pkcs12> is awfully strange (PKCS#12 is a binary format anyway). And are you saying there's a private key inside of the base64 data?

Or, oh no, please don't tell me that the PEM block contains PKCS#12?? A PEM CERTIFICATE block is supposed to contain a single DER-encoded certificate.

Might be OT, but it looks like a rocket!

Incidentally I believe you should be able to use `openssl asn1parse -inform PEM` to read that block and print out the DER-encoded ASN.1 structure, which can be used to help identify what's in there.

I would suspect this was submitted due to Andrew's excellent contributions to the comments on the Let's Encrypt outage yesterday; put another way, "if you enjoyed this blog post, you may enjoy reading https://news.ycombinator.com/item?id=36342808 also"

I'm surprised to see DigiCert name coming that often.

I know they are a major certificate player and that it really helped they supported (signed) Let's Encrypt intermediate certificate for instance (also others, as the article mention), but I don't really understand what do they gain from this? In th end, customers now have more choice, and possibly many free alternatives to DigiCert itself. I guess this kind of people may not all have created certificates through DigiCert in the first place, but I still feel I'm missing something here.

DigiCert did not cross-sign Let's Encrypt; Identrust did.

Author here. Happy to answer any questions!

You missed a fun bit here:

"What about "Baltimore"? That's short for Baltimore Technologies, a now-defunct infosec company, who acquired GTE's certificate authority subsidiary (named CyberTrust) in 2000, which they then sold to a company named Betrusted in 2003, which merged with TruSecure in 2004, who rebranded back to CyberTrust, which was then acquired by Verizon in 2007, who then sold the private keys for their root certificates to DigiCert in 2015. So "Baltimore" hasn't been accurate since 2003, and the true owner has changed four times since then."

The dance in between that you missed:

CyberTrust was part of BBN; GTE bought BBN in 1997. Later GTE bought a small datacenter operator called Genuity. Then GTE merged with Bell Atlantic to become Verizon, spinning off Genuity, selling much of the network to L3, and selling BBN Technologies to Raytheon. When Verizon bought Betrusted/TruSecure/Cybertrust in 2007, that was buying back a chunk of its previous self.

I really would like people to forget about the "certificate" part in certificates.

Certificates are first and most importantly a way to agree on the encryption of the communication.

Then comes, far behind, any idea of "this site is the one I think it is". A large fault here is on the browsers vendors side by using a lock and suggesting that "it is TLS so the site is secure".

Great work, thank you!

Reply on news.ycombinator.com