SSL TLS & PKI: The Complete Guide - From Zero to Hero

1. Introduction - Why Security Matters

The Problem of Secure Communication

Every time you browse the internet, you're sending and receiving data across networks you don't control. Without proper security measures, this data travels as plain text—readable by anyone who intercepts it. Think of it like sending a postcard through the mail: anyone handling it can read the message.

The Identity Problem Online

One of the fundamental challenges of the internet is identity verification. In the physical world, you can verify someone's identity through face-to-face interaction, official documents, or familiar locations. Online, none of these exist.

The critical questions are:

• How do you know you're actually talking to your bank's website?
• How can you trust that yourbank.com is really your bank and not an impersonator?
• What stops someone from creating a fake website that looks identical to a legitimate one?

Without identity verification, attackers can easily:

• Create convincing fake websites (phishing)
• Use look-alike domain names (chase-secure.com instead of chase.com)
• Exploit IDN homograph attacks (using characters from different alphabets that look identical, like chąse.com)

Man-in-the-Middle (MITM) Attacks

A Man-in-the-Middle attack occurs when an attacker secretly positions themselves between you and the server you're communicating with. The attacker can:

What an attacker can do:

• Eavesdrop: Read all unencrypted traffic, including passwords, credit card numbers, and personal information
• Modify: Change data in transit—alter account numbers, transaction amounts, or inject malicious content
• Impersonate: Pretend to be either party in the communication

Eavesdropping Threats

Eavesdropping is a passive attack where the attacker simply listens to network traffic without modifying it. This is surprisingly easy on unencrypted connections:

Tools like Wireshark can capture:

• Login credentials
• Session cookies (allowing session hijacking)
• Personal data and messages
• Credit card information
• Any data sent over HTTP

Common attack scenarios:

• Public WiFi networks (coffee shops, airports, hotels)
• Compromised routers or network equipment
• ISP-level monitoring
• Corporate network surveillance

Key Insight: On HTTP, everything you send is visible in plaintext to anyone on the network path between you and the server.

The Evolution from HTTP to HTTPS

The solution to these problems is HTTPS (HTTP Secure), which adds a security layer between HTTP and TCP.

The Three Pillars of HTTPS:

1. Confidentiality: Only the intended recipient can read the data (encryption)
2. Integrity: Data cannot be modified in transit without detection
3. Authentication: You can verify you're talking to the legitimate server

---

2. Cryptography Fundamentals

Understanding SSL/TLS requires a foundation in cryptography. Don't worry—you don't need to be a mathematician. You just need to understand the concepts.

What is Encryption?

Encryption is the process of transforming readable data (plaintext) into an unreadable format (ciphertext) using a mathematical algorithm and a key.

Decryption is the reverse process—converting ciphertext back to plaintext using the correct key.

Key components:

• Algorithm: The mathematical process (AES, RSA, ChaCha20)
• Key: Secret information that controls the transformation
• Plaintext: Original readable data
• Ciphertext: Encrypted unreadable data

Symmetric Encryption

Symmetric encryption uses ONE shared secret key for both encryption AND decryption.

How it works:

• Sender and receiver must both have the same key
• Encrypt with key K, decrypt with the same key K
• Very fast—can encrypt gigabytes per second with hardware acceleration

Common algorithms:

• AES-256 (Advanced Encryption Standard, 256-bit key)
• AES-128 (128-bit key, still secure)
• ChaCha20 (modern, efficient on devices without AES hardware)
• 3DES (deprecated, slow)

The Problem: How do you securely share the secret key with someone over an insecure network? If an attacker intercepts the key exchange, they can decrypt everything.

Speed: AES-256 can encrypt ~5 GB/s on modern CPUs
Key size: 256 bits (32 bytes)
Use case: Bulk data encryption after secure key exchange

Asymmetric Encryption

Asymmetric encryption (public-key cryptography) solves the key exchange problem by using TWO mathematically related keys:

1. Public Key: Shared freely with everyone—used to encrypt data
2. Private Key: Kept absolutely secret—used to decrypt data

The magic:

• What the public key encrypts, ONLY the private key can decrypt
• You cannot derive the private key from the public key (computationally infeasible)

Common algorithms:

• RSA (2048-bit or 4096-bit keys)
• ECDSA (Elliptic Curve, 256-bit or 384-bit)
• Ed25519 (modern, fast)

The tradeoff:

• Much slower than symmetric encryption (~1000x slower)
• Used primarily for key exchange and digital signatures, not bulk data

Encryption direction:
    Encrypt with PUBLIC key  → Only PRIVATE key can decrypt

Signing direction:
    Sign with PRIVATE key    → Anyone with PUBLIC key can verify

How Key Pairs Work Mathematically

Key pairs are based on trapdoor functions—mathematical operations that are:

• Easy to compute in one direction
• Computationally infeasible to reverse

RSA Example:

• Based on the difficulty of factoring large prime numbers
• Multiplying two 1024-bit primes is fast
• Factoring the result back into the original primes would take billions of years

Elliptic Curve Cryptography (ECC):

• Based on the discrete logarithm problem on elliptic curves
• Much smaller keys for equivalent security
• 256-bit ECC ≈ 3072-bit RSA security

Digital Signatures

A digital signature proves three things:

1. Authentication: The message was signed by the claimed sender
2. Integrity: The message hasn't been altered since signing
3. Non-repudiation: The signer cannot deny signing the document

How Digital Signatures Work - Step by Step

Creating a Digital Signature (Signing):

Verifying a Digital Signature:

Why This Works

1. Only the private key holder can create valid signatures - Even if attackers have the public key, they cannot forge signatures
2. Any modification invalidates the signature - Changing even one character produces a completely different hash
3. Public verification - Anyone with the public key can verify, but only the key holder can sign

Real-World Analogy

Think of it like a wax seal on a medieval letter:

• Only the king has the unique seal ring (private key)
• Anyone can recognize the king's seal pattern (public key)
• Breaking the seal proves tampering (integrity)
• The unique pattern proves origin (authentication)

Hash Functions

Hash functions are one-way functions that take any input and produce a fixed-size output (the "hash" or "digest").

Properties of cryptographic hash functions:

