PKI: Public Key Infrastructure

Public Key Infrastructure (PKI)

Public Key Infrastructure (PKI) is the framework of policies, hardware, software, and procedures that enables secure electronic communication through the use of public and private cryptographic keys. It is the technology that underpins HTTPS, digital signatures, email encryption, code signing, and most other forms of secure digital communication. Without PKI, the modern internet as we know it would not exist, because there would be no trusted way to verify identities or encrypt communications between parties who have never met.

PKI solves a fundamental problem in cryptography: how do you trust that a public key actually belongs to the person or organization you think it does? A public key alone is just a number. Anyone can generate a key pair and claim to be anyone else. PKI provides the trust framework that binds identities to public keys through the use of digital certificates and Certificate Authorities (CAs). To understand PKI properly, it is helpful to be familiar with symmetric and asymmetric encryption, SSL/TLS protocols, and SSL certificates.

What Is PKI

Public Key Infrastructure is the combination of technologies, policies, and standards used to manage digital certificates and public-key encryption. It enables secure communication by providing mechanisms for generating, distributing, storing, and revoking digital certificates, which bind a public key to a verified identity. PKI also provides the infrastructure for verifying that a certificate is valid and has not been revoked.

Think of PKI as the equivalent of a government-issued passport or driver's license. A passport proves your identity because a trusted authority, the government, issued it after verifying your identity. Similarly, a digital certificate proves the identity of a website or organization because a trusted Certificate Authority issued it after performing verification. When you visit a website with HTTPS, your browser checks the site's certificate and confirms that it was issued by a trusted CA, which tells you that you are actually connected to the real website and not an imposter.

Certificate Authority (CA) → Digital Certificate → Identity Trust

Example:
Let's Encrypt (CA) → Issues certificate for example.com → Browser trusts example.com

Result: Your browser knows it is talking to the real example.com, not a fake.

Why PKI Matters

PKI is the foundation of trust on the internet. Without it, every secure online interaction would be vulnerable to impersonation, eavesdropping, and man-in-the-middle attacks.

• Authentication: PKI verifies the identity of websites, servers, users, and devices through digital certificates.
• Encryption: PKI enables secure key exchange for symmetric encryption, protecting data in transit from eavesdropping.
• Integrity: Digital signatures created with private keys allow recipients to verify that data has not been altered in transit.
• Non-repudiation: Digitally signed transactions can be proven to have originated from a specific party, preventing denial of actions.
• Scalability: PKI allows secure communication between parties who have never communicated before without pre-sharing secrets.
• Compliance: Regulations like GDPR, HIPAA, and PCI-DSS require PKI for encryption and authentication in many contexts.

Core Components of PKI

PKI consists of several distinct components that work together to create a complete trust framework. Each component plays a specific role in the lifecycle of digital certificates.

Certificate Authority (CA)

A Certificate Authority is a trusted third-party organization that issues, manages, and revokes digital certificates. The CA verifies the identity of certificate applicants before issuing certificates, and its own public key is embedded in operating systems and browsers as a trusted root. Examples include Let's Encrypt, DigiCert, GlobalSign, and IdenTrust. The CA's root certificate is the ultimate source of trust in the PKI hierarchy.

Registration Authority (RA)

A Registration Authority is responsible for verifying the identity of entities requesting certificates. The RA performs the identity checks and then informs the CA to issue the certificate. This separation of duties allows the CA to focus on certificate issuance while the RA handles the verification workflow.

Certificate Revocation List (CRL)

A Certificate Revocation List is a list of digital certificates that have been revoked by the CA before their scheduled expiration date. Certificates are revoked when the associated private key is compromised, the certificate holder no longer controls the domain or device, or the certificate was issued in error. Browsers check CRLs periodically to determine whether a certificate they are validating has been revoked.

Online Certificate Status Protocol (OCSP)

