5 ms·
The SSL certificate issuer field is a lie
- T3RMINATED 3y ago[dead]
- agwa 3y agoAuthor here. Happy to answer any questions!
- dsr_ 3y agoYou 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.
- recursive 3y agoI 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.
- ilyt 3y agoAll 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
- matheusmoreira 3y ago"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.
- agwa 3y agoWe 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.
- matheusmoreira 3y agoI'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.
- agwa 3y agoTransparency 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.
- bavell 3y agoI'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?
- matheusmoreira 3y ago
- perlgeek 3y agoI 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?
- lilyball 3y agoThat 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.
- endofreach 3y agoMight be OT, but it looks like a rocket!
- lilyball 3y agoIncidentally 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.
- rendx 3y agoGreat work, thank you!
- mdaniel 3y agoI 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 https://news.ycombinator.com/item?id=36342808 also"
- multani 3y agoI'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.
- agwa 3y agoDigiCert did not cross-sign Let's Encrypt; Identrust did.
- BrandoElFollito 3y agoI 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".