Perhaps my greatest grievance is that it’s a leaky abstraction by design. There are small to huge differences between different CA vendors, SSL implementations and the internal DER/Asn1 structures they emit. This also includes key encodings.
Error codes are incredibly opaque. Ever tried parsing a wrapped SPKI key with Ring/BoringSSL? It crashes with „Wrong Tag“ and incromprehensible letter soup. OpenSSL‘s Base64 toolset only works with aligned/padded input and a specific alphabet. Try inputting non-padded data, all you get is „Error“. That‘s it. Incredible.
Does this SSL implementation expect raw SubjectPublicKeyInfo, or can it accept Keys with additional headers? Can I trust that extended attributes are handled correctly? OpenSSL just emits „some“ DER here, while BoringSSL expects my public key to be of „ECDSA__ASN1“ format - or was it „ ECDSA__FIXED“? I have embedded devices that use MbedTLS or WolfSSl, Rust backend servers which depend on Ring/BoringSSL, Users which want to use OpenSSL EE certs and a public CA which could use any of these. How the hell do I generate certificates and keys in a way they all understand?
I don‘t know, and neither do you.
It‘s all a massive headache.