• Deterministic: Same input always produces the same hash
• One-way: Cannot reverse the hash to get the original input
• Fixed output: Any input produces a hash of the same size
• Collision resistant: Virtually impossible to find two inputs with the same hash
• Avalanche effect: Tiny change in input = completely different hash

SHA-256("Hello") = 185f8db32271fe25f561a2...
SHA-256("hello") = 2cf24dba5fb0a30e26e83b2a... ← Completely different!

Common hash algorithms:

• SHA-256 (256-bit output, most common)
• SHA-384 (384-bit output)
• SHA-512 (512-bit output)
• SHA-3 (newer standard)
• BLAKE2 (fast, modern)

Deprecated/broken:

• MD5 (broken, do not use)
• SHA-1 (collision attacks found, deprecated)

Non-Repudiation

Non-repudiation means the signer cannot deny having signed a document. This is crucial for:

• Legal contracts and agreements
• Financial transactions
• Code signing (software publishers)
• Email authentication (S/MIME)

Requirements for non-repudiation:

• Secure private key storage (only the signer has access)
• Timestamping (proves when the signature was made)
• Audit trail preservation

Important: Your private key = Your identity = Your responsibility. If your private key is compromised, someone else can sign documents as you.

---

3. Public Key Infrastructure (PKI) Overview

What is PKI?

Public Key Infrastructure (PKI) is the complete ecosystem that enables secure digital communication at scale. It's not just software—it's a framework of:

• Policies and procedures
• Hardware and software
• People and processes
• Legal frameworks

PKI's purpose:

• Create digital certificates
• Manage certificate lifecycle
• Distribute certificates securely
• Store certificates and keys
• Revoke compromised certificates

Components of PKI

Trust Models in PKI

Hierarchical Trust (Used by SSL/TLS)

• Single root of trust at the top
• Trust flows downward through the hierarchy
• If you trust the root, you trust everything it signs
• Used by: HTTPS, Code Signing, S/MIME

Web of Trust (Used by PGP/GPG)

• No central authority
• Users sign each other's keys
• Trust established through introductions
• Transitive trust: "I trust Alice, Alice trusts Bob, so I trust Bob"
• More decentralized but harder to scale

Goals of PKI

PKI exists to provide:

1. Confidentiality: Only intended recipients can read data
2. Integrity: Data hasn't been tampered with
3. Authentication: Verify identity of parties
4. Non-Repudiation: Senders can't deny sending
5. Authorization: Control access based on verified identity
6. Trust: Establish verifiable trust relationships

---

4. Certificate Authorities (CAs)

What is a Certificate Authority?

A Certificate Authority is a trusted third party that:

• Verifies the identity of certificate applicants
• Issues digital certificates binding public keys to identities
• Signs certificates with their private key (vouching for authenticity)
• Maintains revocation information
• Undergoes regular security audits

Think of CAs as the internet's "notaries"—they verify identity and provide official documentation (certificates) that others can trust.

Major public CAs:

• Let's Encrypt (free, automated)
• DigiCert
• GlobalSign
• IdenTrust
• Sectigo (formerly Comodo)
• GoDaddy

Root CAs vs Intermediate CAs

Root Certificate Authorities

• Self-signed certificates (they sign their own certificate)
• Pre-installed in browsers and operating systems
• Kept offline and air-gapped for security
• Rarely used directly to sign end-entity certificates
• Very long validity periods (20-30 years)
• Compromise would be catastrophic (entire trust chain invalidated)

Intermediate Certificate Authorities

• Signed by the Root CA
• Used for day-to-day certificate issuance
• Can be revoked if compromised (limits damage)
• Online and active
• Shorter validity periods (5-10 years)
• Multiple intermediates can exist for different purposes

Certificate Hierarchy and Chain of Trust

How validation works:

1. Browser receives server certificate + intermediate certificate(s)
2. Browser verifies intermediate's signature on server cert
3. Browser verifies root's signature on intermediate cert
4. Browser checks if root is in its trusted store
5. If chain is complete and valid → connection is trusted

Important: Servers must send the complete chain (except the root) during the TLS handshake. Missing intermediates cause validation failures.

Trusted Root Certificate Stores

Every browser and operating system maintains a root store—a list of trusted Root CA certificates.

How CAs get added:

• Must pass rigorous audits (WebTrust, ETSI)
• Public review process
• Must maintain security standards
• Regular re-auditing required

How CAs get removed:

• Security incidents (mis-issuance)
• Failed audits
• Policy violations
• Negligence

Self-Signed vs CA-Signed Certificates

Registration Authorities (RAs)

Registration Authorities act as the "front desk" for certificate requests:

• Verify applicant's identity before CA issues certificate
• Separation of duties (RA verifies, CA signs)
• Handle different validation levels:
  • Domain Validation (DV): DNS records, email, HTTP challenges
  • Organization Validation (OV): Business registration checks
  • Extended Validation (EV): Rigorous legal, physical, operational checks

Certificate Repositories

Public directories where certificates and related information are published:

• LDAP servers: Common protocol for directory access
• HTTP/HTTPS: Web-accessible repositories
• Contents: Certificates, CRLs, CA certificates, policy documents

Example repository URLs:
http://crt.sectigo.com/
http://cacerts.digicert.com/

---

5. Digital Certificates Explained

What is a Digital Certificate?

A digital certificate is essentially a digital passport that:

• Binds a public key to an identity (domain name, organization, person)
• Is signed by a trusted Certificate Authority
• Contains metadata about validity, usage, and the issuer

Analogy: Just as a passport proves your identity (issued by a trusted government), a certificate proves a server's identity (issued by a trusted CA).

The X.509 Standard

X.509 is the international standard for digital certificates, defined by the ITU-T (International Telecommunication Union).

Key facts:

• Version 3 is current (v1 and v2 are deprecated)
• Encoded in ASN.1 (Abstract Syntax Notation One)
• Used universally: SSL/TLS, S/MIME, code signing, VPNs, IPsec
• First published in 1988, current version from 2000

Purpose of Certificates

Certificates enable three critical functions:

