X.509 Certificate Structure and PKI Components
I. X.509 — the certificate standard format
Certificates used today in TLS/code-signing/S/MIME follow the X.509 v3 standard. Main fields:
| Field | Meaning |
|---|---|
| Version | Version (v3) |
| Serial Number | Unique serial assigned by the CA (used to identify revocation) |
| Signature Algorithm | Signing algorithm (e.g., SHA-256 with RSA / ECDSA) |
| Issuer | Distinguished name (DN) of the issuer (CA) |
| Validity | Validity period (Not Before ~ Not After) |
| Subject | DN of the subject (certificate owner) |
| Subject Public Key | The subject's public key + algorithm |
| Extensions (v3) | Extension fields (below) |
| Signature | The CA's signature over the above |
Key v3 extensions
| Extension | Role |
|---|---|
| SAN (Subject Alternative Name) | List of actual applicable domains. Modern browsers look at SAN, not CN |
| Key Usage | Key purpose (digital signature, key encipherment, etc.) |
| Extended Key Usage (EKU) | Detailed purpose (serverAuth, clientAuth, codeSigning…) |
| Basic Constraints | CA:TRUE/FALSE — whether it's a CA certificate, chain depth |
| AKI / SKI | Authority/Subject Key Identifier — used to link the chain |
| CRL Distribution / AIA | Location of revocation list / OCSP / issuer certificate |
:::caution CN is no longer trusted In the past the domain went in the Common Name (CN), but browsers now use only SAN for domain validation. Without SAN, it's rejected as a domain mismatch. :::
II. Encoding and file extensions
The same certificate differs by encoding/purpose.
| Encoding/format | Description | Extensions |
|---|---|---|
| DER | Binary | .der .cer |
| PEM | DER as Base64 + -----BEGIN CERTIFICATE----- header | .pem .crt .cer |
| PKCS#12 | Certificate + private key bundled, password-protected | .p12 .pfx |
| PKCS#7 | Certificate/chain bundle (no key) | .p7b |
| CSR | Certificate Signing Request | .csr |
-----BEGIN CERTIFICATE-----
MIIDdjCCAl6gAwIBAg-...(Base64)...
-----END CERTIFICATE-----
III. PKI components
PKI (Public Key Infrastructure) is the whole system that issues, manages, and verifies certificates.
| Element | Role |
|---|---|
| CA (Certificate Authority) | The trusted entity that issues/signs/revokes certificates |
| RA (Registration Authority) | Verifies applicant identity (screens on behalf of the CA) |
| VA (Validation Authority) | Provides revocation status (OCSP/CRL) |
| CSR | The "signing request" the applicant creates (public key + identity) |
| Certificate repository | Publishes issued certificates / CRLs |
| Subscriber / relying party | The certificate owner / the party that trusts it (the browser) |
Issuance flow (concept)
Applicant: generate a key pair (keep the private key) → create a CSR (public key + identity) → submit to CA
CA/RA: verify identity / domain ownership (DV/OV/EV)
CA: on pass → sign with the CA private key → issue certificate
Applicant: install certificate + intermediate CA (chain)
:::info The private key is never handed over A CSR carries only the public key. The private key never leaves the applicant's server. This is a basic PKI principle. :::
IV. Validation levels (DV / OV / EV)
| Level | Validation scope | Use |
|---|---|---|
| DV (Domain Validation) | Confirms domain ownership only | Most websites, automated issuance (ACME) |
| OV (Organization Validation) | Verifies the organization's existence too | Corporate sites |
| EV (Extended Validation) | Strict legal-entity verification | Finance, etc. (formerly the green address bar) |
Encryption strength is identical across all three. The difference is only the rigor of identity validation.
V. Conclusion
An X.509 certificate is a structured document of identity + public key + extensions (SAN, etc.) + CA signature, and PKI is the ecosystem that issues/verifies/revokes it. The next document looks at how these certificates connect into a chain of trust and the role of the root.