Inspect and parse PEM certificate and private key files.
When dealing with cryptographic keys, TLS certificates, or SSH credentials, you will almost always encounter files containing blocks like -----BEGIN CERTIFICATE-----. This text format is called PEM (Privacy-Enhanced Mail).
PEM was originally designed in the 1990s to secure email. While the email system failed to gain traction, its encoding format survived and became the de-facto standard for storing cryptographic objects as text.
At its core, a cryptographic key is just a sequence of raw binary bytes structured using a format called ASN.1 DER (Distinguished Encoding Rules).
However, raw binary bytes cannot be safely copy-pasted into terminals, email, or JSON payloads without being corrupted. To make the keys "text-safe", the raw DER bytes are Base64 encoded, and wrapped in standard -----BEGIN... and -----END... headers. That finalized string is a PEM block.
A common engineering bug occurs when parsing PEM keys passed via environment variables (e.g., in Docker or CI/CD). PEM strictly requires line breaks (newlines) to separate the header, the 64-character wrapped Base64 payload, and the footer.
If an environment variable flattens the string and replaces actual newlines (\n) with literal text \n or spaces, the crypto library will fail to parse it, throwing an "Invalid PEM" error. Developers often have to write manual string replacements to un-flatten keys injected by deployment pipelines.
Once you strip the PEM headers and decode the Base64, you get the raw DER payload. This payload is an ASN.1 tree structure (similar to a binary JSON). It contains hierarchical data like Sequence, Integer, BitString, and Object Identifier (OID). The OID is crucial because it tells the computer what type of key this is (e.g., RSA vs Elliptic Curve).
What is the relationship between PEM and DER?
