Training PKI FoundationsLesson 1.6

Module 1: PKI Fundamentals

Lesson 1.6: X.509 Certificate Structure and Fields

25–30 minutes

Reading + Quiz

PreviousModule Review

Learning Objectives

Identify the major fields in an X.509 v3 certificate and describe the purpose of each
Explain the role of the Subject Alternative Name extension in TLS server certificate validation
Distinguish between Key Usage and Extended Key Usage and describe when each applies
Explain the Basic Constraints extension and the pathLenConstraint value
Describe the purpose of CDP and AIA extensions and why their availability matters
Explain the difference between critical and non-critical extensions
Identify the fields used in certificate revocation and chain validation

The X.509 Standard

Every digital certificate used in enterprise PKI — TLS server certificates, user authentication certificates, code signing certificates, device certificates — is an X.509 version 3 certificate. The X.509 standard is defined by the ITU-T and implemented for the internet by the IETF in RFC 5280. When you open a certificate in Windows Certificate Manager, examine it with OpenSSL, or review it in a browser's certificate viewer, you are looking at the fields defined by this standard.

A certificate is a signed data structure. It contains information about the subject (the entity the certificate was issued to) and the issuer (the Certificate Authority that signed it). The CA's digital signature over the certificate's content is what makes the certificate trustworthy. If the content is altered after signing, the signature becomes invalid and the certificate will be rejected.

The certificate structure has two main parts: the TBSCertificate (to-be-signed certificate — the data the CA signs) and the outer Certificate structure that wraps the TBSCertificate with the CA's signature and the signature algorithm identifier.

Key Concept

X.509 Version 3 Is the Only Version in Use

Version 3 introduced the extensions mechanism — the ability to add structured additional information to a certificate beyond the basic fields. Extensions are essential for enterprise PKI: they carry the SAN, Key Usage, EKU, Basic Constraints, CDP, and AIA values that control how certificates are used and validated. Versions 1 and 2 are obsolete and should not be issued.

Core Certificate Fields

The following fields appear in every X.509 v3 certificate. Understanding each field is essential for reading certificates, diagnosing validation failures, and designing certificate templates.

Field

Type

Purpose

`Version`	Field	Identifies the X.509 version. Must be v3 (value 2) for certificates with extensions. Version 1 and 2 certificates cannot carry extensions.
`SerialNumber`	Field	A unique integer assigned by the issuing CA. Used in CRLs and OCSP responses to identify revoked certificates. Must be unique within the CA's namespace.
`Signature`	Field	The algorithm identifier for the CA's signature (e.g., sha256WithRSAEncryption). Appears in both the TBSCertificate and the outer Certificate — both must match.
`Issuer`	Field	The Distinguished Name of the CA that signed this certificate. Must match the Subject field of the issuing CA's own certificate for chain validation to succeed.
`Validity`	Field	Contains Not Before and Not After sub-fields defining the certificate's operational window. Both expressed in UTC time. Certificate expiration is determined entirely by Not After.
`Subject`	Field	The Distinguished Name of the entity the certificate was issued to. For TLS server certificates, the Subject CN is no longer used for hostname validation — the SAN extension is authoritative.
`SubjectPublicKeyInfo`	Field	Contains the public key and the algorithm identifier (RSA, ECDSA, etc.). The corresponding private key must be kept secret by the certificate subject.

Production Note

Subject CN vs. SAN for TLS Hostname Validation

Modern TLS clients (browsers, operating systems, programming language TLS libraries) validate the server hostname against the Subject Alternative Name extension — not the Subject Common Name. A certificate that has the correct hostname in the Subject CN but no SAN extension, or a SAN that does not include the hostname, will fail TLS validation. Always ensure the SAN extension is present and correct.

X.509 v3 Extensions

Extensions are the mechanism by which X.509 v3 certificates carry additional information beyond the basic fields. Each extension has an OID (Object Identifier), a criticality flag, and a value. Extensions can be marked critical or non-critical.

Key Concept

Critical vs. Non-Critical Extensions

A critical extension must be understood and enforced by any system that processes the certificate. If a system encounters a critical extension it does not recognize, it must reject the certificate. A non-critical extension can be ignored if not understood. This distinction is important when deploying certificates to systems with varying levels of X.509 support.

The following extensions are the most important for enterprise PKI practitioners to understand:

subjectAltNameExtensionOID 2.5.29.17

Subject Alternative Name (SAN)

