PKI and Digital Certificates

PKI and Digital Certificates: Core Concepts

Asymmetric encryption lets you encrypt data with a public key, but how do you know that a public key actually belongs to the person or server you think it does? If an attacker can substitute their own public key for the target's, they can intercept and decrypt all your communications. Public Key Infrastructure (PKI) solves this trust problem by using digital certificates to bind public keys to identities.

What a Certificate Contains

An X.509 certificate (the standard format) contains:

• Subject — The entity the certificate identifies (domain name, organization, or individual)
• Issuer — The Certificate Authority (CA) that signed the certificate
• Public key — The subject's public key
• Validity period — Not Before and Not After dates
• Serial number — Unique identifier assigned by the CA
• Signature algorithm — The algorithm used by the CA to sign (e.g., SHA256withRSA)
• Signature — The CA's digital signature over all the above fields

The certificate is essentially a statement by the CA: "We have verified that this public key belongs to this subject."

Certificate Authorities and the Chain of Trust

A Certificate Authority (CA) is a trusted entity that issues and signs certificates. The CA uses its own private key to sign certificates, and anyone with the CA's public key can verify those signatures.

The trust model is hierarchical:

Root CA (self-signed, offline)
    └── Intermediate CA (signed by Root)
            └── End-entity certificate (signed by Intermediate)

Root CAs are self-signed and kept offline (air-gapped) to protect their private keys. If a root CA's private key is compromised, every certificate in the hierarchy is untrustworthy.

Intermediate CAs are signed by the root and issue end-entity certificates. This separation means the root can stay offline while intermediates handle daily operations. If an intermediate is compromised, only its certificates need to be revoked — the root remains trusted.

End-entity certificates are the certificates presented by servers, clients, or individuals. They cannot sign other certificates.

Certificate Validation

When a client receives a certificate, it validates the entire chain:

1. Verify the signature — Check that each certificate's signature is valid using the issuer's public key
2. Check the chain — Follow the chain from the end-entity certificate up to a trusted root CA
3. Check validity dates — Ensure the current date is within the certificate's validity period
4. Check revocation — Verify the certificate has not been revoked (via CRL or OCSP)
5. Check the hostname — Verify the certificate's Subject Alternative Name (SAN) matches the hostname you are connecting to

# View a certificate's details
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -text -noout

# Verify a certificate chain
openssl verify -CAfile root-ca.pem -untrusted intermediate.pem server-cert.pem

Where It Fits

PKI is the trust infrastructure that makes TLS, code signing, email encryption (S/MIME), and document signing possible. Study Asymmetric Encryption first to understand the key pairs that certificates bind to identities, then move to the TLS Handshake to see how certificates are used in practice.

PKI and Digital Certificates: Practice

PKI is best understood by building a small certificate authority and issuing certificates. The exercises below walk through creating a root CA, an intermediate CA, and end-entity certificates.

Exercise 1: Create a Root CA

# Generate the root CA private key (keep this offline!)
openssl genrsa -out root-ca.key 4096

# Create the root CA self-signed certificate
openssl req -new -x509 -key root-ca.key -sha256 -days 3650 \
  -out root-ca.pem \
  -subj "/C=US/ST=State/L=City/O=MyOrg/CN=My Root CA"

# View the certificate
openssl x509 -in root-ca.pem -text -noout | head -20

The root CA certificate is self-signed — the issuer and subject are the same. This is the trust anchor.

Exercise 2: Create an Intermediate CA

# Generate the intermediate CA private key
openssl genrsa -out intermediate.key 4096

# Create a Certificate Signing Request (CSR)
openssl req -new -key intermediate.key \
  -out intermediate.csr \
  -subj "/C=US/ST=State/L=City/O=MyOrg/CN=My Intermediate CA"

# Sign the CSR with the root CA to create the intermediate certificate
openssl x509 -req -in intermediate.csr -CA root-ca.pem \
  -CAkey root-ca.key -CAcreateserial -days 1825 \
  -sha256 -out intermediate.pem \
  -extfile <(echo "basicConstraints=CA:TRUE")

