CompTIA Security+ PKI Components - Zero-Fluff, Hands-On Guide

CompTIA Security+ PKI Components: Zero-Fluff, Hands-On Guide

(CA, RA, CRL, OCSP – Deploy, Troubleshoot, Secure)

1. What This Is & Why It Matters

PKI (Public Key Infrastructure) is the backbone of secure digital communication—it’s how your browser trusts https://google.com, how VPNs authenticate users, and how code signing ensures software isn’t tampered with. If PKI breaks, everything breaks: - Websites show "Your connection is not private" (ERR_CERT_AUTHORITY_INVALID). - VPNs fail to connect ("Certificate not trusted"). - Email encryption (S/MIME) stops working. - IoT devices can’t securely phone home.

Real-world scenario: You’re a sysadmin at a mid-sized company. Your CEO’s laptop suddenly can’t access internal apps because the internal CA’s certificate expired. Users see scary browser warnings, and your helpdesk is flooded. You have 30 minutes to fix it before the CEO’s big presentation.

This guide gives you the immediate, practical skills to: ? Deploy a private CA (like OpenSSL or Windows AD CS). ? Issue and revoke certificates (and know when to use CRL vs. OCSP). ? Troubleshoot PKI failures (e.g., "Why does my browser hate this cert?"). ? Pass Security+ questions about PKI components (they’re on the exam every time).

2. Core Concepts & Components

? Certificate Authority (CA)

• What it is: The trusted third party that issues and signs digital certificates (like a passport office for the internet).
• Production insight:
• Public CAs (e.g., DigiCert, Let’s Encrypt) are trusted by browsers/OSes by default.
• Private CAs (e.g., Active Directory Certificate Services, OpenSSL) are used for internal apps/devices. You must manually trust them on client machines.
• If your CA’s private key is compromised, all certificates it issued are toast. (This is why CAs use hardware security modules (HSMs) in production.)

? Registration Authority (RA)

• What it is: The middleman between users and the CA. It verifies identity (e.g., "Is this user really who they claim?") but doesn’t issue certificates.
• Production insight:
• In Active Directory, the RA is often the domain controller.
• In Let’s Encrypt, the RA is the ACME client (e.g., Certbot) that proves you control a domain.
• If the RA is compromised, attackers can request certificates for domains they don’t own.

? Certificate Revocation List (CRL)

• What it is: A blacklist of revoked certificates, published by the CA. Clients download it periodically.
• Production insight:
• CRLs are slow (clients cache them for hours/days). If you revoke a cert, it may take time to propagate.
• CRLs can get huge (e.g., a CA with 1M revoked certs). Some systems (like Windows) fail open if the CRL is unreachable (bad for security).
• Default CRL location is often hardcoded in certificates. If you move your CRL, old certs break.

? Online Certificate Status Protocol (OCSP)

• What it is: A real-time alternative to CRLs. Clients ask the CA, "Is this cert still valid?" and get an immediate answer.
• Production insight:
• OCSP is faster than CRLs but creates a privacy leak (the CA sees every site you visit).
• OCSP stapling (where the web server caches the OCSP response) fixes this.
• If the OCSP responder is down, some clients (like Firefox) fail open. Others (like Chrome) hard-fail (bad UX).

? Certificate Signing Request (CSR)

• What it is: A file (.csr) generated by a user/device, containing their public key and identity info (e.g., domain name). The CA signs it to create a certificate.
• Production insight:
• CSRs are not encrypted. Anyone can read them (but they can’t modify them without invalidating the signature).
• If you lose the private key matching a CSR, the certificate is useless.

? Certificate Formats

? Root vs. Intermediate CA

• Root CA: The top-level trust anchor. Its certificate is self-signed and pre-installed in OSes/browsers.
• Intermediate CA: Signed by the root CA. Used to limit damage if a CA is compromised.
• Production insight:
• Never use the root CA to sign end-entity certificates. It should be offline (air-gapped) and only used to sign intermediate CAs.
• If you lose the root CA’s private key, your entire PKI is dead.

3. Step-by-Step Hands-On: Deploy a Private CA with OpenSSL

Goal: Set up a private CA, issue a certificate for internal.example.com, and revoke it (then test CRL/OCSP).

Prerequisites

• A Linux VM (Ubuntu 22.04) or WSL.
• openssl installed (sudo apt install openssl).
• A domain you control (or use internal.example.com with /etc/hosts entries).

Step 1: Create a Root CA

# Create directories
mkdir -p ~/pki/{root-ca,certs,crl,newcerts,private}
cd ~/pki/root-ca
chmod 700 private

