Certificate Fields Explained

An X.509 v3 certificate contains a set of core fields and optional extensions. Understanding each field is essential when debugging TLS handshake failures, validating certificate chains, or generating certificates for internal services.

Core Fields

Version

Indicates the X.509 version. Almost all certificates in use today are v3 (encoded as integer 2). Version 3 is required for extensions.

Serial Number

A unique integer assigned by the CA. The combination of Issuer + Serial Number must be globally unique. CAs use large random serial numbers (at least 20 bytes of entropy per CA/Browser Forum baseline requirements) to prevent collision attacks.

Signature Algorithm

Specifies the algorithm the CA used to sign the certificate, e.g., sha256WithRSAEncryption or ecdsa-with-SHA384. This field appears twice: once in the TBS (to-be-signed) section and once at the top level. Both must match.

Issuer

The Distinguished Name (DN) of the CA that signed the certificate. A DN is a set of attribute-value pairs:

CN = Let's Encrypt Authority X3   (Common Name)
O  = Let's Encrypt                 (Organization)
C  = US                            (Country)

Validity (Not Before / Not After)

Defines the time window during which the certificate is valid. Times are in UTC. Browsers and TLS libraries reject certificates outside this window. Public CA certificates are now limited to 398 days maximum.

Subject

The DN identifying the certificate holder. For TLS server certificates, the Common Name (CN) historically held the hostname, but modern practice requires using the Subject Alternative Name (SAN) extension instead. Many CAs now issue certificates with an empty or minimal Subject, relying entirely on SANs.

Subject Public Key Info

Contains the algorithm identifier (RSA, ECDSA, Ed25519) and the public key bytes. For RSA, this includes the modulus and exponent. For ECDSA, it includes the curve identifier and point coordinates. In .NET, access this via X509Certificate2.PublicKey.

Extensions (v3)

Extensions are typed, optionally critical. A client that encounters a critical extension it does not understand must reject the certificate. Non-critical extensions can be safely ignored.

Subject Alternative Name (SAN)

The authoritative field for matching hostnames. Can contain DNS names, IP addresses, email addresses, and URIs. Wildcards are allowed in the leftmost label only (e.g., *.example.com). If SAN is present, the Subject CN is ignored for hostname matching.

Key Usage

A bitfield that restricts what the key may be used for: digitalSignature, keyEncipherment, keyCertSign, cRLSign, and others. CA certificates need keyCertSign. TLS server certs typically need digitalSignature and keyEncipherment. This extension is usually marked critical.

Extended Key Usage (EKU)

Further restricts key usage to specific purposes. Common OIDs:

1.3.6.1.5.5.7.3.1  — TLS Server Authentication
1.3.6.1.5.5.7.3.2  — TLS Client Authentication
1.3.6.1.5.5.7.3.3  — Code Signing
1.3.6.1.5.5.7.3.4  — Email Protection (S/MIME)

Basic Constraints

Indicates whether the certificate is a CA ( CA:TRUE) and optionally the maximum path length. A leaf certificate has CA:FALSE or omits this extension entirely. This extension is critical and prevents a leaf from issuing child certificates.

CRL Distribution Points

URLs where the CA publishes its Certificate Revocation List. Clients can download the CRL to check if the certificate has been revoked. Largely superseded by OCSP but still present for backward compatibility.

Authority Information Access (AIA)

Contains two important URLs: the OCSP responder endpoint for real-time revocation checking, and the CA Issuers URL where clients can download the issuing CA certificate (critical for chain building when the intermediate is missing from the TLS handshake).

Subject Key Identifier (SKI) & Authority Key Identifier (AKI)

SKI is a hash of the certificate's public key. AKI identifies the issuer's public key (and optionally the issuer DN and serial number). Together they enable efficient chain building: a certificate's AKI should match its issuer's SKI.