PKI (Public Key Infrastructure)

PKI (Public Key Infrastructure) is a system for managing digital identities based on asymmetric cryptography. It solves the fundamental problem of establishing trust across a distributed network: How can Alice ensure that the public key she possesses truly belongs to Bob—and not to an attacker?

The Trust Problem and the PKI Solution

Without PKI, the "man-in-the-middle" problem arises during key exchange: An attacker could pass off their own public key as "Bob’s key."

PKI solves this through a trust hierarchy: A trusted third party (Certificate Authority, CA) cryptographically confirms the link between a public key and an identity.

Root CA (Trust Anchor)
    ↓ signed
Intermediate CA
    ↓ signed
End-Entity Certificate (for server, person, device)

The operating system and browsers contain lists of trusted Root CAs (approx. 150 worldwide).

PKI Components

Certificate Authority (CA): Issues, signs, and revokes certificates. Divided into:

• Public CA: Commercial (DigiCert, Sectigo) or non-profit (Let's Encrypt) – for publicly accessible servers
• Private/Enterprise CA: Internal CA for corporate devices, VPN clients, intranets (e.g., Microsoft AD CS, HashiCorp Vault)

Registration Authority (RA): Verifies the applicant’s identity before issuing a certificate. Can be operated separately from the CA.

Certificate Repository: Publicly accessible storage for issued certificates (LDAP, HTTP).

CRL (Certificate Revocation List) / OCSP: Mechanisms for verifying whether a certificate is still valid (certificates revoked before expiration).

Certificate Types

TLS/SSL Certificates (Server Authentication):

• Domain Validation (DV): Only domain ownership verified (Let's Encrypt, fast, free)
• Organization Validation (OV): Company identity verified (for corporate websites)
• Extended Validation (EV): Extensive verification, formerly indicated by a green address bar (less relevant today)
• Wildcard Certificate: Applies to *.example.com—all subdomains

Client Certificates: Authenticate users or devices to servers. Use cases:

• Password-less VPN authentication
• Web application access (instead of username/password)
• S/MIME (email encryption and signing)

Code Signing Certificates: Software vendors sign their executables. Windows and macOS verify this signature at startup.

Document Signing: Digital signatures on PDFs, contracts (e.g., Adobe Acrobat compatible).

PKI in an Enterprise Context (Private PKI)

Companies often operate their own Certificate Authorities for:

Device Certificates (Machine Identity): Every corporate device receives a unique certificate → enables conditional access ("Only managed devices with a valid certificate are granted access").

802.1X Wi-Fi Authentication: No more pre-shared keys—each device authenticates to the Wi-Fi network via a certificate. No password that can be shared.

VPN (IPsec/TLS-based): Mutual certificate authentication (Mutual TLS) instead of passwords.

Email encryption (S/MIME): Employees receive certificates for encrypted and signed emails.

PKI Security Risks

CA Compromise: An attack on a public CA (DigiNotar 2011, Comodo 2011) can have global repercussions. Attackers can then issue any valid certificates.

Key Compromise: Private key of a certificate stolen → Certificate must be revoked immediately (CRL/OCSP).

Expiration Monitoring: Expired certificates cause outages (production incidents in large enterprises are common). Certificate lifecycle management is critical.

Incorrectly issued certificates: CAs can make mistakes. Certificate Transparency (CT) logs enable public verification of all issued certificates.

Private PKI risks:

• Weak root CA key material
• No HSM (Hardware Security Module) for CA keys
• No automatic revocation in case of device theft

PKI and Zero Trust

In Zero Trust architectures, PKI is a fundamental trust instrument:

• Device identity: Client certificates as device identity for conditional access
• Service identity: Mutual TLS (mTLS) between microservices (no implicit network trust)
• SPIFFE/SPIRE: Workload identities in Kubernetes via PKI

# Display certificate information
openssl x509 -in cert.pem -text -noout

# Validate certificate chain
openssl verify -CAfile chain.pem cert.pem

# Check OCSP status
openssl ocsp -issuer issuer.pem -cert cert.pem -url http://ocsp.example.com

BSI Recommendations

The BSI recommends the following in its Technical Guidelines (TR-02102):

• RSA keys: at least 3072 bits (until 2028), then 4096 bits
• ECC keys: P-256 or P-384 (NIST curves)
• Certificate validity: max. 1 year for TLS server certificates (industry trend: 90 days, Let's Encrypt: 47 days)
• CA keys: storage in hardware security modules (HSM)