Public Key Infrastructure (PKI) and Certificates

At its core, Public Key Infrastructure uses asymmetric cryptography to securely exchange data and authenticate identities. Instead of a single password used by both sides, a Public Key Infrastructure uses a mathematically related key pair consisting of a public key and a private key.

The genius of this system lies in its asymmetry. A public key is distributed freely to anyone who wishes to encrypt a message for the key owner. You can post it on a billboard, email it to strangers, or broadcast it in cleartext. However, a private key must be kept secret by the owner to decrypt messages encrypted with the corresponding public key.

The Core Assumption of PKI Public Key Infrastructure relies on the mathematical difficulty of deriving a private key from the corresponding public key. While they are connected by complex algorithms (like RSA or Elliptic Curve), working backward from the public padlock to forge the private key is computationally infeasible.

This asymmetry also works in reverse to prove identity, a process known as digital signing. Digital signatures use the sender's private key to encrypt a cryptographic hash of a message. When the recipient receives the message, they do not need a secret password to verify who sent it. A recipient verifies a digital signature using the sender's public key. If the sender's public key successfully decrypts the hash, it proves mathematically that the message could only have been signed by the holder of the corresponding private key.

Source: Private key signing by https://Reinwaldbrian49@gmail.com FlippyFlink, CC BY-SA 4.0.

Keys alone are just strings of numbers. If I hand you a public key and claim to be your bank, how do you know I am not an imposter? We must bind that mathematical key to a real-world identity.

This is where the digital certificate comes in. A digital certificate is an electronic document that cryptographically binds a public key to an entity's identity. Think of it as a digital passport. Just as a physical passport follows international standards, the X.509 standard defines the standard format and required fields for digital certificates within a Public Key Infrastructure.

Furthermore, no passport is valid forever. An expiration date is included in every digital certificate to specify the exact time after which the certificate is mathematically no longer considered valid. This limits the exposure window if a private key is ever compromised.

The Application Process: CSRs

When you need a new certificate for your web server, you don't generate the keys and just announce yourself to the world. You generate the key pair locally, keeping the private key tightly secured. Then, you create a Certificate Signing Request (CSR).

A Certificate Signing Request is a specially formatted message sent from an applicant to a Certificate Authority to apply for a digital certificate. It fundamentally contains two things: a Certificate Signing Request contains the public key of the applicant and the applicant's identifying information.

Source: PublicKeyCertificateDiagram It by Giaros, CC BY-SA 3.0.

For digital certificates to work, they must be signed by an entity that both the sender and the recipient trust.

A Certificate Authority (CA) is a trusted third party that issues, manages, and revokes digital certificates. If the certificate is a passport, the CA is the government passport office.

However, CAs handle massive volume. To streamline operations, they often offload the vetting process to a Registration Authority (RA). A Registration Authority verifies the identity of a user requesting a digital certificate before the certificate is issued. They do the legwork of checking your credentials, but it is vital to remember a key limitation: A Registration Authority does not issue digital certificates. They simply tell the CA, "I have vetted this entity; you may sign their CSR."

Trust Models

How do we organize these authorities? A trust model establishes the hierarchical structure and relationships for verifying digital certificates within a Public Key Infrastructure.

• Hierarchical Trust Model: This is the standard of the modern internet. A hierarchical trust model uses a single Root Certificate Authority that delegates trust downwards to Intermediate Certificate Authorities.

• Root CA: A Root Certificate Authority represents the highest level of trust in a hierarchical Public Key Infrastructure. Because the Root CA is the ultimate anchor of trust, its private key is the most valuable target for an attacker. Therefore, an offline Root Certificate Authority is disconnected from the network to protect the highly sensitive root private key from network-based compromises. It is only brought online in a physically secure room to sign the certificates of intermediate CAs.

• Intermediate CAs: These are the workhorses of the PKI. Intermediate Certificate Authorities are authorized by a Root Certificate Authority to issue certificates to end-entities (like web servers or users).

  

  Source: Chain of trust v2 by Fanyangxi, CC BY-SA 4.0.

• Web of Trust: Not all models are hierarchical. A web of trust model relies on users directly signing the public keys of other users instead of using a central Certificate Authority. This is commonly used in PGP (Pretty Good Privacy) for encrypting emails, where trust is crowdsourced rather than dictated from the top down.

  

  Source: Web of Trust-en by Kku, CC BY-SA 4.0.

When a CA issues a certificate, it can validate the applicant to varying degrees. As a cybersecurity professional, you must choose the right validation level for your organization's needs.