The basicConstraints=CA:TRUE extension marks this certificate as a CA certificate, allowing it to sign other certificates.

Exercise 3: Issue a Server Certificate

# Generate the server private key
openssl genrsa -out server.key 2048

# Create a CSR with the server's hostname
openssl req -new -key server.key \
  -out server.csr \
  -subj "/C=US/ST=State/L=City/O=MyOrg/CN=www.example.com"

# Sign with the intermediate CA, including SAN extension
openssl x509 -req -in server.csr -CA intermediate.pem \
  -CAkey intermediate.key -CAcreateserial -days 365 \
  -sha256 -out server.pem \
  -extfile <(echo "subjectAltName=DNS:www.example.com,DNS:example.com")

# Verify the full chain
openssl verify -CAfile root-ca.pem -untrusted intermediate.pem server.pem

Exercise 4: Check Certificate Revocation with OCSP

# Query an OCSP responder
openssl ocsp -issuer intermediate.pem -cert server.pem \
  -url http://ocsp.example.com -resp_text

OCSP (Online Certificate Status Protocol) provides real-time revocation status. An alternative is CRL (Certificate Revocation List), which is a periodically updated list of revoked certificate serial numbers.

Check Your Understanding

• Why are root CAs kept offline?
• What is the purpose of an intermediate CA?
• What happens if a certificate's private key is compromised?

PKI and Digital Certificates: Trade-offs and Interviews

PKI is the foundation of trust on the internet, but it is also one of the most complex and failure-prone security systems. Understanding its limitations is essential for both operating and securing PKI.

When PKI Is the Wrong Tool

• Internal-only services: For services that are never exposed to the internet, a private PKI adds complexity without proportional benefit. Use shared secrets or SSH key-based authentication instead.
• Short-lived credentials: For ephemeral workloads (containers, serverless functions), the overhead of certificate issuance and renewal may exceed the security benefit. Use short-lived tokens (OAuth, SPIFFE) instead.
• Small teams: Operating a private PKI requires expertise and ongoing maintenance. For small teams, Let's Encrypt (free, automated certificates) or cloud provider certificate managers are better options.

Common PKI Failures

• Expired certificates: The most common PKI failure. An expired certificate causes service outages and security warnings. Implement automated renewal (ACME protocol, cert-manager).
• Weak key algorithms: Certificates signed with RSA-1024 or SHA-1 are no longer trusted. Ensure all certificates use RSA-2048+ or ECC-256+ and SHA-256+.
• Misconfigured SANs: If the certificate's Subject Alternative Name does not match the hostname, clients will reject it. Always include all hostnames the certificate will be used for.
• Compromised CA: If a CA's private key is compromised, every certificate it issued must be revoked. This is why root CAs are kept offline and intermediates are used for daily operations.

Let's Encrypt and Automated PKI

Let's Encrypt provides free, automated domain-validated certificates using the ACME protocol. This has dramatically reduced the cost and complexity of TLS:

# Obtain a certificate with certbot
certbot certonly --standalone -d www.example.com -d example.com

# Certbot automatically renews via a cron job or systemd timer
certbot renew --dry-run

Let's Encrypt certificates are valid for 90 days, which encourages automation. The short validity period limits the damage from a compromised key.

How This Comes Up in Interviews

• "How does a client verify a server's certificate?" The client checks the certificate chain from the end-entity certificate up to a trusted root CA, verifies each signature, checks validity dates, checks revocation status (CRL/OCSP), and verifies the hostname matches the SAN.
• "What happens if a CA's private key is compromised?" Every certificate issued by that CA (and its intermediates) must be revoked. This is why root CAs are kept offline and why intermediate CAs limit the blast radius.
• "How do you handle certificate renewal in production?" Use automated tools like certbot with the ACME protocol, or a certificate manager like cert-manager in Kubernetes. Never rely on manual renewal — expired certificates cause outages.