# Generate root CA private key (RSA 4096-bit)
openssl genrsa -aes256 -out private/root-ca.key.pem 4096
# Enter a strong passphrase (e.g., 20+ chars with symbols)

# Create root CA config file (root-ca.cnf)
cat > root-ca.cnf << 'EOF'
[ ca ]
default_ca = CA_default

[ CA_default ]
dir               = ~/pki/root-ca
certs             = $dir/certs
crl_dir           = $dir/crl
new_certs_dir     = $dir/newcerts
database          = $dir/index.txt
serial            = $dir/serial
RANDFILE          = $dir/private/.rand
private_key       = $dir/private/root-ca.key.pem
certificate       = $dir/certs/root-ca.cert.pem
crlnumber         = $dir/crlnumber
crl               = $dir/crl/root-ca.crl.pem
crl_extensions    = crl_ext
default_crl_days  = 30
default_md        = sha256
name_opt          = ca_default
cert_opt          = ca_default
default_days      = 3650
preserve          = no
policy            = policy_strict

[ policy_strict ]
countryName             = match
stateOrProvinceName     = match
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

[ req ]
default_bits        = 4096
distinguished_name  = req_distinguished_name
string_mask         = utf8only
default_md          = sha256
x509_extensions     = v3_ca

[ req_distinguished_name ]
countryName                     = Country Name (2 letter code)
stateOrProvinceName             = State or Province Name
localityName                    = Locality Name
0.organizationName              = Organization Name
organizationalUnitName          = Organizational Unit Name
commonName                      = Common Name
emailAddress                    = Email Address

[ v3_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ crl_ext ]
authorityKeyIdentifier=keyid:always
EOF

# Initialize CA database
touch index.txt
echo 1000 > serial
echo 1000 > crlnumber

# Generate root CA certificate (self-signed)
openssl req -config root-ca.cnf \
      -key private/root-ca.key.pem \
      -new -x509 -days 3650 -sha256 -extensions v3_ca \
      -out certs/root-ca.cert.pem
# Fill in details (Common Name = "Example Root CA")

Verify:

openssl x509 -noout -text -in certs/root-ca.cert.pem

• Check Issuer and Subject are the same (self-signed).
• Check CA:TRUE and keyCertSign in Key Usage.

Step 2: Create an Intermediate CA

# Create directories
mkdir -p ~/pki/intermediate-ca/{certs,crl,newcerts,private,csr}
cd ~/pki/intermediate-ca
chmod 700 private

# Generate intermediate CA private key
openssl genrsa -aes256 -out private/intermediate-ca.key.pem 4096

# Create intermediate CA config (intermediate-ca.cnf)
cat > intermediate-ca.cnf << 'EOF'
[ ca ]
default_ca = CA_default

[ CA_default ]
dir               = ~/pki/intermediate-ca
certs             = $dir/certs
crl_dir           = $dir/crl
new_certs_dir     = $dir/newcerts
database          = $dir/index.txt
serial            = $dir/serial
RANDFILE          = $dir/private/.rand
private_key       = $dir/private/intermediate-ca.key.pem
certificate       = $dir/certs/intermediate-ca.cert.pem
crlnumber         = $dir/crlnumber
crl               = $dir/crl/intermediate-ca.crl.pem
crl_extensions    = crl_ext
default_crl_days  = 30
default_md        = sha256
name_opt          = ca_default
cert_opt          = ca_default
default_days      = 1825
preserve          = no
policy            = policy_loose

[ policy_loose ]
countryName             = optional
stateOrProvinceName     = optional
localityName            = optional
organizationName        = optional
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

[ req ]
default_bits        = 4096
distinguished_name  = req_distinguished_name
string_mask         = utf8only
default_md          = sha256
x509_extensions     = v3_intermediate_ca

[ req_distinguished_name ]
countryName                     = Country Name (2 letter code)
stateOrProvinceName             = State or Province Name
localityName                    = Locality Name
0.organizationName              = Organization Name
organizationalUnitName          = Organizational Unit Name
commonName                      = Common Name
emailAddress                    = Email Address

