X.509 Certificate Structure
Examine the fields inside a digital certificate — subject, issuer, validity period, public key, and extensions — and understand what each means.
X.509 Certificate Structure is a free Cloud & IT Cert Prep lesson on CoddyKit — lesson 2 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Cloud & IT Cert Prep learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
What Is an X.509 Certificate?
An X.509 certificate is a standardized digital document that binds a public key to an identity. The X.509 standard (defined in RFC 5280) specifies the format, fields, and extensions used in digital certificates worldwide. Every TLS/HTTPS certificate, S/MIME email certificate, code-signing certificate, and client authentication certificate follows the X.509 format. Understanding the structure of an X.509 certificate helps you read certificate information, diagnose certificate errors, and make informed decisions about certificate deployment and validation.
# View an X.509 certificate in human-readable form
openssl x509 -in certificate.pem -noout -text
# Or view a website's certificate directly
openssl s_client -connect example.com:443 2>/dev/null | \
openssl x509 -noout -textVersion, Serial Number, and Algorithm
The first fields in an X.509 certificate establish its basic identity. Version: X.509 v3 is the current standard (v3 added extensions). Serial Number: a unique integer assigned by the issuing CA that identifies this specific certificate — used in CRL (revocation lists) to revoke individual certificates. Signature Algorithm: specifies the algorithm used by the CA to sign the certificate (e.g., sha256WithRSAEncryption or ecdsa-with-SHA256). This field appears twice: once in the TBSCertificate and once in the outer signature wrapper — they must match.
# Certificate header fields
# Version: 3 (v3 = supports extensions)
# Serial Number:
# 30:4b:7e:bf:36:e3:46:a8
# Signature Algorithm: sha256WithRSAEncryption
# The serial number is used for revocation:
# CRL lists serial numbers of revoked certificates from this CAIssuer and Subject Fields
Two of the most important fields in a certificate establish the parties involved. The Issuer field identifies the CA that signed the certificate (e.g., CN=DigiCert Global CA G2, O=DigiCert Inc, C=US). The Subject field identifies the entity the certificate was issued to (e.g., CN=*.example.com, O=Example Corp, C=US). For a TLS certificate, the Subject's Common Name (CN) or Subject Alternative Name (SAN) extension specifies which domain name(s) the certificate is valid for. Browsers match the requested hostname against these fields.
# Extract Issuer and Subject
openssl x509 -in cert.pem -noout -subject -issuer
# subject=CN = *.google.com, O = Google LLC, L = Mountain View, ST = California, C = US
# issuer=CN = GTS CA 1C3, O = Google Trust Services LLC, C = US
# Check Subject Alternative Names (critical for hostname validation)
openssl x509 -in cert.pem -noout -ext subjectAltName
# DNS:*.google.com, DNS:google.comValidity Period: notBefore and notAfter
The validity period defines when the certificate is active. It consists of two timestamps: notBefore (the certificate is not yet valid before this date) and notAfter (the certificate has expired after this date). TLS clients verify that the current time falls within this window. Certificates presented outside their validity period cause a certificate error in browsers and must be renewed. Modern best practice is to issue short-lived certificates (90 days, as Let's Encrypt does) to limit exposure if a private key is compromised between issuance and expiry.
# Check certificate expiry dates
openssl x509 -in cert.pem -noout -dates
# notBefore=Jan 1 00:00:00 2026 GMT
# notAfter=Mar 31 23:59:59 2026 GMT
# Check how many days until expiry
echo | openssl s_client -connect example.com:443 2>/dev/null | \
openssl x509 -noout -enddate
# notAfter=Jun 15 12:00:00 2026 GMTPublic Key Field
The certificate's core payload is the Subject Public Key Info field, which contains the public key being certified and specifies the algorithm it is used with. For an RSA certificate, this field contains the modulus and exponent of the RSA public key along with its bit length (2048, 4096). For an ECC certificate, it contains the curve name (e.g., prime256v1) and the public key point. The CA does not generate this key pair — the certificate requestor generates their own key pair and submits only the public key in a Certificate Signing Request (CSR).
# Generate a key pair and CSR (Certificate Signing Request)
# First, generate the private key
openssl genrsa -out server.key 2048
# Create a CSR containing the public key and subject info
openssl req -new -key server.key -out server.csr \
-subj '/CN=www.example.com/O=Example Corp/C=US'
# The CSR is sent to the CA for signing
# The CA returns the signed X.509 certificate
# Private key NEVER leaves your possessionX.509 v3 Extensions
X.509 v3 introduced extensions that significantly expand certificate capabilities. Extensions can be critical (a client that cannot process this extension must reject the certificate) or non-critical (can be ignored if not understood). Key extensions include: Subject Alternative Name (SAN) — additional domain names or IPs the certificate covers; Key Usage — restricts what operations the key can be used for (digital signature, key encipherment); Extended Key Usage — further restricts purpose (TLS server auth, client auth, code signing); and Basic Constraints — indicates if the subject is a CA.
# View X.509 v3 extensions
openssl x509 -in cert.pem -noout -text | grep -A 20 'X509v3 extensions'
# X509v3 Key Usage: critical
# 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
# X509v3 Basic Constraints: critical
# CA:FALSESubject Alternative Name (SAN) vs Common Name
Historically, the Common Name (CN) field in the Subject distinguished field was used for the primary domain name. Modern certificates use Subject Alternative Names (SANs) instead, as browsers deprecated CN-based matching (RFC 2818) in favor of SANs. SANs allow a single certificate to cover multiple domains (multi-SAN certificates) or all subdomains of a domain (wildcard certificates: *.example.com). SAN wildcards only cover one level — *.example.com covers www.example.com but not sub.www.example.com.
CRL Distribution Point and OCSP Extension
Two critical extensions tell clients how to check if a certificate has been revoked before its expiry date. CRL Distribution Points (CDP): contains URLs where the CA's Certificate Revocation List can be downloaded. Authority Information Access (AIA): contains the URL of the CA's OCSP (Online Certificate Status Protocol) responder for real-time revocation checking. Modern clients prefer OCSP over CRL downloads because CRLs can be large files. The CA's digital signature on OCSP responses ensures clients receive authentic revocation status information.
# Check OCSP status of a certificate
openssl ocsp -issuer intermediate_ca.pem \
-cert server_cert.pem \
-url http://ocsp.digicert.com \
-text
# Response shows: good, revoked, or unknown
# server_cert.pem: good
# This Update: Jun 21 00:00:00 2026 GMTCertificate Formats: PEM, DER, PFX
X.509 certificates come in several encoding formats that you will encounter in practice. PEM (Privacy Enhanced Mail): base64-encoded DER wrapped in -----BEGIN CERTIFICATE----- headers. Human-readable, used on Linux/Apache/nginx. DER (Distinguished Encoding Rules): binary format. Used on Java applications and some Windows contexts. PFX/PKCS#12: a container format that bundles the certificate, its chain, and the private key in one password-protected file. Used in Windows IIS and when exporting certificates with their private keys. P7B/PKCS#7: certificate chain only, no private key, used in Windows certificate stores.
# Convert between certificate formats
# PEM to DER
openssl x509 -in cert.pem -outform DER -out cert.der
# DER to PEM
openssl x509 -in cert.der -inform DER -outform PEM -out cert.pem
# Export certificate + private key to PFX (for Windows IIS)
openssl pkcs12 -export -in cert.pem -inkey private.key \
-certfile chain.pem -out cert.pfx -passout pass:ExportPasswordCertificate Transparency (CT Logs)
Certificate Transparency (CT) is a framework that requires CAs to log all issued certificates to publicly auditable logs. This allows anyone to monitor for unauthorized certificates issued for their domains. Chrome and Safari require CT log inclusion for TLS certificates. SCT (Signed Certificate Timestamp) is proof of log inclusion, embedded in the certificate or delivered via TLS extension. CT logs expose mis-issuance rapidly — if a CA incorrectly issues a certificate for your domain, you'll see it in logs like crt.sh before attackers can abuse it.
# Search for all certificates issued for a domain using crt.sh
# This would be done via browser or API:
# https://crt.sh/?q=example.com
# Check CT log inclusion in a certificate
openssl x509 -in cert.pem -noout -text | grep -A 5 'CT Precertificate'
# X509v3 extension: CT Precertificate SCTs (critical)
# Signed Certificate Timestamp:
# Version: v1 (0x0)
# Log ID: A4:B9...CA Signature on the Certificate
The last component of an X.509 certificate is the CA's digital signature. The CA hashes all the certificate data (TBSCertificate) and signs that hash with its own private key. This signature is what makes the certificate trustworthy — anyone can verify it using the CA's public key (found in the CA's own certificate). The signature algorithm used (listed in the signature field) must match what's specified earlier in the certificate. Any modification to the certificate after signing invalidates the signature, ensuring the certificate's integrity.
# Verify that a certificate was signed by a specific CA
openssl verify -CAfile ca_chain.pem server_cert.pem
# server_cert.pem: OK
# If the signature is invalid or the chain is broken:
# server_cert.pem: C = US, O = Example, CN = www.example.com
# error 20 at 0 depth lookup: unable to get local issuer certificateQuick Check
Test your understanding of CompTIA Security+ (SY0-701) concepts from this lesson.
Lesson Recap
In this lesson you learned: an X.509 certificate contains version, serial number, issuer, subject, validity period, public key, and v3 extensions; the SAN extension controls which hostnames the cert covers; CDP and AIA extensions point to revocation checking endpoints; and CT logs provide public audit trails of certificate issuance. Next up we explore Certificate Lifecycle and Revocation.
Frequently asked questions
Is the “X.509 Certificate Structure” lesson free?
Yes — the full text of “X.509 Certificate Structure” is free to read here on the web, and the Cloud & IT Cert Prep course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Cloud & IT Cert Prep course, upgrade to CoddyKit PRO.
What will I learn in “X.509 Certificate Structure”?
Examine the fields inside a digital certificate — subject, issuer, validity period, public key, and extensions — and understand what each means. You practise Cloud & IT Cert Prep with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Cloud & IT Cert Prep?
No prior experience is required. Cloud & IT Cert Prep on CoddyKit is structured for beginners through advanced learners; this is — lesson 2 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “X.509 Certificate Structure” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Cloud & IT Cert Prep lesson?
Yes. Every Cloud & IT Cert Prep lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.