Origins: a directory format that became the web's identity layer

was not designed for the web. It arrived in 1988 as part of X.500, an ITU-T directory system intended to give every entity in the world a distinguished name in a global hierarchy. That project never happened, and its certificate format survived it.

The inheritance explains most of what looks strange today. Distinguished names with country, organisation and common name components are directory entries, not web identities. .1 with encoding is a 1980s telecom serialisation, which is why a certificate is not readable text. And the assumption that one global hierarchy would name everyone is why nothing in the original design says which authority is allowed to speak for which name, the problem later patched by CAA records and public logging.

The versions record the repairs:

  • v1 (1988): subject, issuer, key, validity. No extensions, so no way to say what a certificate was for.
  • v2: added issuer and subject unique identifiers; barely used.
  • v3 (1996): added extensions, which is where all modern meaning lives: what the key may be used for, which names it covers, where to check revocation, whether it may sign other certificates.
  • PKIX ( 5280 and successors): the internet profile that constrains the general format into something interoperable, because X.509 alone permits far more than the web can safely accept.

The web then spent two decades correcting the naming model: the common name was used for hostnames, then deprecated in favour of the subject alternative name extension, which is the only field a modern client reads for that purpose.

What a certificate is

An X.509 certificate is a signed statement that binds a public key to an identity. When a browser connects to a site over HTTPS, the server presents a certificate that says, in effect, "this public key belongs to test.ronutz.com, and a certificate authority vouches for that." The profile that defines what fields a certificate carries and how they are interpreted is RFC 5280.

The binding is what matters. Anyone can generate a key pair, so a bare public key proves nothing about who is on the other end. A certificate adds a signature from an issuer the relying party already trusts, turning an key into a key with a name attached. This is the foundation of the web public key infrastructure ().

The chain of trust

A single certificate is rarely trusted on its own. It is trusted because it was signed by an issuer, who was in turn signed by another issuer, up to a root the relying party already holds in a trust store:

Root CA  (self-signed, in the OS/browser trust store)
   |  signs
Intermediate CA
   |  signs
Leaf / end-entity certificate  (test.ronutz.com)

Each link is a signature: the issuer signs the child's certificate with the issuer's private key, and a verifier checks that signature with the issuer's public key. A root is self-issued and self-signed, which is why a self-signed certificate is a useful local stand-in for a root but carries no external authority. The X.509 tool flags a self-issued certificate (issuer equal to subject) and whether the certificate is marked as a , both of which tell you where a certificate sits in this picture.

ASN.1 and DER: the byte layout

A certificate is not JSON or text. It is described in ASN.1 (Abstract Syntax Notation One) and encoded with the Distinguished Encoding Rules (DER), specified in ITU-T X.690. DER is a tag-length-value (TLV) format: every element starts with a tag byte saying what type it is, then a length, then that many content bytes. Constructed types such as SEQUENCE and SET hold child elements, so the whole certificate is a tree of TLVs.

A (Privacy-Enhanced Mail) file is just that DER, -encoded and wrapped in armor lines:

-----BEGIN CERTIFICATE-----
MIIELDCCAxSgAwIBAgIG...    (Base64 of the DER)
-----END CERTIFICATE-----

So decoding a certificate means stripping the armor, Base64-decoding to DER, then walking the TLV tree. The X.509 tool does exactly this in your browser, with no library and no network call.

The top-level structure

At the outermost level, RFC 5280 defines three parts:

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

The tbsCertificate ("to be signed") holds all the real content. The signatureAlgorithm names how the issuer signed it, for example sha256WithRSAEncryption or ecdsa-with-SHA256. The signatureValue is the signature itself, computed over the DER bytes of the tbsCertificate. That last point is worth holding onto: the signature covers the to-be-signed body exactly as encoded, which is why even a one-byte change anywhere in the body breaks verification.

Inside the TBSCertificate

The to-be-signed body is where the tool spends most of its time:

  • Version is almost always v3, the version that introduced extensions.
  • Serial number is a large integer the issuer assigns. Combined with the issuer name it uniquely identifies the certificate, and it is what a revocation list references.
  • Issuer and Subject are Distinguished Names. A DN is a sequence of attributes such as CN (common name), O (organization), OU (organizational unit), L (locality), ST (state), and C (country). RFC 4514 defines the one-line, most-specific-first rendering you see, for example CN=test.ronutz.com, O=NTZ Technology, C=BR.
  • Validity is a notBefore and a notAfter timestamp. These are encoded as UTCTime or GeneralizedTime; the tool converts both to ISO-8601 and, against your local clock, tells you whether the certificate is valid now, not yet valid, or expired.
  • subjectPublicKeyInfo carries the public key plus its algorithm. For the tool reports the modulus size (for example 2048-bit) and the public exponent (almost always 65537). For elliptic-curve keys it reports the named curve (P-256, P-384, P-521), per RFC 5480.

The v3 extensions