OCSP is an alternative to CRLs for checking certificate revocation status in real time. Instead of downloading a potentially large list of revoked certificates, an OCSP client sends a query to an OCSP responder asking specifically about one certificate, and the responder returns a signed response indicating whether that certificate is valid, revoked, or unknown. OCSP is more efficient than CRLs but adds latency to the connection establishment process.

Certificate Repository

A certificate repository is a publicly accessible storage location where CAs publish issued certificates and CRLs. This allows relying parties to retrieve certificates and check revocation status. The repository is typically accessible via HTTP or LDAP.

Certificate Authority (CA)
        │
        ├── Issues certificates
        ├── Maintains Certificate Revocation Lists (CRL)
        ├── Operates OCSP responders
        │
        └── Registration Authority (RA) → Performs identity verification

Trusted Root CA → Intermediate CA → End-entity Certificate

Digital Certificates (X.509)

A digital certificate is an electronic document that binds a public key to an identity. The most common certificate format is X.509, which is used in TLS/SSL for websites. An X.509 certificate contains specific fields that provide information about the certificate holder and the CA that issued it.

Version: 3
Serial Number: 3c:4a:2f:...
Signature Algorithm: sha256RSA
Issuer: CN=Let's Encrypt, O=Internet Security Research Group
Validity:
    Not Before: 2024-01-15 00:00:00 UTC
    Not After: 2024-04-15 23:59:59 UTC
Subject: CN=example.com
Subject Public Key Info: RSA 2048-bit
Extensions:
    Subject Alternative Names: example.com, www.example.com
    Key Usage: Digital Signature, Key Encipherment
    Extended Key Usage: Server Authentication, Client Authentication