[ v3_intermediate_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
EOF

# Initialize intermediate CA database
touch index.txt
echo 1000 > serial
echo 1000 > crlnumber

# Generate CSR for intermediate CA
openssl req -config intermediate-ca.cnf \
      -new -sha256 \
      -key private/intermediate-ca.key.pem \
      -out csr/intermediate-ca.csr.pem
# Common Name = "Example Intermediate CA"

# Sign the intermediate CA with the root CA
cd ~/pki/root-ca
openssl ca -config root-ca.cnf \
      -extensions v3_intermediate_ca \
      -days 1825 -notext -md sha256 \
      -in ../intermediate-ca/csr/intermediate-ca.csr.pem \
      -out ../intermediate-ca/certs/intermediate-ca.cert.pem

Verify:

openssl verify -CAfile certs/root-ca.cert.pem \
      ../intermediate-ca/certs/intermediate-ca.cert.pem

• Should output: ../intermediate-ca/certs/intermediate-ca.cert.pem: OK

Step 3: Issue a Server Certificate

# Generate private key for the server
openssl genrsa -out ~/pki/intermediate-ca/private/internal.example.com.key.pem 2048

# Create CSR
openssl req -new -sha256 \
      -key ~/pki/intermediate-ca/private/internal.example.com.key.pem \
      -out ~/pki/intermediate-ca/csr/internal.example.com.csr.pem \
      -subj "/CN=internal.example.com"

# Sign the CSR with the intermediate CA
cd ~/pki/intermediate-ca
openssl ca -config intermediate-ca.cnf \
      -extensions server_cert \
      -days 365 -notext -md sha256 \
      -in csr/internal.example.com.csr.pem \
      -out certs/internal.example.com.cert.pem

# Create a full chain (server cert + intermediate CA)
cat certs/internal.example.com.cert.pem \
    certs/intermediate-ca.cert.pem \
    > certs/internal.example.com.chain.pem

Verify:

openssl verify -CAfile ~/pki/root-ca/certs/root-ca.cert.pem \
      -untrusted certs/intermediate-ca.cert.pem \
      certs/internal.example.com.cert.pem

• Should output: certs/internal.example.com.cert.pem: OK

Step 4: Revoke a Certificate & Test CRL/OCSP

# Revoke the certificate
cd ~/pki/intermediate-ca
openssl ca -config intermediate-ca.cnf \
      -revoke certs/internal.example.com.cert.pem

# Generate CRL
openssl ca -config intermediate-ca.cnf \
      -gencrl -out crl/intermediate-ca.crl.pem

# Check the CRL
openssl crl -in crl/intermediate-ca.crl.pem -noout -text

• Look for Revoked Certificates section.

Test OCSP:

# Start an OCSP responder (in a new terminal)
openssl ocsp -index index.txt -port 8888 -rsigner certs/intermediate-ca.cert.pem \
      -rkey private/intermediate-ca.key.pem -CA certs/intermediate-ca.cert.pem \
      -text -out ocsp.log

# Query OCSP (in original terminal)
openssl ocsp -CAfile ~/pki/root-ca/certs/root-ca.cert.pem \
      -issuer certs/intermediate-ca.cert.pem \
      -cert certs/internal.example.com.cert.pem \
      -url http://127.0.0.1:8888 -text

• Should output: internal.example.com.cert.pem: revoked

4.-Production-Ready Best Practices

Security

• ? Offline Root CA: Keep the root CA air-gapped (only power it on to sign intermediate CAs).
• ? HSMs for Private Keys: Use Hardware Security Modules (e.g., YubiHSM, AWS CloudHSM) to protect CA private keys.
• ? Short-Lived Certificates: Issue certificates with <90-day lifetimes (Let’s Encrypt does 90 days).
• ? OCSP Stapling: Enable it on web servers to reduce privacy leaks and improve performance.
• ? Certificate Transparency Logs: Monitor for rogue certificates issued for your domains (e.g., crt.sh).

Reliability & Maintainability

• ? Automate Renewals: Use ACME clients (Certbot) or Kubernetes cert-manager to auto-renew certs.
• ? Centralized Logging: Log all certificate issuance/revocation events (e.g., to ELK or Splunk).
• ? Backup CA Databases: The index.txt and serial files are critical—back them up securely.
• ? Test CRL/OCSP: Regularly test that revoked certs are properly rejected.

Cost Optimization

• ? Use Let’s Encrypt for Public Certs: Free, automated, and trusted by browsers.
• ? Private CA for Internal Use: Avoid paying for public certs for internal services.
• ? Wildcard Certs: Use *.example.com to reduce certificate count (but beware of security risks if one server is compromised).

5. Common Mistakes & Traps

6.-Exam/Certification Focus (CompTIA Security+)

Typical Question Patterns

1. "Which PKI component verifies a user’s identity before requesting a certificate?"
2. ? Registration Authority (RA)

3. Certificate Authority (CA) (it issues certs, doesn’t verify identity).

4. "What’s the difference between CRL and OCSP?"

5. CRL: A list of revoked certs (downloaded periodically).

6. OCSP: A real-time query to check a single cert’s status.

7. "Why would