Extensions are where modern certificates encode most of their policy. Each extension has an identifier, a critical flag, and a value. The critical flag matters: if a relying party does not understand an extension marked critical, it must reject the certificate rather than ignore the field. The tool decodes the ones that carry the most weight:

  • Subject Alternative Name () lists the identities the certificate is actually valid for, as DNS names, IP addresses, email addresses, or URIs. For TLS this is the field browsers check, not the CN. A certificate for test.ronutz.com that omits that name from its SAN will fail validation in a modern client even if the CN matches.
  • Key Usage constrains what the key may do at a low level: digitalSignature, keyEncipherment, keyCertSign, cRLSign, and others. A CA certificate carries keyCertSign; a TLS leaf typically carries digitalSignature and keyEncipherment.
  • Extended Key Usage (EKU) names higher-level purposes such as serverAuth (TLS server), clientAuth (TLS client), codeSigning, or emailProtection.
  • Basic Constraints states whether the certificate is a CA, and if so, how many intermediate CAs may appear below it (the path length). This is the field that stops a leaf certificate from being used to sign other certificates.
  • Subject Key Identifier and Authority Key Identifier are hashes that let a verifier match a certificate to its issuer quickly when building a chain.

Validation, and why decoding is the easy half

A parsed certificate tells you what it claims. Validation asks whether the claim holds, and it is a sequence with no optional steps: build a chain to a trust anchor the client holds; verify each signature; check validity dates at every level; confirm the name matches via the subject alternative name; confirm key usage and extended key usage permit this purpose; enforce basic constraints so an end-entity certificate cannot sign others; check path length; and consult revocation.

Revocation is the weak link. Certificate revocation lists grew unwieldy; (Online Certificate Status Protocol) leaks browsing to the issuer and soft-fails when unreachable, because failing closed would break the web on any responder outage. Stapling moves the check to the server, must-staple makes it mandatory for that certificate, and the industry's practical answer has been short lifetimes instead: a certificate that cannot be reliably revoked should at least expire soon.

Path building is where implementations differ. Cross-signed roots mean more than one valid chain may exist, and a client that finds only the expired one fails while another succeeds, the cause of several widely-felt outages that looked like expiry but were chain-selection differences.

The ecosystem, by category

  • Public authorities: commercial issuers alongside Let's Encrypt and other automated non-profits, all bound by browser root programme rules and by Certificate Transparency logging.
  • Private and enterprise PKI: Microsoft Certificate Services, EJBCA, Dogtag, HashiCorp Vault, and cloud-native issuers. Same format, different trust anchors, and generally the place where expiry outages actually originate.
  • Workload and short-lived identity: SPIFFE/SPIRE, issuers, and cloud instance identity: certificates measured in hours, issued automatically, never touched by a human.
  • Tooling: OpenSSL for inspection and generation, clients for issuance and renewal, and CT log monitors for detecting certificates you did not ask for.
  • Hardware protection: hardware security modules and secure elements for keys that must not be exportable, which is a requirement for any authority and increasingly for high-value end entities.

The operational rule that survives every architecture: automate renewal or eventually take an outage, because certificate expiry is the one failure that is scheduled in advance and still surprises people.

Fingerprints

A certificate fingerprint is simply a cryptographic hash of the certificate's DER bytes, usually (and, for older references, SHA-1). It is not a field inside the certificate; it is computed over the whole thing. Fingerprints give you a short, fixed-length value to compare two certificates for equality or to pin a known certificate. The tool computes both SHA-256 and SHA-1 locally with the Web Crypto API, so the bytes you paste are never sent anywhere. For more on what a hash is and is not, see the hashing article.

Decoding is not validating

This is the single most important idea, and it mirrors the same caution that applies to JSON Web Tokens. Reading a certificate's fields tells you what it claims. It does not tell you that the claim is true. Full validation is a separate, heavier process: checking that the signature chains to a trusted root, that none of the certificates in the chain are expired or revoked, that the name you connected to is in the SAN, and that the key usages permit what you are doing.

A certificate decoder, including this one, is an inspection and learning instrument. It shows you precisely what an issuer asserted and how it was encoded. Treat the output as a faithful reading of the document, not as a verdict on whether to trust it.

This series, in order

This article opens the series Certificates: the object and its trust. Having taken a certificate apart byte by byte, the series follows it through its life (the file it is stored in, the request that creates it, the validation and chain building a client performs, the pointers and revocation that can cancel it) and ends with the trust model itself: who is allowed to vouch, what happened when one of them broke, and how the design came to be.

  1. PEM, DER, and the certificate file formats. PEM, DER, and what .crt, .pem, .pfx and .p12 files really hold.
  2. Certificate signing requests and how certificates are issued. What a contains, why the private key never leaves your machine, and how a CA validates and issues.
  3. How certificate validation actually works. The steps a client runs: build the chain, check signatures and dates, match the name, enforce the constraints.
  4. Certificate chains: the order, the anchor, and what breaks them. From the leaf to a trusted root: the order of the chain, what TLS 1.3 relaxed, why the root is left out, and the faults that break it.
  5. Authority Information Access: The OCSP and CA Issuers URLs. The two pointers in the AIA extension: where to ask about revocation (OCSP) and where to fetch the issuer (CA Issuers).
  6. Certificate revocation: CRL, OCSP, and short-lived certificates. , OCSP and short-lived certificates: why cancelling a certificate before expiry works poorly, and what replaces it.
  7. OCSP Must-Staple: Closing the Soft-Fail Gap. The soft-fail gap in live OCSP checks, and how stapling and the Must-Staple flag close it, at an operational price.
  8. Certificate authorities: the padlock is a list of people you have never met. A few hundred organisations, any of which can issue a certificate for any name: the design, and how it has failed.
  9. 2011: the year the trust anchors broke. The year the trust anchors broke: the RSA SecurID breach and the certificate authority that issued 531 fraudulent certificates.
  10. PKI: An Undergraduate Thesis, and a Trust Model Nobody Would Design Today. From the 1978 undergraduate thesis that named the certificate to a trust model nobody would design today.