1. Authentication: Prove the server is who it claims to be
2. Encryption: Provide the public key needed to establish encrypted communication
3. Integrity: CA's signature proves certificate hasn't been tampered with

Certificate = Public Key + Identity + CA's Signature

---

6. Certificate Anatomy & Structure

Let's dissect an X.509 certificate to understand each component.

Subject (Who)

The Subject field identifies who the certificate is issued TO.

Subject:
    CN = example.com          (Common Name - primary identifier)
    O  = Example Corporation  (Organization)
    OU = IT Department        (Organizational Unit - optional)
    L  = San Francisco        (Locality/City)
    ST = California           (State/Province)
    C  = US                   (Country - 2-letter code)

Issuer (By Whom)

The Issuer field identifies the CA that issued and signed the certificate.

Issuer:
    CN = Let's Encrypt Authority X3
    O  = Let's Encrypt
    C  = US

Serial Number

A unique identifier assigned by the CA to each certificate.

• Used for revocation (CRLs and OCSP identify certs by serial number)
• Up to 20 bytes (160 bits)
• Must be unique per CA (no two certs from same CA have same serial)
• Modern CAs use cryptographically random serials

Serial Number: 04:e7:e0:5a:23:1d:f7:e4:26:1f:c8:9e:d0:3f:aa:db:23:4c

Validity Period

Defines when the certificate is valid:

Validity
    Not Before: Jan  1 00:00:00 2024 GMT
    Not After : Apr 30 23:59:59 2024 GMT

• Not Before: Certificate is not valid before this date/time
• Not After: Certificate expires after this date/time
• Always in UTC (Coordinated Universal Time)
• Maximum validity: 398 days (13 months) since September 2020
• Let's Encrypt: 90 days (encourages automation)

Public Key Information

Contains the certificate holder's public key:

Subject Public Key Info:
    Public Key Algorithm: rsaEncryption
        RSA Public-Key: (2048 bit)
        Modulus:
            00:c2:d5:8a:... (large number)
        Exponent: 65537 (0x10001)

Common algorithms:

• RSA (2048-bit minimum, 4096-bit recommended)
• ECDSA P-256 or P-384 (smaller, faster)
• Ed25519 (modern, efficient)

Signature Algorithm

How the CA signed the certificate:

Signature Algorithm: sha256WithRSAEncryption

Components:

• Hash algorithm (SHA-256, SHA-384, SHA-512)
• Encryption algorithm (RSA, ECDSA)

Deprecated (do not use):

• MD5 (broken)
• SHA-1 (collision attacks found)

Subject Alternative Names (SANs)

Critical extension that lists ALL identities covered by the certificate:

X509v3 Subject Alternative Name:
    DNS:example.com
    DNS:www.example.com
    DNS:api.example.com
    DNS:mail.example.com
    IP Address:192.168.1.1

Important:

• Modern browsers check SANs, NOT the Common Name (CN)
• Must include the primary domain in SANs
• Can include: DNS names, IP addresses, email addresses, URIs
• Allows one cert to protect multiple domains/subdomains

Key Usage Extensions

Restricts what cryptographic operations the key can perform:

X509v3 Key Usage: critical
    Digital Signature, Key Encipherment

Extended Key Usage

Application-specific purposes:

X509v3 Extended Key Usage:
    TLS Web Server Authentication
    TLS Web Client Authentication

Certificate Fingerprint/Thumbprint

A hash of the entire certificate:

SHA-256 Fingerprint:
    A1:B2:C3:D4:E5:F6:07:18:29:3A:4B:5C:6D:7E:8F:90:
    11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00

• Not stored in the certificate—calculated by hashing it
• Used for certificate pinning
• Quick way to verify you have the correct certificate
• Use SHA-256 (SHA-1 deprecated)

Version Number

Version: 3 (0x2)

• v1: Original, basic fields only
• v2: Added issuer/subject unique IDs (rarely used)
• v3: Added extensions (current standard, required for modern use)

---

7. Types of SSL/TLS Certificates

By Validation Level

Domain Validated (DV) Certificates

Lowest level of validation—only proves you control the domain.

Validation methods:

• Email to [email protected] or similar
• DNS TXT record verification
• HTTP file challenge (/.well-known/acme-challenge/)

Characteristics:

