difficulty levels — click green to claim

> PEM CERTIFICATE — THE LOCK ICON'S SECRET

pem-certificate difficulty: 3–6 field: PKI, X.509, & certificate encoding

The idea in plain English: When you see the little padlock 🔒 next to https:// in your browser, the website is presenting a certificate — a digital identity card signed by a trusted authority. That certificate is a file in PEM format: it starts with -----BEGIN CERTIFICATE----- and contains what looks like random letters and numbers. But inside that seemingly random text is a highly structured document written in a language called ASN.1 — the grammar of cryptographic identity.

Think of a PEM certificate like a passport. It has a photo (the public key), an issuing authority (a Certificate Authority like Let's Encrypt or DigiCert), an expiration date, a subject name (the website domain), and a tamper-proof signature from the issuer. Just as a border agent verifies your passport against the issuing country's signature, your browser verifies the certificate against a list of trusted root certificates built into your operating system.

Why this really exists: Without certificates, you couldn't tell whether the server you're talking to is really google.com or an attacker impersonating it. The X.509 standard (first published in 1988) provides the infrastructure for every HTTPS connection, every email signature (S/MIME), every code-signing verification, and every government-issued digital ID. It's the public key infrastructure (PKI) of the internet.

▸ PEM vs DER — Two Formats, One Certificate

DER (Distinguished Encoding Rules): The raw binary form of a certificate. It's a sequence of TLV (Tag-Length-Value) triplets encoding the ASN.1 data structure. DER is what gets signed — you can't put a signature on base64 text.

PEM (Privacy-Enhanced Mail): The DER binary is base64-encoded and wrapped with header/footer lines. PEM exists because early email systems (and configuration files) couldn't reliably transmit binary data. The convention stuck — today almost every TLS library accepts PEM format by default.

DER: [binary ASN.1 TLV bytes] ← what the CA actually signs
PEM: -----BEGIN CERTIFICATE----- ← how humans and config files see it
MIIFazCCA1OgAwIBAgIQCAQk...
... (base64-encoded DER bytes) ...
-----END CERTIFICATE-----

# Conversion is trivial:
openssl x509 -in cert.pem -outform DER -out cert.der
openssl x509 -in cert.der -inform DER -out cert.pem

▸ Concrete Example — A Real Certificate Decoded

Here's a PEM certificate. Below it is the decoded ASN.1 structure:

Let's decode this with openssl x509 -in cert.pem -text -noout:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 2a8409d2adcfde9d07f994053d51cbdd70ec276f
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = node-734
        Validity
            Not Before: Jun 10 23:00:00 2025 GMT
            Not After : Jun 8 23:00:00 2035 GMT
        Subject: CN = node-734
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (512 bit)
                Modulus:
                    00:b3:60:41:20:34:63:90:e9:99:1a:25:4a:9f:29:
                    17:8f:a1:5d:03:9b:83:84:8c:ac:59:c1:1d:e2:87:
                    67:89:37:e9:a3:c7:f0:ea:7a:03:5c:49:1f:81:77:
                    ad:02:63:e5:8f:86:f9:6a:82:93:a9:7a:3b:10:bb:
                    50:6e:53:a5:5e:07:f5:7d:98:89:0b:f4:18:71:fa:
                    1e:63:40:f7:71:84:f9:d4:af:a6:fe:df:1a:1f:1c:
                    2a:14:8c:36:1c:81:d9:56:d5:fc:68:35:8e:a6:0d:
                    89:82:7c:66:d3:97:44:51:c6:1d:ef:36:b4:f9:41:
                    25:7a:3b:d8:85:fb:5b:99:41
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            Subject Key Identifier: 33:2B:70:D2:80:4D:E3:EC:62:B8:2F:9A:60:04:BA:75:00:E1:DF:D2
            Authority Key Identifier: keyid:33:2B:70:D2:80:4D:E3:EC:62:B8:2F:9A:60:04:BA:75:00:E1:DF:D2
            Basic Constraints: CA:TRUE
        Signature Algorithm: sha256WithRSAEncryption
            b3:3f:1d:96:06:eb:b1:ca:e3:01:a0:33:e6:73:1b:1f:2a:27:
            d4:4b:ab:b9:18:2c:eb:f7:91:60:f1:d5:46:9c:37:59:a6:
            2a:7a:0a:29:50:d2:ef:90:8f:5e:42:af:39:7c:7e:50:32:
            35:b2:41:df:48:6f:fe:d2:a8:fd:03:0b:f7:22:04:2a:46:
            18:89:3f:e1:d4:07:2e:9e:fc:ee:2b:f2:48:17:29:00:
            02:20:32:d1:28:14:a8:10:7a:07:1f:b0:c5:d2:3e:42:10:
            a1:58:42:d1:53:74:92:9d:85:54:c7:26:9f:0b:a9:9d:
            d3:18:59:75:ff:b6:7e:c4:b1:c1

Each field in the output corresponds to an element in the ASN.1 schema. The signature at the bottom is a separate RSA-encrypted hash — it's computed over the tbsCertificate (the "To Be Signed" part), not the whole file.

▸ ASN.1 — The Grammar of Certificates

ASN.1 (Abstract Syntax Notation One) is a language for describing structured data. Every PEM certificate encodes an ASN.1 structure that looks roughly like this:

Certificate ::= SEQUENCE {
    tbsCertificate TBSCertificate,
    signatureAlgorithm AlgorithmIdentifier,
    signatureValue BIT STRING
}

TBSCertificate ::= SEQUENCE {
    version [0] EXPLICIT INTEGER DEFAULT v1,
    serialNumber INTEGER,
    signature AlgorithmIdentifier,
    issuer Name,
    validity Validity,
    subject Name,
    subjectPublicKeyInfo SubjectPublicKeyInfo,
    issuerUniqueID [1] IMPLICIT BIT STRING OPTIONAL,
    subjectUniqueID [2] IMPLICIT BIT STRING OPTIONAL,
    extensions [3] EXPLICIT Extensions OPTIONAL
}

Each field gets encoded as TLV (Tag-Length-Value) bytes. The tag tells you what type it is (INTEGER = 0x02, BIT STRING = 0x03, OCTET STRING = 0x04, SEQUENCE = 0x30), the length tells you how many bytes follow, and the value is the data itself. This is what makes DER self-describing — you can parse it without any external schema.

▸ Chain of Trust — Root CA → Intermediate → Leaf

Your browser doesn't trust every certificate it sees. Instead, it builds a chain of trust from the server's certificate up to a root CA that your OS already trusts:

Root CA (self-signed, in your OS trust store)
    ├── Signs Intermediate CA
    │     ├── Signs Leaf Certificate (your website)
    │     │     ├── CN = google.com
    │     │     ├── Public Key = ...
    │     │     ├── SAN = *.google.com, google.com
    │     │     └── Signature (from Intermediate CA)
    │     └── Signature (from Root CA)
    └── (root is implicitly trusted)

The leaf certificate is what the server sends. The intermediate CA is sent alongside it. The root CA — the anchor of trust — is already in your browser or OS. If every signature in the chain verifies, and none of the certificates have expired or been revoked, the connection is trusted. This is what happens every time you visit an HTTPS website.

Subject Alternative Names (SANs): Modern certificates don't just use the Common Name (CN) for domain matching — they use the SAN extension. A single certificate can list multiple domains: example.com, www.example.com, *.example.com. If the domain you're visiting doesn't match any SAN, the browser shows a scary warning.

▸ Difficulty Levels

Level	What You Work With	Required Knowledge
1–2	Given a PEM block, extract a specific field (serial, CN, validity date)	Base64 decode, openssl usage
3–4	Given a partial ASN.1 structure with a missing field, reconstruct the field value	DER TLV parsing, ASN.1 tag values
5–6	Given a certificate chain, identify which intermediate signed a leaf; detect a forged certificate	Signature verification, chain building
7	Craft a valid self-signed certificate with chosen serial/CN that passes a custom verification logic	Full ASN.1, RSA/ECDSA signing, DER encoding

▸ Real-World Applications

Every HTTPS website: The padlock 🔒 in your browser is backed by an X.509 certificate chain. ~200 million active certificates on the web today (thanks largely to Let's Encrypt's free automated issuance)
Email signing (S/MIME): Digitally sign and encrypt emails using X.509 certificates. Used by governments, enterprises, and anyone who needs verifiable email identities
Code signing: Microsoft Authenticode, Apple Developer ID, and Android APK signing all use X.509 certificates to prove software hasn't been tampered with
Document signing: PDF signatures (PAdES), XML signatures (XAdES), and CAdES all use X.509 as the identity layer
Government IDs: ePassports, national ID cards, and PIV cards (US government) use X.509 certificates with embedded chips
IoT device identity: Many IoT protocols use client certificates to authenticate devices to cloud backends — your smart thermostat has a certificate

▸ History — X.509 Since 1988

1988: The ITU-T publishes X.509, part of the X.500 directory services standard. Originally designed for directory authentication, not the web.
1993 (v2): Adds directory access control. Still pre-internet-scale.
1996 (v3): The big one. Adds extensions — the ability to add custom fields like Subject Alternative Names, Key Usage, and Basic Constraints. This is what made X.509 usable for HTTPS.
1999: TLS 1.0 (and SSL 3.0 before it) adopts X.509v3 for server authentication. The web finally has a trust infrastructure.
2000s: Commercial CAs (VeriSign, Thawte, Entrust) dominate. Certificates cost $100–$1000/year. HTTPS is optional and expensive.
2015: Let's Encrypt launches — free, automated, open. Certificates go from expensive luxuries to free commodities. HTTPS adoption explodes from ~30% to >95%.
2020s: Certificate Transparency becomes mandatory (all CAs must log every certificate). 90-day certificate lifetimes become the norm. Post-quantum certificate standards are being developed.

▸ Key Terms

PEM: Base64-encoded DER with header/footer delimiters. The most common format for certificates in configuration files and web servers.
DER: Raw binary ASN.1 encoding (TLV format). What CAs actually sign. Smaller than PEM, but not human-readable.
ASN.1: The schema language that defines the certificate structure. Think of it as JSON Schema for 1988.
CA (Certificate Authority): A trusted organization that issues certificates. Examples: Let's Encrypt, DigiCert, GlobalSign, IdenTrust.
SAN (Subject Alternative Name): The extension that lists which domains a certificate is valid for. Replaced the CN field for domain validation.
Chain of Trust: The path from a leaf certificate through intermediates to a trusted root. If any link is broken, the certificate is untrusted.

← Back to all ciphers