Authority Information Access: OCSP responder URL
Certificate Revocation List Distribution Points: CRL URL
Signature: (CA's signature of the certificate)

The Issuer field identifies the CA that issued the certificate. The Subject field identifies the entity to which the certificate was issued, typically a domain name for a website certificate. The Validity period defines when the certificate is active. The Subject Alternative Names extension lists all domain names the certificate is valid for, which is essential for modern websites that may be reachable under multiple domain names. The CA's digital signature over the entire certificate allows anyone with the CA's public key to verify that the certificate has not been tampered with and was genuinely issued by that CA.

The PKI Trust Hierarchy

PKI uses a hierarchical trust model. At the top is the Root CA, whose self-signed certificate is distributed and trusted by operating systems and browsers. The Root CA issues certificates to Intermediate CAs, which in turn issue certificates to end-entities such as websites, users, or devices. This hierarchy limits risk: if an Intermediate CA is compromised, the Root CA can revoke it without needing to replace the root certificate installed on every device in the world.

Root CA (self-signed, built into browsers)
    │
    └── Intermediate CA (issued by Root CA)
            │
            └── End-entity Certificate (issued by Intermediate CA)
                    │
                    └── example.com

Verification path: Browser trusts Root CA → Root CA trusts Intermediate CA → Intermediate CA trusts example.com certificate → Connection is secure

When you connect to an HTTPS website, the server sends its end-entity certificate along with the intermediate certificates needed to chain back to a trusted root. Your browser verifies the signatures up the chain until it reaches a root certificate that is already trusted. If the chain is valid and the certificate has not expired or been revoked, the browser establishes a secure connection and displays a padlock icon.

Types of Digital Certificates

How PKI Works for HTTPS

When you visit an HTTPS website, PKI operates behind the scenes in every TLS handshake to authenticate the server and establish an encrypted channel.

1. The web server presents its digital certificate to your browser during the TLS handshake.
2. Your browser checks that the certificate is within its validity period and that the domain name you requested matches the certificate's Subject Alternative Names.
3. Your browser verifies the certificate's digital signature by following the chain of trust up to a trusted Root CA installed in your browser or operating system.
4. Your browser checks whether the certificate has been revoked by querying the CRL or OCSP responder specified in the certificate.
5. If all checks pass, your browser trusts that it is connected to the legitimate website and uses the server's public key to encrypt a session key for the remainder of the connection.
6. If any check fails, your browser displays a security warning informing you that the connection is not secure.

Client (Browser)                              Server
      │                                             │
      │─── Client Hello (supported cipher suites)──→│
      │                                             │
      │←── Server Hello (chosen cipher suite)───────│
      │←── Certificate (end-entity + intermediates)│
      │                                             │
      │─── Verify certificate chain to trusted root│
      │─── Check expiration and revocation         │
      │                                             │
      │←── Server Hello Done───────────────────────│
      │                                             │
      │─── Client Key Exchange (encrypted session key)│
      │─── Change Cipher Spec─────────────────────→│
      │─── Finished───────────────────────────────→│
      │                                             │
      │←── Change Cipher Spec───────────────────────│
      │←── Finished────────────────────────────────│
      │                                             │
      │=== Encrypted application data begins =======│

Public Key vs Private Key

PKI is built on asymmetric cryptography, which uses a mathematically linked pair of keys. The public key can be shared openly, while the private key must be kept secret. Understanding the distinct roles of each key is essential for using PKI correctly.

In TLS, the server's public key is used by the client to encrypt a random session key, which only the server can decrypt with its private key. This session key is then used for symmetric encryption of the actual application data, which is much faster than asymmetric encryption. The private key never leaves the server and is never transmitted over the network, which is why it is safe for the public key to be distributed widely.

Certificate Revocation

Certificates can become invalid before their expiration date. When this happens, they must be revoked so that relying parties know not to trust them. PKI provides two mechanisms for checking revocation status.

Certificate Revocation List (CRL)

A CRL is a list of serial numbers of revoked certificates, signed by the CA. CAs publish updated CRLs at regular intervals, typically every few days or weeks. Browsers and other clients download the CRL periodically and cache it locally. The main disadvantage of CRLs is that they can become very large, especially for CAs that have issued millions of certificates, and there is a delay between revocation and the CRL being updated and downloaded.

Online Certificate Status Protocol (OCSP)

OCSP allows a client to query the CA's OCSP responder directly to ask whether a specific certificate is valid. The responder returns a signed response indicating good, revoked, or unknown. OCSP is more efficient than CRLs because the client only downloads status for the certificate it is checking, not the entire list. However, OCSP adds latency to the connection because the client must wait for the OCSP response before completing the TLS handshake. OCSP stapling is an optimization where the server periodically fetches the OCSP response and "staples" it to the certificate during the handshake, eliminating the extra round trip.

Public Key vs Private Key

PKI is built on asymmetric cryptography, which uses a mathematically linked pair of keys. The public key can be shared openly, while the private key must be kept secret. Understanding the distinct roles of each key is essential for using PKI correctly.

Common PKI Mistakes to Avoid

• Using Self-Signed Certificates in Production: Self-signed certificates are not trusted by browsers and will generate security warnings. Use certificates from a trusted public CA for production websites.
• Allowing Private Key Exposure: If a private key is compromised, anyone can impersonate the certificate holder. Store private keys securely, restrict access, and use hardware security modules for high-value keys.
• Not Implementing Revocation Checking: Failing to check CRLs or OCSP means you will continue to trust certificates that have been revoked. Always configure revocation checking in your applications.
• Using Weak Key Lengths: RSA keys shorter than 2048 bits are considered insecure. Use RSA 2048-bit or 4096-bit, or use ECC keys which provide equivalent security with shorter key lengths.
• Ignoring Certificate Expiration: Certificates that expire cause service outages. Implement monitoring to alert before certificates expire and automate renewal where possible.
• Not Validating the Entire Chain: Only checking the end-entity certificate without verifying the chain back to a trusted root leaves you vulnerable to forged certificates.

PKI Best Practices

• Automate Certificate Renewal: Use protocols like ACME (Let's Encrypt) to automatically renew certificates before they expire, eliminating manual processes and reducing the risk of expired certificates causing outages.
• Use Short Certificate Lifetimes: Shorter validity periods, such as 90 days, reduce the impact of compromised keys and encourage automation. Let's Encrypt pioneered 90-day certificates, and many CAs now offer similar options.
• Implement Certificate Transparency Monitoring: Certificate Transparency logs record all certificates issued by participating CAs. Monitor these logs to detect unauthorized certificates issued for your domains.
• Protect Private Keys with Hardware: For high-value certificates, store private keys in Hardware Security Modules (HSMs) that prevent key extraction and provide tamper-resistant key storage.
• Use ECC for Better Performance: Elliptic Curve Cryptography (ECC) provides equivalent security to RSA with much smaller key sizes, resulting in faster handshakes and lower computational overhead.
• Regularly Audit Your Certificates: Maintain an inventory of all certificates in your environment, track expiration dates, and audit for unauthorized or expired certificates.

Frequently Asked Questions

1. What is the difference between a root CA and an intermediate CA?
   A root CA is the ultimate trust anchor. Its self-signed certificate is distributed with operating systems and browsers. An intermediate CA is issued by a root CA and issues end-entity certificates. Using intermediate CAs allows the root CA to remain offline and secure, while intermediate CAs can be replaced if compromised without requiring every device to update its root store.
2. Why do I see "Your connection is not private" errors in my browser?
   This error occurs when the browser cannot verify the website's certificate. Common causes include expired certificates, certificates issued for a different domain name, self-signed certificates, certificates from an untrusted CA, or revoked certificates. The error is a security feature that protects you from connecting to fraudulent websites.
3. What is the difference between DV, OV, and EV certificates?
   Domain Validation (DV) only verifies control over the domain name. Organization Validation (OV) verifies the domain and the organization's legal existence. Extended Validation (EV) performs the most rigorous verification, including legal, physical, and operational existence. DV certificates are sufficient for most websites. OV and EV provide additional assurance for e-commerce, banking, and other high-trust applications.
4. Can I run my own Certificate Authority?
   Yes. Many organizations run private CAs for internal use, issuing certificates to internal servers, devices, and users. However, certificates from a private CA will not be trusted by public browsers unless you install your CA's root certificate on every device that needs to trust them. For public-facing websites, you must use a publicly trusted CA.
5. What is a wildcard certificate?
   A wildcard certificate is valid for a domain and all its subdomains. The certificate's subject name includes an asterisk, such as *.example.com, which matches www.example.com, mail.example.com, and any other subdomain. Wildcard certificates simplify certificate management for organizations with many subdomains but require careful private key protection because compromise affects all subdomains.
6. What should I learn next after understanding PKI?
   After mastering PKI fundamentals, explore SSL/TLS protocols, SSL certificate management, encryption basics, and security compliance for practical implementation of PKI in your applications.

Conclusion

Public Key Infrastructure is the backbone of trust on the internet. It enables secure communication, authentication, and digital signatures by binding public keys to verified identities through digital certificates and Certificate Authorities. Without PKI, every secure online interaction would require pre-arranged secret keys, which is impossible at internet scale.

Understanding PKI is essential for anyone building or operating web applications. The core concepts are straightforward: a trusted Certificate Authority issues certificates that prove identity, those certificates contain public keys, and the corresponding private keys are kept secret by the certificate holder. Browsers verify certificates by following a chain of trust from the website's certificate up to a root CA that is built into the browser or operating system.

Modern PKI best practices include automating certificate renewal with short lifetimes, monitoring Certificate Transparency logs for unauthorized certificates, protecting private keys with hardware, and using ECC for better performance. As the web continues to evolve toward ubiquitous encryption, PKI will remain at the center of how we establish trust between parties who have never met.

To deepen your understanding, explore related topics like SSL/TLS protocols, SSL certificate management, symmetric vs asymmetric encryption, and security compliance. Together, these skills form a complete foundation for building secure, trusted systems.