Whether you're configuring internal network services, integrating with payment gateways, or deploying code-signing pipelines, you will encounter PKI — and understanding it at a deep level separates reactive troubleshooting from confident engineering.
The problem PKI solves
Public key cryptography is elegant in theory: you distribute your public key freely, anyone can encrypt a message only you can read, and you can sign messages proving only you could have authored them. The fatal gap, however, is identity. A public key is just a number. Nothing about it proves who owns the corresponding private key. In an e-commerce scenario, a malicious actor could intercept your connection to a bank, substitute their own public key, and silently relay — and read — everything you "securely" send. This is a classic man-in-the-middle attack, and it is exactly the threat PKI is designed to defeat.
PKI's answer is the digital certificate: a standardized package (defined by the X.509 standard, formalized in RFC 5280) that binds a public key to an identity and is cryptographically signed by a trusted third party, the Certificate Authority (CA). The reasoning is circular in the best way — if you already trust the CA, and the CA says this key belongs to this entity, then you transitively trust the key-entity binding.
Certificate authorities and the root of trust
┌───────────────────────────────────┐
│ ROOT CA │
│ Self-signed root certificate │
│ RSA 2048/4096-bit or ECC equiv. │
└───────────────┬───────────────────┘
│ signs
┌───────────────▼───────────────────┐
│ INTERMEDIATE CA │
│ Scoped certificate policies │
│ Issues leaf/end-entity certs │
└──────┬─────────────────┬──────────┘
│ signs │ signs
┌───────────▼──────┐ ┌───────▼──────────┐
│ Web server cert │ │ Email user cert │
│ (SAN = FQDN/IP) │ │ (SAN = RFC 822) │
└──────────────────┘ └───────────────────┘
A root certificate is self-signed: the CA issues a certificate to itself, signing it with its own private key. This breaks the otherwise infinite regress of "who vouches for the voucher?" The root certificate's public key is distributed out-of-band — embedded in operating systems and browsers during manufacture. Once a client installs or inherits a root certificate, it automatically trusts any certificate that chains back to it.
The most resilient commercial deployments use a hierarchical model. The root CA issues certificates only to intermediate CAs, then goes offline in a physically secured vault. The intermediates, operating online, issue certificates to actual subjects (servers, users, code). If an intermediate is compromised, its certificates can be revoked without destroying the entire PKI. This is how large commercial CAs such as DigiCert, Comodo, IdenTrust, and Let's Encrypt operate. A certificate's certification path — from leaf to intermediate to root — is also called the chain of trust.
The simplest alternative is a single CA model common on private networks, where one server acts as both root and issuer. It is easy to set up but fragile: compromise the single CA and the entire infrastructure collapses. For internal use only, acceptable; for anything public-facing, not recommended.
Finally, self-signed certificates — where a server signs its own certificate with its own key — are valid for development and testing but should never protect production systems. Browsers will flag them as untrusted, and for good reason: there is no third party vouching for the key owner's identity.
How a certificate gets issued: the CSR process
SUBJECT CERTIFICATE AUTHORITY
─────── ─────────────────────
1. Generate key pair
(RSA/ECC, chosen length)
2. Compose CSR with public key
+ identity fields (CN, O, SAN) ──────► 3. Validate identity
(WHOIS, domain control,
org verification)
◄──────── 4. Sign & return cert
3. Install signed certificate
4. Present to clients on TLS handshake
Registration is the CA's process for verifying who a subject actually is before countersigning their public key. In a Windows domain, users and machines may auto-enroll by authenticating to Active Directory. Third-party CAs typically perform domain control validation (a DNS record or file placed on the web server), organization validation (business registry checks), or the full extended validation (EV) process that inspects legal filings and calls registered phone numbers.
The Certificate Signing Request (CSR) is the formal mechanism. The subject generates its key pair, keeps the private key entirely to itself, and constructs a file containing the public key plus desired certificate fields. The CA reviews the CSR, confirms the subject is who they claim to be, and returns a signed certificate.
Subject identity in certificates: CN, SAN, and wildcards
Early certificates used the Common Name (CN) attribute to carry the domain name — a convention that grew organically rather than by design. Because CN can hold arbitrary text, browsers struggled to interpret it consistently. The CN field is now deprecated for host identity purposes.
Modern certificates use the Subject Alternative Name (SAN) extension, which accepts typed identifiers: FQDNs, IP addresses, email addresses (RFC 822 format for email certificates), and more. Browsers validate against SAN and ignore CN for identity purposes, though best practice still duplicates the primary FQDN in CN for legacy compatibility.
A few SAN strategies worth knowing:
- Explicit subdomains: listing
www.example.comandmembers.example.comseparately is more secure — a rogue subdomain cannot slip under the certificate. - Wildcard domain:
*.example.comcovers all immediate subdomains in a single certificate, convenient but broader in scope. - Multi-SAN certificate: a single certificate covering multiple entirely different domains, useful for hosting providers.
Beyond server certificates, the same framework issues email certificates (SAN = email address), code-signing certificates (no SAN; CA verifies the publisher's organization to prevent impersonation), and user identity certificates for smart card authentication.
A certificate also carries a Distinguished Name (DN) that concatenates CN, Organizational Unit (OU), Organization (O), Locality (L), State (ST), and Country (C) into a structured identifier — for example: CN=www.example.com, OU=Web Hosting, O=Example LLC, L=Chicago, ST=Illinois, C=US.
Certificate revocation: CRL and OCSP
Certificates have fixed validity periods, but sometimes a certificate must be invalidated before expiry: a private key is stolen, a domain changes hands, an employee leaves, or a CA discovers it was fooled into issuing to a fraudulent subject. Two mechanisms handle this.
┌──────────────────────────────────────────────────────────┐
│ REVOCATION METHODS │
│ │
│ CRL (Certificate Revocation List) │
│ ───────────────────────────────── │
│ • CA publishes a signed list of revoked serial numbers │
│ • Published on a schedule (e.g. every 24 hours) │
│ • Validity period slightly longer than publish period │
│ • Client downloads full list; may be stale │
│ │
│ OCSP (Online Certificate Status Protocol) │
│ ────────────────────────────────────────── │
│ • Client queries an OCSP responder with a cert serial │
│ • Responder returns: Good / Revoked / Unknown │
│ • Near real-time; smaller network payload than CRL │
│ • Some OCSP servers still back-end onto CRLs │
└──────────────────────────────────────────────────────────┘
A revoked certificate is permanently invalid; a suspended certificate (status: Certificate Hold) can be re-enabled. Both appear in the CA's Certificate Revocation List. The CRL includes a publish timestamp, distribution point URLs, a validity period, and a CA signature to authenticate the list itself. The CRL URL is embedded directly in the certificate, so browsers know where to check.
The practical weakness of CRL is staleness: a certificate may be revoked hours before the next publication, and clients holding an older CRL remain unaware. OCSP solves this by turning revocation checks into individual queries, returning a real-time status. Most modern OCSP servers query the certificate database directly. The certificate specifies where to find the OCSP responder in the Authority Information Access (AIA) extension.
Key management across the lifecycle
Managing cryptographic keys responsibly means thinking across their entire lifetime:
Generate ──► Store ──► Use ──► Revoke ──► Expire/Renew
│ │ │
│ └──► protect with └──► new key pair
│ TPM / HSM / enclave or same pair
└──► high-entropy RNG essential
- Generation: a key's security depends entirely on the randomness of the generation process. Deterministic pseudo-random number generators (PRNGs) are weak seeds. True random number generators (TRNGs) use physical entropy — electrical noise, thermal variation, air turbulence — as a nondeterministic seed. This is why dedicated cryptoprocessors matter.
- Storage: a key file on a general-purpose filesystem is only as safe as the OS and credentials protecting it. Theft of the device or a credential compromise exposes the key silently.
- Revocation: if a key is compromised, all data encrypted with it should be re-encrypted under a new key. Without tamper detection this process begins late.
- Expiration and renewal: every certificate carries a validity period. Expiry forces periodic rotation, limiting the window during which a silently compromised key can be exploited. Renewal can reuse the same key pair or generate a new one.
A decentralized key management model lets each device or account generate and store its own keys — easy to deploy but hard to audit. A centralized key management system (KMS) keeps all keys on a dedicated server or appliance; devices use the Key Management Interoperability Protocol (KMIP) to request cryptographic operations without ever receiving the raw key material.
Cryptoprocessors: TPMs, HSMs, and secure enclaves
The most robust key protection moves key material off general-purpose hardware entirely.
┌───────────────────────────────────────────────────────────────┐
│ CRYPTOPROCESSOR COMPARISON │
│ │
│ TPM (Trusted Platform Module) │
│ • Bound to a single device (desktop, laptop, embedded) │
│ • Discrete: dedicated chip — tamper resistant │
│ • Integrated: part of CPU/chipset — not tamper resistant │
│ • Firmware (Intel PTT / AMD fTPM): broadest attack surface │
│ • Version 2.0 not backward compatible with 1.2 │
│ │
│ HSM (Hardware Security Module) │
│ • Rack-mounted appliance, PCIe card, or USB security key │
│ • Centralised key storage for networked hosts │
│ • FIPS 140-2 certified variants available │
│ • Also available as virtual appliance │
│ │
│ Secure Enclave (TEE) │
│ • Protected memory region in CPU (e.g. Intel SGX) │
│ • Locked to a list of digitally-signed processes │
│ • Even root/SYSTEM cannot read enclave memory │
│ • Mitigates in-memory key exposure during decryption │
└───────────────────────────────────────────────────────────────┘
The critical vulnerability that cryptoprocessors address: even if a key never leaves a TPM or HSM, the _decrypted plaintext_ must at some point be loaded into RAM for an application to use it. A malicious process with sufficient privilege could read that RAM. Secure enclaves (Trusted Execution Environments, or TEEs) solve this by creating a memory region that the CPU itself enforces as inaccessible to all other processes — even the operating system kernel. The enclave is cryptographically tied to specific signed applications; any other process attempting to read it is blocked at the hardware level.
Applications communicate with cryptoprocessors through the PKCS#11 API, a standardized interface that lets software request operations (sign, decrypt, generate key) without ever touching the raw key bytes.
Key escrow and M-of-N controls
The inverse problem from key compromise is key loss. If a private key is destroyed and no backup exists, all data encrypted to that key is permanently unrecoverable. Naive backups widen the attack surface proportionally. The industry solution is key escrow: the key, or a share of it, is held independently by a trusted third party.
Key split into N shares
───────────────────────
Share 1 ──► Escrow agent A
Share 2 ──► Escrow agent B } M-of-N: any M agents must
Share 3 ──► Escrow agent C cooperate to reconstruct key
...
Share N ──► Escrow agent N
Key Recovery Agent (KRA) account required for each holder.
Recovery policy enforces minimum quorum M before reconstruction.
M of N controls (sometimes called Shamir's Secret Sharing in implementation) ensure that no single individual — not even an insider with malicious intent — can unilaterally recover a key. A common configuration might be 3-of-5: any three of five designated Key Recovery Agents must authenticate and authorize the recovery operation before the key is reconstructed. This simultaneously protects against insider threat and against the availability risk of any single KRA being unreachable.
Putting it all together
PKI is not a single technology but an interlocking system: cryptographic algorithms generate key pairs, X.509 structures encode identity and validity, certificate authorities vouch for key-to-identity bindings, hierarchical trust chains extend that vouching at scale, revocation mechanisms invalidate compromised credentials in near-real-time, and cryptoprocessors protect the key material that underpins all of it.
As a practitioner, your responsibilities span the full lifecycle: choosing appropriate key lengths and algorithms, submitting CSRs with correctly configured SAN fields, monitoring certificate expiration, configuring CRL and OCSP endpoints, deciding between TPM-bound device keys and centrally managed HSM keys, and establishing recovery procedures using escrow and M-of-N quorums. Each layer of this architecture reinforces the others — and a gap in any one layer can undermine the entire chain of trust.