• Domain Validation (DV): A Domain Validation (DV) certificate requires the applicant to prove administrative control over the registered domain name (usually by adding a specific DNS record or clicking an email link). It proves you own the domain, but nothing about who you actually are.
• Organization Validation (OV): An Organization Validation (OV) certificate requires the Certificate Authority to verify the legal existence of the organization requesting the certificate. This involves checking public registries to ensure the company is legitimate.
• Extended Validation (EV): An Extended Validation (EV) certificate requires the highest level of strict background checks by the Certificate Authority before issuance. This is the gold standard for financial institutions.

Certificates also come in different scopes to cover varying infrastructure needs:

• Wildcard Certificates: A wildcard certificate is used to secure a primary domain and an unlimited number of its subdomains (e.g., *.yourdomain.com) using a single certificate.

  

  Source: Let’s Encrypt example certificate on Firefox 94 screenshot by Software: Mozilla Foundation and Screenshot: VulcanSphere, MPL 2.

• Subject Alternative Name (SAN) Certificates: A Subject Alternative Name (SAN) Certificates secures multiple distinctly different domain names (e.g., domain.com, another-domain.net, and third-site.org) under a single digital certificate.

  

  Source: Subject Alt Names on Firefox 90 screenshot by Software: Mozilla Foundation and contributors Screenshot: VulcanSphere, MPL 2.

• Self-Signed Certificates: A self-signed certificate is a digital certificate signed by the exact same entity whose identity the certificate asserts. Because there is no trusted third-party CA vouching for them, self-signed certificates trigger security warnings because they are not trusted by default in web browsers. They are strictly for internal testing.

Specialized End-Entity Certificates

Beyond web servers, PKI secures users, devices, and software:

• Machine certificates are assigned to specific computers or hardware devices to authenticate the device to a network (like a corporate Wi-Fi or VPN).
• User certificates are assigned to individual people to authenticate identity, encrypt email, or digitally sign documents.
• Code signing certificates are used by software developers to digitally sign applications, installers, and scripts. A code signing certificate verifies the software author's identity and ensures the underlying code has not been tampered with since being signed.

What happens if an administrator's laptop is stolen, or a web server is hacked and the private key is stolen? The certificate hasn't reached its expiration date, but it can no longer be trusted. We must revoke it.

Historically, CAs maintained a Certificate Revocation List (CRL), which is a published roster of digital certificates that have been revoked before their expiration date. However, downloading massive lists constantly is inefficient for browsers.

To solve this, the Online Certificate Status Protocol (OCSP) was created. OCSP allows clients to query a Certificate Authority regarding the revocation status of a specific digital certificate in real time.

But imagine millions of browsers hitting a CA's OCSP server simultaneously—the CA would crumble under the traffic. The elegant solution is OCSP stapling. OCSP stapling allows a web server to provide the client with a time-stamped, digitally signed OCSP response during the initial TLS handshake. The web server queries the CA periodically, "staples" the CA's signed "all clear" message to its own certificate, and hands it to the browser. Because the server does the querying, OCSP stapling reduces the processing load on the Certificate Authority's OCSP responders.

Managing private keys at an enterprise scale introduces unique risks. If an employee encrypts vital company files using their user certificate and then leaves the company or loses their smart card, that data is permanently lost unless you have a backup plan.

Key escrow involves securely storing a backup copy of a private key with a trusted third party. In a corporate environment, this is often an internal enterprise CA. Ultimately, key escrow allows an organization or law enforcement agency to recover encrypted data if the original private key is lost or unavailable.

Another advanced defense mechanism is Certificate pinning. Standard browsers trust hundreds of CAs. If an attacker compromises just one obscure CA, they can issue a fraudulent certificate for your domain and execute a Man-in-the-Middle (MITM) attack. Certificate pinning forces a client application to trust only a specific certificate or specific public key for a designated host. By hardcoding the expected public key into a mobile app, for example, certificate pinning mitigates man-in-the-middle attacks by preventing attackers from using fraudulent certificates issued by compromised Certificate Authorities.

Source: Man in the middle attack by Miraceti, CC BY-SA 3.0.

In your daily work, you will interact with digital certificates as files. Depending on the operating system (Linux vs. Windows) or the web server (Apache vs. IIS), you will need to handle different file formats. Understanding these formats is critical for baseline security administration.

Understanding PKI is not just about memorizing acronyms; it is about grasping how mathematical asymmetry creates a chain of trust in a fundamentally untrustworthy world. From the offline Root CA sleeping in a vault to the momentary OCSP staple passing between a web server and a browser, every component works together to verify reality in the digital realm.