PKI Core Components and Architecture

TL;DR

PKI (Public Key Infrastructure) uses digital certificates and public-key cryptography to securely identify users and devices. It relies on trusted third parties called Certificate Authorities (CAs) to issue and manage these digital identities. Understanding PKI's main parts helps you secure communications and data exchange.

1. The Mental Model

Think of PKI like a digital passport system for the internet. A trusted agency (CA) issues passports (certificates) that prove who you are. This lets everyone know who's who, making secure communication possible.

2. The Core Material

PKI gives you a way to verify identities and encrypt information using public-key cryptography. It's built on a few key components that work together to establish trust.

Digital Certificates

A digital certificate is like an electronic ID card. It securely binds a public key to an individual, organization, or device. It contains:
* Subject's Public Key: The key used for encryption or signature verification.
* Subject's Identity Information: Who the certificate belongs to (e.g., name, organization).
* Issuer's Identity Information: Who issued the certificate (the CA).
* Validity Period: When the certificate is valid from and to.
* Digital Signature of the Issuer: The CA's signature, proving they issued and haven't tampered with the certificate.
* Serial Number: A unique identifier for the certificate.

Certificate Authorities (CAs)

A Certificate Authority (CA) is the trusted entity that issues digital certificates. They verify the identity of the certificate requester and then digitally sign the certificate. This signature makes the certificate trustworthy. There are different types:
* Root CA: The top CA in a hierarchy; its certificate is self-signed and establishes the ultimate trust anchor. Your operating system and browsers usually have a list of pre-trusted root CAs.
* Intermediate CA: CAs that issue certificates on behalf of a Root CA. They help distribute the workload and add an extra layer of security, as the Root CA can remain offline.

Registration Authority (RA)

A Registration Authority (RA) acts as an intermediary between the end-entity (you, a server, etc.) and the CA. The RA verifies your identity before sending your request to the CA for certificate issuance. They don't sign certificates themselves.

Certificate Revocation List (CRL) and Online Certificate Status Protocol (OCSP)

Sometimes a certificate needs to be invalidated before its expiration date (e.g., the private key was compromised).
* CRL: A Certificate Revocation List is a list of serial numbers for certificates that have been revoked by the CA. Browsers and applications periodically download and check these lists.
* OCSP: The Online Certificate Status Protocol is a more real-time way to check a certificate's status. Instead of downloading a whole list, your application queries an OCSP responder to see if a specific certificate is still valid.

Certificate Storage and Management

Managing certificates involves storing private keys securely, distributing public certificates, and handling renewals and revocations. This is often done using:
* Hardware Security Modules (HSMs): Dedicated physical devices that protect cryptographic keys and perform crypto operations.
* Key Management Systems (KMS): Software solutions for generating, storing, managing, and backing up cryptographic keys.

Here's how these components interact:

graph TD
    A["End User/Server"] --> B{{"Requests Certificate"}};
    B --> C["Registration Authority (RA)"];
    C --> D{{"Verifies Identity"}};
    D --> E["Certificate Authority (CA)"];
    E --> F{{"Issues & Signs Certificate"}};
    F --> G["Certificate Store (e.g., Browser/OS)"];
    E --> H["Certificate Revocation List (CRL) Repository"];
    E --> I["OCSP Responder"];
    G --> J{{"Trusts CA's Signature"}};
    J --> K["Valid Certificate Used for Secure Communication"];
    K --> H;
    K --> I;
    I --> L{{"Queries Certificate Status"}};
    L --> K;

3. Worked Example

Let's say you're setting up an e-commerce website, secure-shop.com, and you want users to trust your site.

1. Request: You generate a Certificate Signing Request (CSR) on your web server. This CSR contains your public key and details like secure-shop.com, your organization name, and country.
2. Submit to RA/CA: You send this CSR to a commercial CA (e.g., Let's Encrypt, DigiCert, GlobalSign). If you're using a large CA, an RA might handle the initial identity verification.
3. Verification: The CA (or RA) verifies that you actually own secure-shop.com. This could involve domain-name verification (e.g., placing a specific file on your web server) or more extensive business validation for higher-assurance certificates.
4. Issuance: Once verified, the CA creates a digital certificate for secure-shop.com that includes your public key, validity dates, subject details, and the CA's own digital signature.
5. Installation: You install this certificate and its corresponding private key on your web server.
6. Trust: When a user visits https://secure-shop.com, your server sends them the certificate. Their browser, which trusts the CA that signed your certificate (because the CA's root certificate is pre-installed in the browser), verifies the signature. If valid, the browser establishes a secure connection, indicating trust (e.g., a padlock icon).
7. Revocation Check (if needed): If your private key were ever compromised, you'd inform the CA, and they'd add your certificate's serial number to their CRL and OCSP responder. Browsers would then see your certificate as revoked and warn users.

4. Key Takeaways

• Digital certificates bind public keys to identities, making trust possible in digital interactions.
• Certificate Authorities (CAs) are the trusted third parties that issue and digitally sign certificates.
• Registration Authorities (RAs) handle initial identity verification before a CA issues a certificate.
• CRLs and OCSP provide mechanisms to check if a certificate is still valid or has been revoked.
• Key security often relies on Hardware Security Modules (HSMs) or Key Management Systems (KMS).

Common Mistakes to Avoid:
- Ignoring Certificate Expiration: Certificates have a lifespan; always plan for timely renewal.
- Compromising Private Keys: Your private key is crucial; never share it or store it insecurely.
- Trusting Untrusted CAs: Browsers/OSes have trusted root CAs; don't install certificates from unknown sources.
- Not Managing Revocation: Failing to revoke compromised certificates leaves a security hole.

5. Now Try It

Install a free SSL certificate (like from Let's Encrypt) on a test web server (you can use a virtual machine or a free cloud tier). Pay close attention to the steps involved in generating the Certificate Signing Request (CSR) and how the CA verifies your domain ownership.

What to do:
1. Set up a basic web server (e.g., Apache or Nginx) on a Linux VM.
2. Follow a tutorial to obtain and install a Let's Encrypt certificate for a temporary domain name you own or can register for testing.
3. Observe the certificate files created (e.g., fullchain.pem, privkey.pem).

What success looks like:
You can access your test website via https:// in a browser, and the browser shows a secure connection (the padlock icon), indicating the certificate is valid and trusted.