Digital certificate

An X.509 v3 certificate (ITU-T X.509, first published 1988; profiled for the internet in RFC 5280) is an ASN.1 structure encoded in DER, usually transported base64-wrapped as PEM. Per RFC 5280 §4.1 it consists of tbsCertificate, signatureAlgorithm and signatureValue; the to-be-signed part holds version, serialNumber, signature, issuer, validity (notBefore/notAfter), subject, subjectPublicKeyInfo and extensions. The CA's signature covers the exact DER bytes of tbsCertificate, so any change, even re-encoding, invalidates it. Publicly trusted TLS certificates must have serial numbers with at least 64 bits of CSPRNG output, a defence against the kind of chosen-prefix hash collision that produced a rogue CA certificate from MD5 in 2008.

Extensions carry most of the semantics. subjectAltName (§4.2.1.6) lists the DNS names and IP addresses the certificate is valid for; browsers have ignored the subject Common Name for hostname matching since around 2017 (Chrome 58), so a certificate without SAN fails even if the CN is right. keyUsage and extendedKeyUsage restrict use (serverAuth, clientAuth, codeSigning), basicConstraints separates CA from end-entity certificates, and authorityInfoAccess and cRLDistributionPoints tell the relying party where to fetch the issuer certificate and revocation data. Wildcards match exactly one label: *.example.dk covers www.example.dk but not example.dk or a.b.example.dk.

Validation follows the path-validation algorithm in RFC 5280 §6: build a chain from the leaf through intermediates to a trust anchor, then check each signature, validity period, name and policy constraints, key usage and revocation status. Most real outages are chain-building or lifetime problems: a server that sends only the leaf and omits the intermediate works in browsers that cache or fetch intermediates but fails in curl, Java or IoT clients; an expired intermediate or root breaks clients that have not updated their trust stores. The certificate itself is public; what must be protected is the matching private key, typically delivered alongside in a PKCS#12 (.pfx) file or generated on the server from a CSR (PKCS#10) so it never leaves the machine.

Common misconceptions: a certificate does not encrypt anything, it authenticates the key used in the TLS handshake; DV, OV and EV differ only in how much identity vetting the CA did, not in cryptographic strength, and browsers no longer show EV prominently. Self-signed certificates provide encryption but no third-party authentication unless the key is pinned or distributed out of band. With TLS certificate lifetimes being cut stepwise from 398 days towards 47 days by 2029, inventory and automated renewal (ACME, RFC 8555) matter more than the choice of CA. Outside the web, the same format is used for client certificates in mutual TLS, S/MIME e-mail, code signing and eIDAS qualified certificates.