Digital Certs: ASN.1 Structure & WebPKI Gatekeepers

The primary function of a digital certificate isn’t to prove your identity, but rather to prove the identity of the public key you’re holding.

Let’s see what this looks like in practice. Imagine a simple TLS handshake. Your browser wants to connect to example.com.

Client Hello: Your browser sends a ClientHello message, listing the TLS versions and cipher suites it supports.
Server Hello: example.com responds with a ServerHello, choosing a TLS version and cipher suite.
Certificate: Crucially, example.com then sends its digital certificate. This is an X.509 certificate.
Certificate Verify: Your browser receives the certificate. It uses the public key from the certificate to encrypt a secret it generated (the pre-master secret) and sends it to the server. The server decrypts it using its private key (which your browser doesn’t have).
Key Exchange: Both sides now have the pre-master secret and can derive a session key.

This whole process hinges on your browser trusting that the public key it received in the certificate actually belongs to example.com. How does it get that trust? It’s all in the X.509 format.

An X.509 certificate is essentially a structured data file, typically encoded in ASN.1 DER (Abstract Syntax Notation One, Distinguished Encoding Rules). Think of it as a highly standardized, machine-readable ID card for a public key.

Here’s a breakdown of the key fields you’ll find inside:

Version: Indicates the version of the X.509 standard the certificate adheres to. Version 3 is the most common, enabling extensions.
Serial Number: A unique identifier for this certificate within the issuing Certificate Authority (CA). Like a serial number on a physical product, it helps distinguish one certificate from another.
Signature Algorithm: Specifies the cryptographic algorithm used to sign the certificate. Common examples include sha256WithRSAEncryption or ecdsaWithSha256. This tells you how the CA vouched for the contents.
Issuer: The distinguished name (DN) of the Certificate Authority that issued this certificate. This is the "who vouches for you" part. For example, CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US.
Validity Period:
- Not Before: The date and time after which the certificate is valid.
- Not After: The date and time after which the certificate expires. This is critical for security; expired certificates are untrusted.
Subject: The distinguished name (DN) of the entity the certificate identifies. This is who the certificate says it is. For a website, this would be its Common Name (CN), like CN=example.com. It can also include Organization (O), Organizational Unit (OU), and Country ©.
Subject Public Key Info: Contains the public key itself and the algorithm used for that key (e.g., RSA, ECDSA). This is the core asset the certificate is protecting.
Issuer Unique ID / Subject Unique ID: These are deprecated and rarely used in modern certificates.
Extensions: This is where much of the power and flexibility of X.509 Version 3 lies. They provide additional information not covered by the basic fields. Key extensions include:
- Key Usage: Defines the permitted uses of the public key (e.g., digitalSignature, keyEncipherment, cRLSign).
- Extended Key Usage (EKU): Specifies the intended applications of the certificate (e.g., serverAuth for TLS/SSL, clientAuth for mutual TLS, codeSigning for software).
- Subject Alternative Name (SAN): Crucial for modern web security. It allows a single certificate to cover multiple domain names or IP addresses. This is why a certificate for www.example.com might also be valid for mail.example.com and example.com itself.
- Basic Constraints: Indicates whether the certificate is for an end-entity (like a web server) or a CA (a certificate used to sign other certificates). If it’s a CA, cA=true.
- Certificate Policies: Outlines the policies under which the certificate was issued.
- CRL Distribution Points: Provides URLs where clients can obtain Certificate Revocation Lists (CRLs) to check if a certificate has been revoked before its expiry date.
- Authority Information Access (AIA): Points to locations where clients can find the issuer’s certificate or other OCSP (Online Certificate Status Protocol) responders.
Signature: The actual digital signature created by the CA’s private key over the certificate’s contents (excluding the signature itself). This is what your browser verifies using the CA’s public key.

Let’s look at a real-world example. You can inspect a certificate using openssl x509.

openssl x509 -in example.com.crt -text -noout

This command will output a human-readable version of the certificate. You’d see fields like:

    Issuer: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
    Validity
        Not Before: Oct 10 10:00:00 2023 GMT
        Not After : Jan  8 10:00:00 2024 GMT
    Subject: CN = example.com
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
            Public Key:
                00:a1:b2:c3:... (a very long string of hex bytes)
    X509v3 extensions:
        X509v3 Basic Constraints:
            CA:FALSE
        X509v3 Key Usage:
            Digital Signature, Key Encipherment
        X509v3 Extended Key Usage:
            TLS Web Server Authentication, TLS Web Client Authentication
        X509v3 Subject Alternative Name:
            DNS:example.com, DNS:www.example.com, IP Address:192.0.2.1
        X509v3 CRL Distribution Points:
            Full Name:
              URL:http://crl.letencrypt.org/R3.crl
        X509v3 Authority Information Access:
            OCSP - URI:http://ocsp.letencrypt.org
            CA Issuers - URI:http://cert.letencrypt.org/R3.cer
    Signature Algorithm: sha256WithRSAEncryption

The system of trust relies on a chain. Your browser trusts a set of "root" CAs (like DigiCert, GlobalSign, ISRG Root X1). These root CAs sign certificates for intermediate CAs, and those intermediate CAs sign certificates for end-entities like example.com. When your browser receives example.com’s certificate, it checks the signature using the public key of the intermediate CA that signed it. It then looks for the intermediate CA’s certificate, verifies its signature using the root CA’s public key, and so on, until it reaches a root CA it already trusts.

The most surprising part of this chain-of-trust model is that your operating system or browser doesn’t magically know which CAs to trust. It has a pre-installed list of "root certificates" provided by the OS vendor or browser developer. If a certificate’s issuer cannot be traced back to one of these trusted roots, the connection will be flagged as insecure, even if all the other fields are perfectly valid.

Once you’ve got a handle on X.509, the next logical step is understanding how certificates are revoked, often via CRLs or OCSP.

Related Concepts

More Deep Dives in Tls Ssl