• Issuance time: Minutes to hours (fully automated)
• Cost: Free (Let's Encrypt) to ~$50/year
• Certificate shows: Domain name only
• Best for: Blogs, personal sites, APIs, small business

90% of all SSL certificates are DV certificates

Organization Validated (OV) Certificates

Business verification—CA confirms the organization exists.

Validation process:

• Business registration verification
• Phone call to authorized representative
• Address verification

Characteristics:

• Issuance time: 1-3 business days
• Cost: $50-$300/year
• Certificate shows: Organization name in certificate details
• Best for: Corporate websites, e-commerce, business applications

Extended Validation (EV) Certificates

Highest level of validation—rigorous verification process.

Validation process:

• Legal entity verification
• Physical address verification
• Phone verification
• Operational existence check
• Corporate officer verification

Characteristics:

• Issuance time: 3-7 business days
• Cost: $150-$1000/year
• Historical: Green address bar (removed by browsers in 2019)
• Best for: Banks, payment processors, high-security sites

By Scope

Single Domain Certificates

• Covers exactly one domain (example.com)
• Simplest and cheapest option
• Cannot be used for subdomains

Wildcard Certificates

Covers all first-level subdomains of a domain:

*.example.com covers:
    blog.example.com ✓
    api.example.com ✓
    mail.example.com ✓
    dev.staging.example.com ✗ (two levels deep - NOT covered)

Characteristics:

• One level only (.example.com, not .*.example.com)
• Cost-effective for many subdomains
• Single certificate to manage
• Security risk: Compromise affects all subdomains

Multi-Domain/SAN Certificates

One certificate covering multiple unrelated domains:

One certificate covers:
    example.com
    example.org
    example.net
    totally-different-domain.com

Characteristics:

• Uses Subject Alternative Names (SANs)
• Typical limit: 100-250 domains per cert
• Pricing: Base + per-domain fee
• Best for: CDNs, cloud infrastructure, multi-tenant apps

By Purpose

Code Signing Certificates

• Sign software to prove authenticity and integrity
• Prevents tampering (modification breaks signature)
• Required for: Windows drivers, macOS apps, mobile apps
• Timestamping keeps signature valid after cert expires

Email/S-MIME Certificates

• Encrypt and digitally sign email messages
• Binds certificate to email address
• Supported by: Outlook, Apple Mail, Gmail, Thunderbird

Client Certificates

• Mutual TLS (mTLS): Both server AND client authenticate
• Much stronger than password authentication
• Use cases: VPNs, corporate intranets, IoT devices, API authentication
• Usually issued by private/internal CAs

---

8. SSL vs TLS - History & Evolution

The Confusion

We say "SSL certificate" but we actually mean "TLS certificate."

Why? SSL was the original protocol, and the name stuck even after TLS replaced it.

Protocol Timeline

SSL (Secure Sockets Layer)

DO NOT USE ANY VERSION OF SSL

TLS (Transport Layer Security)

Why TLS 1.3 is Better

Current Recommendations

• Minimum: TLS 1.2
• Preferred: TLS 1.3
• Disable: SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1

---

9. How the TLS Handshake Works

The TLS handshake establishes a secure connection before any application data is transmitted.

Overview

Purpose:

1. Negotiate TLS version and cipher suite
2. Authenticate the server (and optionally client)
3. Exchange keys securely
4. Establish encrypted channel

Duration: 1-2 round trips (50-100ms depending on TLS version)

Visual Overview: TLS 1.2 Handshake

Visual Overview: TLS 1.3 Handshake (Faster!)

Step-by-Step: TLS 1.2 Handshake

Step 1: Client Hello

Client initiates connection with:

Client Hello:
    Supported TLS Versions: TLS 1.2, TLS 1.1
    Cipher Suites: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, ...
    Random: [32 bytes of random data]
    Session ID: [for resumption]
    Extensions: server_name (SNI), supported_groups, ...

SNI (Server Name Indication): Tells the server which domain the client wants (essential for shared hosting with multiple sites on one IP).

Step 2: Server Hello

Server responds with:

Server Hello:
    Selected Version: TLS 1.2
    Selected Cipher: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    Random: [32 bytes of random data]
    Session ID: [for resumption]

Step 3: Server Certificate

Server sends its certificate chain:

Certificate:
    [Server Certificate]
    [Intermediate CA Certificate]
    (Root CA NOT included - client has it in trust store)

Step 4: Certificate Verification

Client validates the certificate:

• Check signature chain up to trusted root
• Verify validity dates
• Match hostname against SANs/CN
• Check revocation status (OCSP/CRL)

Step 5: Key Exchange

Using ECDHE (Elliptic Curve Diffie-Hellman Ephemeral):

Server Key Exchange: [Server's ECDH public value]
Client Key Exchange: [Client's ECDH public value]

Both parties now independently calculate the same premaster secret.

Step 6: Session Keys Generated

From the premaster secret, both derive:

• Client write key (client → server encryption)
• Server write key (server → client encryption)
• Client write MAC key
• Server write MAC key

Step 7: Finished Messages

Client: ChangeCipherSpec (now using encryption)
Client: Finished [encrypted hash of all handshake messages]
Server: ChangeCipherSpec
Server: Finished [encrypted hash of all handshake messages]

Step 8: Encrypted Communication

Handshake complete! All application data is now encrypted with symmetric encryption (AES-256-GCM typically).

TLS 1.3 Differences

TLS 1.3 simplifies and speeds up the handshake:

Improvements:

• 1-RTT handshake (vs 2-RTT in TLS 1.2)
• Key exchange happens in Client Hello (key_share extension)
• Removes RSA key exchange entirely
• Removes weak cipher suites
• Encrypted handshake (only Client Hello is plaintext)
• 0-RTT resumption option (with caveats)

Perfect Forward Secrecy (PFS)

The problem with RSA key exchange: If an attacker records encrypted traffic today and later obtains the server's private key, they can decrypt ALL past recorded sessions.

Ephemeral key exchange (ECDHE) provides PFS:

• New key pair generated for EACH session
• Keys deleted after session ends
• Compromising the server's key doesn't help decrypt past sessions

TLS 1.3 mandates PFS—all cipher suites use ephemeral key exchange.

---

10. Certificate Validation Process

When a browser connects to an HTTPS site, it performs extensive validation:

Visual Overview: Certificate Validation Flow

1. Chain Verification

Browser walks up the chain, verifying each signature.

2. Signature Verification

For each certificate in the chain:

• Extract issuer's public key
• Decrypt signature (getting the hash)
• Calculate hash of certificate data
• Compare: must match exactly

3. Validity Date Checking

Current time must be:
    After "Not Before" date
    Before "Not After" date

• Uses UTC time
• Clock skew can cause false failures

4. Hostname Verification

The domain you're connecting to must match:

• Subject Alternative Names (SANs) - primary check
• Common Name (CN) - fallback for old certs

Connecting to: www.example.com

Certificate SANs:
    DNS:example.com          ← Doesn't match
    DNS:www.example.com      ← MATCH!
    DNS:api.example.com      ← Doesn't match

5. Revocation Status

Check if certificate has been revoked:

• CRL (Certificate Revocation List): Download list, check if serial present
• OCSP (Online Certificate Status Protocol): Query CA's OCSP responder

6. Trust Store Lookup

Root CA must be in the browser/OS trusted root store. If not found, validation fails with "untrusted issuer" error.

---

11. Certificate Lifecycle Management

The Complete Lifecycle

Private Key Generation

# Generate RSA 2048-bit private key
openssl genrsa -out private.key 2048

# Generate RSA 4096-bit private key (more secure)
openssl genrsa -out private.key 4096

# Generate ECDSA P-256 private key (recommended)
openssl ecparam -genkey -name prime256v1 -out private.key

Critical: Protect your private key!

• Never share it
• Store securely (HSM for high-security environments)
• Use file permissions (chmod 600)
• Keep secure backups

Certificate Signing Request (CSR)

A CSR contains:

• Your public key
• Domain/organization information
• Signature (proves you have the private key)

# Create CSR
openssl req -new -key private.key -out request.csr

# You'll be prompted for:
# Country Name (2 letter code) [US]:
# State or Province Name [California]:
# Locality Name [San Francisco]:
# Organization Name [My Company]:
# Common Name [example.com]:

Domain Validation Methods

How CAs verify you control the domain:

Certificate Installation

Varies by web server:

Nginx:

server {
    listen 443 ssl;
    ssl_certificate /path/to/fullchain.pem;
    ssl_certificate_key /path/to/private.key;
}

Apache:

<VirtualHost *:443>
    SSLEngine on
    SSLCertificateFile /path/to/certificate.crt
    SSLCertificateKeyFile /path/to/private.key
    SSLCertificateChainFile /path/to/chain.crt
</VirtualHost>

Certificate Renewal

• Set calendar reminders (30 days before expiry)
• Monitor with tools (SSL Labs, certificate monitoring services)
• Automate with ACME (Let's Encrypt + Certbot)
• Test renewal process before it's critical

---

12. Certificate Revocation

Sometimes certificates need to be invalidated before they expire.

Reasons for Revocation

• Private key compromised or suspected compromise
• CA compromised
• Domain ownership changed
• Certificate issued incorrectly
• Organization no longer exists
• Employee left company (for user certificates)

Certificate Revocation Lists (CRLs)

How CRLs work:

1. CA maintains a list of revoked certificate serial numbers
2. Clients download the CRL periodically
3. Check if certificate's serial number is on the list

Problems with CRLs:

• Can become very large (megabytes)
• Infrequent updates (hours to days)
• Must download entire list even for one check
• Soft-fail: Most browsers ignore CRL check failures

Online Certificate Status Protocol (OCSP)

How OCSP works:

1. Client sends certificate serial number to OCSP responder
2. OCSP responder returns: GOOD, REVOKED, or UNKNOWN
3. Real-time verification

Problems with OCSP:

• Privacy: CA knows every site you visit
• Latency: Extra round-trip for each connection
• Availability: If OCSP server is down, what do you do?
• Soft-fail: Most browsers proceed if OCSP fails

OCSP Stapling

The best solution:

1. Server periodically fetches its own OCSP response from CA
2. Server "staples" the response to the TLS handshake
3. Client gets proof of validity without contacting CA

Benefits:

• Fast (no extra round-trip)
• Private (CA doesn't see client)
• Reliable (works even if CA's OCSP server is slow)

# Enable OCSP Stapling in Nginx
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8;

Must-Staple Extension

Certificate extension that tells clients: "Require OCSP stapling—if missing, reject the connection."

This prevents attackers from hiding revocation by blocking OCSP responses.

Browser-Specific Approaches

---

13. Let's Encrypt & ACME Protocol

What is Let's Encrypt?

Let's Encrypt is a free, automated, open Certificate Authority that has revolutionized web security.

Key facts:

• Launched December 2015
• Non-profit (Internet Security Research Group - ISRG)
• Issues 3+ million certificates per day
• Over 300 million websites use Let's Encrypt
• Responsible for HTTPS adoption going from ~40% to ~90%+

Free vs Paid Certificates

When to use commercial certificates:

• Need OV or EV validation
• Want warranty/insurance
• Need phone support
• Long validity preferred (less automation)

ACME Protocol

Automatic Certificate Management Environment - the protocol that powers Let's Encrypt automation.

How ACME works:

1. Client generates account key pair
2. Client requests certificate for domain
3. CA returns challenges to prove domain control
4. Client completes challenges
5. CA verifies challenges
6. CA issues certificate

Challenge Types

HTTP-01 Challenge

1. CA: "Place this token at 
       http://example.com/.well-known/acme-challenge/{token}"
2. Client: Places file with specified content
3. CA: Fetches URL and verifies content
4. CA: Domain validated!

Requirements:

• Web server accessible on port 80
• Control over web content
• Doesn't work for wildcard certificates

DNS-01 Challenge

1. CA: "Create this TXT record: 
       _acme-challenge.example.com → {value}"
2. Client: Creates DNS record
3. CA: Queries DNS and verifies
4. CA: Domain validated!

Requirements:

• DNS API access or manual DNS editing
• Required for wildcard certificates
• Works even without web server

TLS-ALPN-01 Challenge

• Proves control via TLS on port 443
• Useful when port 80 is blocked
• Less commonly used

Certbot and ACME Clients

Certbot is the official ACME client from EFF:

# Install Certbot
sudo apt install certbot python3-certbot-nginx

# Get certificate and configure Nginx automatically
sudo certbot --nginx -d example.com -d www.example.com

# Renew all certificates
sudo certbot renew

Other popular ACME clients:

• acme.sh: Bash script, no dependencies
• Caddy: Web server with automatic HTTPS built-in
• Traefik: Reverse proxy with automatic certificates
• cert-manager: Kubernetes-native certificate management

90-Day Validity

Why only 90 days?

1. Encourages automation: Can't manually renew every 90 days forever
2. Limits damage: Compromised keys are valid for less time
3. Frequent rotation: Better security posture
4. Forces good practices: Automation means fewer outages

Best practice: Set up automatic renewal to run daily (Certbot checks if renewal is needed).

# Certbot auto-renewal (usually set up automatically)
0 0 * * * certbot renew --quiet

---

14. Practical Certificate Operations

OpenSSL Commands

OpenSSL is the Swiss Army knife of certificate management.

Generate Private Key

# RSA 2048-bit
openssl genrsa -out private.key 2048

# RSA 4096-bit
openssl genrsa -out private.key 4096

# ECDSA P-256 (recommended)
openssl ecparam -genkey -name prime256v1 -out private.key

# With password protection
openssl genrsa -aes256 -out private.key 2048

Create CSR

# Interactive
openssl req -new -key private.key -out request.csr

# Non-interactive
openssl req -new -key private.key -out request.csr \
    -subj "/C=US/ST=California/L=San Francisco/O=My Company/CN=example.com"

Create Self-Signed Certificate

# Valid for 365 days
openssl req -x509 -new -key private.key -out certificate.crt -days 365 \
    -subj "/CN=example.com"

# With SANs (Subject Alternative Names)
openssl req -x509 -new -key private.key -out certificate.crt -days 365 \
    -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:example.com,DNS:www.example.com")) \
    -extensions SAN

View Certificate Details

# View certificate
openssl x509 -in certificate.crt -text -noout

# View CSR
openssl req -in request.csr -text -noout

# View private key (be careful!)
openssl rsa -in private.key -text -noout

Test SSL/TLS Connection

# Connect and show certificate
openssl s_client -connect example.com:443

# Show full certificate chain
openssl s_client -connect example.com:443 -showcerts

# Test specific TLS version
openssl s_client -connect example.com:443 -tls1_2
openssl s_client -connect example.com:443 -tls1_3

# With SNI (for shared hosting)
openssl s_client -connect example.com:443 -servername example.com

Check Certificate Expiration

# Check expiration date
openssl x509 -in certificate.crt -noout -enddate

# Check if certificate will expire within 30 days
openssl x509 -in certificate.crt -checkend 2592000

# Check remote certificate expiration
echo | openssl s_client -connect example.com:443 2>/dev/null | \
    openssl x509 -noout -enddate

Certificate Formats

Convert Between Formats

# PEM to DER
openssl x509 -in cert.pem -outform DER -out cert.der

# DER to PEM
openssl x509 -in cert.der -inform DER -out cert.pem

# PEM to PFX (with private key)
openssl pkcs12 -export -out cert.pfx -inkey private.key -in cert.pem -certfile chain.pem

# PFX to PEM
openssl pkcs12 -in cert.pfx -out cert.pem -nodes

Certificate Bundling

Servers need to send the full chain (except root):

# Create full chain file
cat certificate.crt intermediate.crt > fullchain.pem

# Verify chain
openssl verify -CAfile root.crt -untrusted intermediate.crt certificate.crt

Online Testing Tools

---

15. Browser Certificate Inspection

How to View Certificates

Chrome

1. Click padlock icon in address bar
2. Click "Connection is secure"
3. Click "Certificate is valid"
4. View certificate details

Firefox

1. Click padlock icon
2. Click right arrow next to "Connection secure"
3. Click "More Information"
4. Click "View Certificate"

Safari

1. Click padlock icon
2. Click "Show Certificate"

Edge

1. Click padlock icon
2. Click "Connection is secure"
3. Click certificate icon

Understanding Certificate Details

When viewing a certificate, you'll see:

• Subject: Who the certificate is for
• Issuer: Who issued it
• Validity: Start and end dates
• Public Key: Algorithm and key size
• Fingerprints: SHA-256, SHA-1 hashes
• Extensions: SANs, Key Usage, etc.

Common Certificate Errors

NET::ERR_CERT_AUTHORITY_INVALID

Cause: Certificate not signed by trusted CA Fix:

• Use CA-signed certificate
• Install missing intermediate certificates
• For self-signed: Add to trusted store (development only)

NET::ERR_CERT_COMMON_NAME_INVALID

Cause: Domain doesn't match certificate Fix:

• Get certificate with correct domain in SANs
• Check for typos in domain name
• Ensure www and non-www are both covered

NET::ERR_CERT_DATE_INVALID

Cause: Certificate expired or not yet valid Fix:

• Renew expired certificate
• Check server clock (might be wrong)
• Wait for "Not Before" date if too early

Mixed Content Warnings

Cause: HTTPS page loads HTTP resources Fix:

• Update all resource URLs to HTTPS
• Use protocol-relative URLs (//example.com/resource)
• Implement Content-Security-Policy

Certificate Pinning Violations

Cause: Certificate doesn't match pinned key/certificate Fix:

• Update pins when rotating certificates
• Include backup pins
• Consider if pinning is necessary (complex to maintain)

---

16. Hands-On Demonstrations

Demo 1: Generate a Self-Signed Certificate

# Step 1: Create private key
openssl genrsa -out mysite.key 2048

# Step 2: Create self-signed certificate
openssl req -new -x509 -key mysite.key -out mysite.crt -days 365 \
    -subj "/CN=localhost"

# Step 3: View the certificate
openssl x509 -in mysite.crt -text -noout

Demo 2: Create a CSR for CA Signing

# Step 1: Generate key
openssl genrsa -out example.key 2048

# Step 2: Create CSR with SANs
cat > csr.conf << EOF
[req]
default_bits = 2048
distinguished_name = req_distinguished_name
req_extensions = req_ext

[req_distinguished_name]
countryName = US
stateOrProvinceName = California
localityName = San Francisco
organizationName = My Company
commonName = example.com

[req_ext]
subjectAltName = @alt_names

[alt_names]
DNS.1 = example.com
DNS.2 = www.example.com
EOF

openssl req -new -key example.key -out example.csr -config csr.conf

# Step 3: Verify CSR
openssl req -in example.csr -text -noout

Demo 3: Set Up HTTPS on Local Server

# Using Python's built-in server (for testing)
# First, generate self-signed cert as in Demo 1

# Python 3
python3 << 'EOF'
import http.server
import ssl

server_address = ('0.0.0.0', 443)
httpd = http.server.HTTPServer(server_address, http.server.SimpleHTTPRequestHandler)
httpd.socket = ssl.wrap_socket(httpd.socket, 
                                certfile='mysite.crt',
                                keyfile='mysite.key',
                                server_side=True)
print("Serving HTTPS on port 443...")
httpd.serve_forever()
EOF

Demo 4: Inspect Remote Certificate

# Get certificate details
echo | openssl s_client -connect google.com:443 2>/dev/null | \
    openssl x509 -text -noout

# Check expiration
echo | openssl s_client -connect google.com:443 2>/dev/null | \
    openssl x509 -noout -dates

# View certificate chain
openssl s_client -connect google.com:443 -showcerts

Demo 5: Set Up Let's Encrypt with Certbot

# Install Certbot (Ubuntu/Debian)
sudo apt update
sudo apt install certbot python3-certbot-nginx

# Get certificate (interactive)
sudo certbot --nginx -d example.com -d www.example.com

# Test automatic renewal
sudo certbot renew --dry-run

# View certificates
sudo certbot certificates

Demo 6: Test SSL/TLS Configuration

# Test TLS versions
for version in tls1 tls1_1 tls1_2 tls1_3; do
    echo "Testing $version..."
    timeout 5 openssl s_client -connect example.com:443 -$version < /dev/null 2>&1 | \
        grep -E "(Protocol|Cipher)"
done

# Check cipher suites
nmap --script ssl-enum-ciphers -p 443 example.com

Demo 7: Simulate Certificate Expiration

# Create certificate expiring in 1 day
openssl req -x509 -new -key private.key -out expiring.crt -days 1 \
    -subj "/CN=expiring.local"

# Check expiration
openssl x509 -in expiring.crt -noout -enddate

# Check if expiring within 7 days
openssl x509 -in expiring.crt -checkend 604800
echo "Exit code: $? (0 = NOT expiring, 1 = expiring soon)"

---

17. Security Best Practices

Implementing SSL/TLS correctly is just as important as implementing it at all. Here are essential best practices.

Key Management Best Practices

Private Key Protection

Essential Key Management Rules:

1. Generate keys securely

   # Use strong random number generator
   openssl genrsa -out private.key 4096
   
   # Or use ECDSA (faster, same security with smaller keys)
   openssl ecparam -genkey -name prime256v1 -out private.key
   

2. Restrict file permissions immediately

   chmod 600 private.key
   chown root:root private.key
   

3. Never store keys in version control

   # .gitignore
   *.key
   *.pem
   private*
   

4. Rotate keys periodically

   • Minimum: Every certificate renewal
   • Recommended: Every 1-2 years
   • After any suspected compromise: Immediately

TLS Configuration Best Practices

Recommended Nginx Configuration (2024+)

# Modern SSL configuration
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;

# TLS 1.3 ciphers (automatic, no configuration needed)
# TLS 1.2 ciphers (secure subset)
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;

# Enable OCSP Stapling
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;

# Session settings
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;

# HSTS (be careful - hard to undo!)
add_header Strict-Transport-Security "max-age=63072000" always;

Recommended Apache Configuration

# Modern SSL configuration
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder off

# OCSP Stapling
SSLUseStapling on
SSLStaplingCache "shmcb:logs/stapling-cache(150000)"

# HSTS
Header always set Strict-Transport-Security "max-age=63072000"

Certificate Management Best Practices

Security Headers Checklist

# Essential security headers alongside HTTPS
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Content-Security-Policy "default-src 'self';" always;

---

18. Common Pitfalls & How to Avoid Them

Learn from others' mistakes—these are the most common SSL/TLS implementation errors.

Pitfall 1: Incomplete Certificate Chain

The Problem:

Browser Error: NET::ERR_CERT_AUTHORITY_INVALID

Server sends only the end-entity certificate, missing intermediate CA certificates.

Why It Happens:

• Works on desktop browsers (they cache intermediates)
• Fails on mobile, curl, API clients, new browsers

Visual Explanation:

Solution:

# Create full chain file
cat server.crt intermediate.crt > fullchain.pem

# Verify chain is complete
openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt
# Should output: server.crt: OK

Pitfall 2: Mixed Content Errors

The Problem: HTTPS page loads resources over HTTP, breaking the security model.

<!-- WRONG: HTTP resource on HTTPS page -->
<script src="http://cdn.example.com/script.js"></script>

<!-- CORRECT: Use HTTPS or protocol-relative -->
<script src="https://cdn.example.com/script.js"></script>
<script src="//cdn.example.com/script.js"></script>

Detection:

# Find mixed content in HTML
grep -r "http://" ./public/ --include="*.html"
grep -r "http://" ./src/ --include="*.js"

Pitfall 3: Forgetting to Redirect HTTP to HTTPS

The Problem: Users typing example.com get HTTP, not HTTPS.

Solution - Nginx:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$server_name$request_uri;
}

Solution - Apache:

<VirtualHost *:80>
    ServerName example.com
    Redirect permanent / https://example.com/
</VirtualHost>

Pitfall 4: Certificate Hostname Mismatch

The Problem:

Browser Error: NET::ERR_CERT_COMMON_NAME_INVALID

Certificate doesn't cover the domain being accessed.

Common Scenarios: | User Visits | Certificate Covers | Result | |-------------|-------------------|--------| | www.example.com | example.com only | ❌ Error | | example.com | www.example.com only | ❌ Error | | api.example.com | .example.com | ✓ Works | | dev.api.example.com | .example.com | ❌ Error (2 levels) |

Solution: Always include ALL domains in SANs:

subjectAltName = DNS:example.com, DNS:www.example.com, DNS:api.example.com

Pitfall 5: Using Outdated TLS Versions

The Problem: Supporting TLS 1.0/1.1 exposes users to known vulnerabilities.

Check Current Configuration:

# Test what versions your server supports
nmap --script ssl-enum-ciphers -p 443 yourdomain.com

Disable Old Versions:

# ONLY allow TLS 1.2 and 1.3
ssl_protocols TLSv1.2 TLSv1.3;

Pitfall 6: Expired Certificates

The Problem: Certificate expires → Complete site outage.

Prevention:

# Check expiration
echo | openssl s_client -connect yourdomain.com:443 2>/dev/null | \
    openssl x509 -noout -dates

# Automated monitoring (cron job)
#!/bin/bash
DOMAIN="yourdomain.com"
WARN_DAYS=30

expiry=$(echo | openssl s_client -connect $DOMAIN:443 2>/dev/null | \
    openssl x509 -noout -enddate | cut -d= -f2)
expiry_epoch=$(date -d "$expiry" +%s)
now_epoch=$(date +%s)
days_left=$(( ($expiry_epoch - $now_epoch) / 86400 ))

if [ $days_left -lt $WARN_DAYS ]; then
    echo "WARNING: $DOMAIN certificate expires in $days_left days!"
    # Send alert email, Slack notification, etc.
fi

Pitfall 7: Weak Key Sizes

The Problem: Using 1024-bit RSA keys (or smaller) is insecure.

Minimum Requirements (2024): | Algorithm | Minimum | Recommended | |-----------|---------|-------------| | RSA | 2048-bit | 4096-bit | | ECDSA | P-256 | P-384 | | Ed25519 | N/A | Use it (always secure) |

Check Key Size:

openssl x509 -in certificate.crt -noout -text | grep "Public-Key"
# Should show: RSA Public-Key: (2048 bit) or higher

Pitfall 8: Not Testing After Changes

Always Test:

1. SSL Labs - https://www.ssllabs.com/ssltest/
2. Local verification:

   curl -I https://yourdomain.com
   openssl s_client -connect yourdomain.com:443
   

3. Mobile devices - They often fail when desktops work

---

19. Real-World Case Studies

Case Study 1: E-Commerce Platform Migration to HTTPS

Scenario: Online retailer with 50,000 daily visitors migrating from HTTP to HTTPS.

Challenges:

• Mixed content from years of HTTP URLs in database
• Third-party widgets using HTTP
• SEO rankings at risk during migration
• Multiple subdomains (shop, blog, api, cdn)

Solution:

Results:

• Zero downtime during migration
• 3% improvement in conversion rate (trust indicators)
• Google rankings maintained/improved
• SSL Labs score: A+

Case Study 2: Automated Certificate Management for Microservices

Scenario: 200+ microservices in Kubernetes needing individual certificates for mTLS.

Before (Manual Process):

• 3 days to provision new service certificate
• Frequent outages from expired certificates
• No visibility into certificate inventory

Solution Architecture:

Implementation:

# cert-manager Certificate resource
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: api-service-tls
spec:
  secretName: api-service-tls-secret
  duration: 2160h # 90 days
  renewBefore: 720h # Renew 30 days before
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
    - api.example.com
    - api-internal.example.com

Results:

• Certificate provisioning: 3 days → 5 minutes
• Zero certificate-related outages in 18 months
• Complete visibility into all certificates
• Automated compliance reporting

Case Study 3: Bank Implementing EV Certificates with HSM

Scenario: Regional bank implementing highest-security SSL/TLS for online banking.

Requirements:

• Extended Validation (EV) certificates
• Private keys in FIPS 140-2 Level 3 HSM
• PCI DSS compliance
• 99.999% uptime

Architecture:

Results:

• Passed PCI DSS audit
• SSL Labs score: A+
• Zero security incidents
• Customer trust increased measurably

---

20. Emerging Trends & Future Developments

Post-Quantum Cryptography (PQC)

The Threat: Quantum computers could break current public-key cryptography:

• RSA: Broken by Shor's algorithm
• ECDSA: Also vulnerable to quantum attacks
• AES: Weakened but still usable (double key size)

Timeline Estimates:

• 2030-2035: Cryptographically relevant quantum computers possible
• NOW: "Harvest now, decrypt later" attacks happening
• 2024+: Transition period begins

NIST Post-Quantum Standards (Finalized 2024):

What You Should Do Now:

1. Inventory: Know which systems use public-key crypto
2. Crypto agility: Design systems that can swap algorithms
3. Hybrid mode: Some browsers already support hybrid TLS (classical + PQC)
4. Monitor: Follow NIST and browser vendor announcements

Example: Chrome's Hybrid PQC Support:

Certificate Transparency (CT)

What It Is: Public, append-only logs of all issued certificates.

Why It Matters:

• Detect mis-issued certificates
• Catch CA compromises faster
• Required for browser trust since 2018

How to Use CT:

# Search for certificates issued for your domain
# Visit: https://crt.sh/?q=yourdomain.com

# Monitor for new certificates (catch unauthorized issuance)
# Tools: Facebook's Certificate Transparency Monitoring
#        SSLMate's CertSpotter

Automatic HTTPS Everywhere

Emerging Standards:

1. HTTPS-Only Mode (Browsers)

   • Firefox, Chrome offer HTTPS-only browsing
   • Automatic upgrade HTTP → HTTPS

2. ACME Everywhere

   • Cloud providers auto-provision certs
   • CDNs handle certificates automatically
   • Zero-config HTTPS becoming standard

3. DNS-over-HTTPS (DoH) & DNS-over-TLS (DoT)

   • Encrypted DNS queries
   • Prevents DNS-based attacks

Shorter Certificate Lifetimes

Trend:

• 2015: 5-year certificates common
• 2018: Max 825 days (CA/Browser Forum)
• 2020: Max 398 days (13 months)
• 2024+: Discussions of 90-day maximum for all certs
• Future: Possibly 45-day or shorter

Implication: Automation isn't optional—it's mandatory.

Decentralized Identity & Certificates

Emerging Concepts:

• Self-sovereign identity
• Decentralized PKI (DPKI)
• Blockchain-based certificate transparency
• Verifiable credentials (W3C standard)

Current State: Experimental, but watch for integration with traditional PKI.

---

Conclusion

You've now covered the complete landscape of SSL/TLS and PKI:

✅ Cryptography Fundamentals: Symmetric vs asymmetric encryption, hashing, digital signatures with detailed visual explanations

✅ PKI Architecture: CAs, root stores, chains of trust, and the hierarchical trust model

✅ Certificate Deep Dive: X.509 structure, SANs, key usage, validation levels

✅ TLS Handshake: Step-by-step visual breakdowns of TLS 1.2 and 1.3 handshakes

✅ Lifecycle Management: Generation, issuance, renewal, revocation with practical commands

✅ Security Best Practices: Key management, TLS configuration, and security headers

✅ Common Pitfalls: How to avoid the most frequent implementation mistakes

✅ Real-World Case Studies: E-commerce migration, microservices, and enterprise banking examples

✅ Future-Proofing: Post-quantum cryptography and emerging trends

Key Takeaways

Quick Reference Cheat Sheet

# Generate key
openssl genrsa -out private.key 4096

# Create CSR
openssl req -new -key private.key -out request.csr

# View certificate
openssl x509 -in cert.crt -text -noout

# Check remote certificate
openssl s_client -connect example.com:443

# Check expiration
echo | openssl s_client -connect example.com:443 2>/dev/null | \
    openssl x509 -noout -enddate

# Test full chain
openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt

Recommended Tools

Further Reading

• Mozilla SSL Configuration Generator
• Let's Encrypt Documentation
• NIST Post-Quantum Cryptography
• CA/Browser Forum Baseline Requirements

---