The SAN extension contains the identifiers the certificate is valid for: DNS names, IP addresses, email addresses, and URIs. For TLS server certificates, this is the authoritative source for hostname validation. A certificate may contain multiple DNS names (including wildcards such as *.example.com) and multiple IP addresses.

Common Mistake

Relying on Subject CN for TLS Hostname Validation

The Subject Common Name (CN) field was historically used for TLS hostname validation, but this practice was deprecated. RFC 2818 (HTTP over TLS) specifies that if a SAN extension is present, the CN must not be used for hostname matching. Current browsers and TLS libraries enforce this. Always include the correct DNS names in the SAN extension.

keyUsageExtensionCriticalOID 2.5.29.15

Key Usage

Key Usage defines the cryptographic operations the certificate's public key may be used for. It is typically marked critical. The most common values are:

digitalSignatureAuthentication, TLS handshake, document signing

keyEnciphermentRSA key exchange (TLS with RSA key exchange)

keyAgreementECDH key exchange

keyCertSignCA certificate signing — CA certificates only

cRLSignCRL signing — CA certificates only

nonRepudiationSigned documents, legal non-repudiation

extKeyUsageExtensionOID 2.5.29.37

Extended Key Usage (EKU)

EKU further restricts the purposes for which the certificate may be used. Each EKU value is identified by an OID. In ADCS, the EKU values on a certificate template determine what the issued certificate can be used for. Mismatched EKU values are a common source of certificate validation failures.

Server Authentication1.3.6.1.5.5.7.3.1TLS server certificates

Client Authentication1.3.6.1.5.5.7.3.2TLS client certificates, smart card logon

Code Signing1.3.6.1.5.5.7.3.3Software and script signing

Email Protection1.3.6.1.5.5.7.3.4S/MIME email signing and encryption

Smart Card Logon1.3.6.1.4.1.311.20.2.2Windows smart card authentication

Time Stamping1.3.6.1.5.5.7.3.8Trusted timestamp authority certificates

basicConstraintsExtensionCritical (on CA certs)OID 2.5.29.19

Basic Constraints

Basic Constraints identifies whether the certificate is a CA certificate or an end-entity certificate. For CA certificates, the cA boolean is set to TRUE. The optional pathLenConstraint limits how many subordinate CA certificates may appear below this CA in a valid certification path.

Root CA

cA=TRUE, pathLen=1 (or unconstrained)Can issue Issuing CA certificates

Issuing CA

cA=TRUE, pathLen=0Can only issue end-entity certificates

End-entity

cA=FALSE (or absent)Cannot issue any certificates

Authority Key Identifier and Subject Key Identifier

These two extensions work together to support efficient certificate chain building.

authorityKeyIdentifierOID 2.5.29.35

Contains the key identifier of the issuing CA's public key. Clients use this to locate the correct issuer certificate when multiple CA certificates are present in the trust store. The value matches the Subject Key Identifier of the issuing CA's certificate.

subjectKeyIdentifierOID 2.5.29.14

Contains a key identifier for the certificate's own public key. This value is used as the Authority Key Identifier in certificates issued by this CA, creating a verifiable link between issuer and subject in the chain.

CRL Distribution Points and Authority Information Access

These extensions provide the URLs clients need to validate the certificate's revocation status and build the certificate chain. Both must be reachable from all clients that will validate the certificate.

cRLDistributionPointsOID 2.5.29.31

Contains one or more URLs where clients can download the Certificate Revocation List published by the issuing CA. Clients check whether the certificate's serial number appears on the CRL. If the CDP URL is unreachable or the CRL has expired, clients may fail open — accepting revoked certificates as valid.

authorityInfoAccessOID 1.3.6.1.5.5.7.1.1

