PKI and Certificate Management Lab

What Is a Public Key Infrastructure?

A Public Key Infrastructure (PKI) is the framework of policies, hardware, software, and procedures that creates, manages, distributes, stores, and revokes digital certificates. At its core, PKI lets two parties who have never met verify each other's identities using cryptography. When you visit a website secured with HTTPS, PKI is working behind the scenes to guarantee that the server is who it claims to be and that your connection is encrypted.

The central component of PKI is the Certificate Authority (CA). A CA is a trusted entity that signs digital certificates, vouching for the identity of the certificate holder. Browsers and operating systems ship with a built-in list of trusted root CAs. Any certificate signed by one of those root CAs — directly or through an intermediate CA — is automatically trusted.

How Certificates Are Issued: The CSR Workflow

Issuing a certificate follows a defined sequence:

1. Generate a private key. The server owner creates an asymmetric key pair. The private key never leaves the server.

2. Create a Certificate Signing Request (CSR). A CSR is a file containing the server's public key plus identifying information: Common Name (CN), Organization (O), Organizational Unit (OU), Country (C), and the Subject Alternative Names (SANs) for modern certificates. The private key signs the CSR so the CA can confirm the requester controls it.

3. Submit the CSR to the CA. The CA verifies the identity claims, then signs the CSR with its own private key, producing a signed certificate (typically a `.crt` or `.pem` file).

4. Install the certificate. The signed certificate and, if needed, any intermediate CA certificates are installed on the web server alongside the private key.

5. Verify the chain. A client browser traces the certificate's issuer back to a trusted root CA. Every link in that chain must be valid.

Key Certificate Fields

When you inspect a certificate in a browser, you will see these important fields:

• Subject: Identifies the entity the certificate was issued to (e.g., CN=lab.example.com).
• Issuer: Identifies the CA that signed the certificate.
• Validity Period: The Not Before and Not After dates. Outside this window, the certificate is rejected.
• Public Key: The algorithm and key (e.g., RSA 2048-bit or ECDSA 256-bit).
• Key Usage / Extended Key Usage (EKU): Extensions that restrict how the certificate may be used. A TLS server certificate typically shows "Digital Signature" and "Key Encipherment" under Key Usage, and "Server Authentication" under EKU.
• Subject Alternative Names (SAN): The hostnames and IP addresses the certificate is valid for. Modern browsers require SANs; the Common Name alone is no longer sufficient.
• Serial Number: A unique number assigned by the CA for tracking and revocation purposes.
• Signature Algorithm: The algorithm the CA used to sign the certificate (e.g., SHA-256 with RSA).

Trust Chains and Why They Matter

A trust chain (certificate chain) runs from the server's end-entity certificate up through one or more intermediate CAs to a root CA. Browsers trust the root CA and therefore trust anything it has signed — directly or indirectly. If any certificate in the chain is missing, expired, or signed by an untrusted CA, the browser displays a warning and blocks or alerts the user.

A self-signed certificate is signed by the same entity that issued it rather than by a recognized CA. Self-signed certificates are acceptable in closed lab environments, but a real user encountering one in a browser should treat it with suspicion: there is no independent verification of the server's identity.

An expired certificate means the current date is past the Not After date. This is a configuration failure, not an attack on its own, but it signals that the operator may not be maintaining security controls. A real user should not proceed; instead, they should report the issue to the website owner or their IT department and avoid submitting sensitive data.

Using OpenSSL for PKI Tasks

OpenSSL is the standard command-line tool for PKI operations on Linux. Common commands you will use in this lab:

• Generate a 2048-bit RSA private key: `openssl genrsa -out server.key 2048`
• Create a CSR from that key: `openssl req -new -key server.key -out server.csr`
• Sign a CSR with a CA (lab CA workflow): handled by easy-rsa or a simple `openssl ca` command configured by your instructor.
• Verify a certificate's details: `openssl x509 -in server.crt -text -noout`
• Test a live TLS connection: `openssl s_client -connect lab.example.com:443`

Lab Safety and Best Practices

This lab uses isolated virtual machines. Keep all generated private keys inside the lab environment — do not export them to personal devices or public repositories. Treat private keys like passwords: anyone who possesses a private key can impersonate that server. Use strong passphrases on any key you protect with one. Delete lab CA keys and certificates at the end of the exercise so they cannot be misused outside the controlled environment. Work only on systems you are authorized to configure; never apply lab CA configurations to production or shared infrastructure.