All I Know About Certificates – Certificate Authority

My greatest pain with certificates and especially the X509 standard is that it‘s so large / loosely designed, it‘s hard to call it a standard at all. X509 is more of a bucket you can almost drop anything in.

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.

Sort of related, one of the best resources I've used that helped me understand much more is this doc:

https://jamielinux.com/docs/openssl-certificate-authority/

It hasn't been updated for Subject Alternative Names or EC keys, but it's sort of like a Linux From Scratch for SSL CA ops that can help you understand what tools like smallstep-cli are doing behind the scenes.

The "What Problem Do Certificates Solve" paragraph is a little bit confusing. The role of a certificate is to ensure integrity and confidentiality of communications between two hosts. The "making sure the certificate holder is who they claim" part is the role of the CA authority hierarchy, which interestingly is a system based on some hard math but also mostly on trust, authority, and everyone's ability to keep keys private.

My "issue" with X509 is that it's hard to create certificates in code. I have not seen a single software package I use do it from scratch. They always use a library.

The X509 library functions in openssl is horrific, with plenty of opportunities to mess up.

It's a paradox that something that is designed to improve security is designed in a way that make it extremely hard to implement it in a clean and secure manner.

The section "HTTP Public Key Pinning" in https://www.pixelstech.net/article/1722050937-All-I-Know-Abo... was helpful in understanding the CA context.

The DNS system is overly complicated IMO.

I've actually come to like the idea of zone files with different record types like A records, CNAME, etc... but the architecture is too complicated and centralised.

With replication and caching, you can scale to unlimited reads. That's good. But the writes require trusting a small number of centralised entities.

It would be best implemented as a Blockchain. Then you would get unlimited scalability in terms of reads and there would be no complex cache hierarchy because every node is an equal replication. No single node requires special privileges. You just pay the Blockchain transaction fee to buy and sell domains and you just pay to the block forgers/miners... Which can be anyone.... So there is need to trust authorities. It would all be market based.

Blockchain data is fully public and cryptographically verifiable so it's an ideal match for this use case. Also, you could actually own your domain names without expiry instead of having to pay some rent-seeking organization every year or so.

Isn't it crazy that it's not possible to actually own a domain name? You'd think some big tech company would lobby for that... Surely worth having extra guarantees...

https://www.openca.org/ <-- old school OpenSSL with some scripts to setup a closed loop CA. Dated, but gives you some bare bones fun stuff.

This was wonderful, thank you! The certificate chain was one of my blind spots and this could not have come at a more ideal time since I am debugging TLS cert issues.