4 ms·
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 cryptograph
by perlgeek 3y ago
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?
- 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.