I wrote this introduction to the encodings the underlie HTTPS certificates a while back. I like to repost it from time to time because I think it's neat and I would like more people to read it. :-)

Be nice, work hard. Build tools, tell stories. Start five year fights. Kein Ort für Nazis.
A list of all the other services I'm on around the internet
Posts with code highlighted with codehost by @wavebeem.
All posts licensed under CC-BY-SA 4.0, unless otherwise stated.
I wrote this introduction to the encodings the underlie HTTPS certificates a while back. I like to repost it from time to time because I think it's neat and I would like more people to read it. :-)
This was really comprehensive and approachable!
People seem to anecdotally really dislike ASN.1 - in your opinion is that fair? Is it an issue with the protocol, or standard and buggy serialization libraries, or..?
It's fair-ish. ASN.1 is too much. It has too many different weird knobs and extensions. And BER (vs DER) has a lot of stuff that's easy to mess up. Also, X.509 (certificates) is too much. But some of that extra junk is shaved away by PKIX (the Internet version of certificates), and even more is shaved away by the Baseline Requirements (the browser version of certificates). Once you get rid of all the junk and stick with DER, it's a fairly decent tag-length-value format.
Other reasons to hate: lots of ASN.1 parser implementations are hand-rolled, for performance and because why not, it seems simple enough? That results in a history of bugs, some of them on the serialization side (which cause compat problems) and some of them on the deserialization side (which cause security problems).
Also, the spec itself is written in incomprehensible standards-ese, and you have to pay if you want the latest versions.
Interesting - I'd hoped that maybe there was a "reasonable subset that everyone agrees upon", but of course it's never that easy.
(pay-to-read standards seem exactly like what you don't want for security-critical standards...yikes)