Contains two types of URLs: the caIssuers URL (location of the issuing CA's certificate, used for chain building) and the OCSP URL (Online Certificate Status Protocol responder, used for real-time revocation checking). Both must be reachable from clients.

Security Consideration

CDP and AIA Availability Is a Security Requirement

If clients cannot reach the CDP or AIA URLs, certificate chain building and revocation checking may fail. Depending on client configuration, this can cause authentication failures (fail closed) or allow revoked certificates to be accepted (fail open). In enterprise PKI, CDP and AIA endpoints must be hosted on highly available infrastructure reachable from all client networks — including remote access clients and cloud workloads.

Reading a Certificate — Field Reference

The following example shows the key fields as they appear in an OpenSSL text dump of a TLS server certificate. Understanding how to read this output is a practical skill for diagnosing certificate validation failures.

Certificate:
  Data:
    Version: 3 (0x2)
    Serial Number:
        04:b3:16:8f:e4:13:c8:d3:...(truncated)
    Signature Algorithm: sha256WithRSAEncryption
    Issuer: C=US, O=Example Corp, CN=Example Issuing CA
    Validity
        Not Before: Jan  1 00:00:00 2026 GMT
        Not After : Dec 31 23:59:59 2026 GMT
    Subject: C=US, O=Example Corp, CN=webserver.example.com
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
            RSA Public-Key: (2048 bit)
    X509v3 extensions:
        X509v3 Subject Alternative Name:
            DNS:webserver.example.com, DNS:www.example.com
        X509v3 Key Usage: critical
            Digital Signature, Key Encipherment
        X509v3 Extended Key Usage:
            TLS Web Server Authentication
        X509v3 Basic Constraints: critical
            CA:FALSE
        X509v3 Authority Key Identifier:
            keyid:A1:B2:C3:D4:...(truncated)
        X509v3 Subject Key Identifier:
            E5:F6:07:18:...(truncated)
        X509v3 CRL Distribution Points:
            Full Name:
              URI:http://crl.example.com/IssuingCA.crl
        Authority Information Access:
            OCSP - URI:http://ocsp.example.com
            CA Issuers - URI:http://aia.example.com/IssuingCA.crt

Production Note

Verify SAN, EKU, and CDP/AIA on Every Issued Certificate

After issuing a certificate, verify that the SAN contains the correct DNS names, the EKU matches the intended use case, and the CDP and AIA URLs are reachable from the client network. These are the three most common sources of certificate validation failures in enterprise environments.

Common Certificate Validation Failures

Hostname mismatch

Cause: SAN extension does not contain the hostname the client is connecting to

Fix: Reissue the certificate with the correct DNS names in the SAN extension

Certificate not yet valid

Cause: Client clock is behind the certificate's Not Before date, or the certificate was issued with a future Not Before

Fix: Verify client clock synchronization; check Not Before date on the certificate

Certificate expired

Cause: Current date is past the certificate's Not After date

Fix: Renew the certificate; implement expiration monitoring to prevent recurrence

EKU mismatch

Cause: Certificate EKU does not include the required purpose (e.g., Server Authentication for TLS)

Fix: Reissue from a template with the correct EKU values

Chain building failure

Cause: Issuing CA certificate not available — AIA URL unreachable or CA cert not in trust store

Fix: Verify AIA URL is reachable; ensure intermediate CA certificate is included in the TLS handshake

Revocation check failure

Cause: CDP URL unreachable or CRL expired; OCSP responder unavailable

Fix: Verify CDP and AIA OCSP URLs are reachable from client networks; check CRL publication schedule

Lesson 1.6 Knowledge Check

7 questions · Select the best answer for each question · Score 70% or higher to pass

1. Which X.509 field contains the DNS names and IP addresses that a TLS certificate is valid for?

2. A certificate has the Key Usage extension set to "Certificate Sign" and "CRL Sign". What type of certificate is this?

3. What is the purpose of the Serial Number field in an X.509 certificate?

4. A critical extension is encountered in a certificate by a client system that does not recognize it. What must the client do?

5. What information does the Authority Information Access (AIA) extension provide?

6. A TLS server certificate is presented to a browser. The certificate's Subject field contains CN=webserver.example.com, but the SAN extension is absent. The browser is connecting to https://webserver.example.com. What will happen?

7. What does the Basic Constraints extension's pathLenConstraint value control?

Finished reading?

Mark this lesson complete and continue to the Module 1 Review.

Module 1 Review

In This Lesson

A. The X.509 Standard

B. Core Certificate Fields

C. X.509 v3 Extensions

D. Reading a Certificate

E. Common Validation Failures

Knowledge Check

Glossary

Lesson Worksheet

X.509 Field Reference Card

Certificate fields, extension OIDs, and common validation failure reference.

Coming Soon

Module 1 Lessons

1.1 What Is PKI?1.2 Public and Private Keys 1.3 Hash Functions and Digital Signatures 1.4 The PKI Trust Hierarchy 1.5 Certificate Lifecycle

1.6 X.509 Certificate Structure

Your Progress

Not yet complete

5 of 18 lessons complete (est.)