Public Key Infrastructure: X.509 Digital Certificates & Trust Chains

When an unknown web server presents a public key during an SSL handshake, how does your browser know that public key genuinely belongs to bank.com and not to an attacker eavesdropping on the network? Public Key Infrastructure (PKI) is the comprehensive framework of hardware, software, policies, and standards that binds public keys to verified identities using X.509 Digital Certificates.

The Hierarchical Trust Chain: Root and Intermediate CAs

PKI relies on trusted third-party organizations called Certificate Authorities (CAs) (such as DigiCert, Let's Encrypt, Sectigo):

Root CA: Sits at the apex of the trust tree. Its private key is kept locked in an offline, air-gapped hardware security module (HSM) inside a secure physical vault. Operating systems (Windows, macOS, Linux, Android) ship with ~150 pre-installed Root CA certificates in their Root Trust Store.
Intermediate CA: The Root CA signs an Intermediate CA certificate. Intermediate CAs are online and handle daily automated certificate issuances. If an Intermediate CA is ever compromised, it can be revoked without invalidating the Root CA.
End-Entity / Leaf Certificate: The certificate issued to your website domain (e.g. veewom.com). Your server sends the Leaf certificate plus Intermediate certificates (the full Certificate Chain) to the visiting browser.

Anatomy of an X.509 Certificate

Standardized under ITU-T X.509, digital certificates contain structured cryptographic fields:

Subject: The entity being identified (Common Name: *.veewom.com).
Subject Alternative Name (SAN): All domain names covered (e.g., veewom.com, api.veewom.com).
Public Key Algorithm & Value: The public key (e.g., RSA 2048-bit or ECC Curve25519).
Issuer: The CA that signed the certificate (e.g., Let's Encrypt Authority X3).
Validity Period: Not Before and Not After dates (Industry maximum validity is currently 398 days).
CA Digital Signature: A cryptographic signature calculated over all the above fields by the CA's private key.

Certificate Revocation: CRL vs. OCSP Stapling

When a private key is accidentally leaked or stolen, the certificate must be revoked before its expiration date:

Revocation Mechanism	How It Operates	Flaws & Security Limitations
CRL (Certificate Revocation List)	CA publishes a periodic flat list of serial numbers of revoked certs. Browsers download the file.	Files grow to tens of megabytes; slow connection delays; updates are delayed by days.
OCSP (Online Certificate Status Protocol)	Browser queries the CA's live server directly: "Is certificate #12345 valid right now?"	Leaked privacy: the CA learns every website the user visits; causes network latency.
OCSP Stapling (RFC 6066)	The web server periodically queries the CA, caches the time-stamped CA response, and staples it directly to the TLS handshake.	GOLD STANDARD! Zero privacy leak, zero browser latency, tamper-proof cryptographic CA timestamp.

Essential OpenSSL Certificate Commands

# 1. Generate an ECDSA private key and Certificate Signing Request (CSR)
openssl ecparam -name prime256v1 -genkey -noout -out server.key
openssl req -new -key server.key -out server.csr

# 2. Inspect raw contents and expiration of an X.509 certificate
openssl x509 -in server.crt -text -noout

# 3. Test live SSL certificate chain on a remote domain
openssl s_client -connect veewom.com:443 -servername veewom.com

Frequently Asked Questions (FAQ) - Student & Interview Review

Q1. What is Certificate Pinning (HPKP / Mobile Pinning)?

Certificate Pinning hardcodes the expected public key hash of the server inside a mobile application. The app rejects connections even if an attacker tricks a compromised corporate Root CA into generating a forged certificate.

Q2. What is Let's Encrypt and ACME protocol?

Let's Encrypt is a free, automated open-source certificate authority. It uses the ACME (Automated Certificate Management Environment) protocol via tools like Certbot to automatically verify domain ownership and renew 90-day certificates without human intervention.