Chap 3B

Certificate Authorities

Certificate Authorities (CAs) solve the problem of verifying identity in public key cryptography. They ensure that public keys truly belong to who they claim to, by issuing digital certificates.

How It Works

1. A web server sends a Certificate Signing Request (CSR) containing its public key to the CA.

2. The CA signs the certificate using its private key and returns it.

3. The client receives the certificate and checks its validity using the CA’s public key (from a trusted root certificate).

4. If valid, the client trusts the server and establishes a secure connection.

PKI (Public Key Infrastructure)

A system that uses CAs to:

• Bind public keys to entities

• Maintain certificate trust chains

• Handle revocation, distribution, and validation

Types of CAs

• Public/Third-party CA: Trusted globally (e.g., DigiCert, Let's Encrypt)

• Private CA: Used within organizations for internal trust

✅ CA Responsibilities

• Issue digital certificates

• Verify requester’s identity

• Manage certificate lifecycles (e.g., revocation)

• Maintain secure certificate repositories

• Enable trust between browsers, clients, and servers

Digital Certificates

A digital certificate is a data file that securely binds a public key to a subject’s identity (e.g., a person, organization, or server). It is issued and digitally signed by a trusted Certificate Authority (CA).

📦 What’s Inside a Digital Certificate

• Subject's Public Key

• Subject Info (e.g., name, domain)

• Issuer Info (CA details)

• Validity period

• Signature (proves authenticity by CA)

• Extensions (additional metadata)

✅ Purpose of a Digital Certificate

• Proves the authenticity of a public key.

• Allows users to trust encrypted connections (e.g., HTTPS).

• Prevents man-in-the-middle attacks by confirming identity.

📚 Standards

• Based on X.509 standard (ITU + IETF)

• Supports Public Key Cryptography Standards (PKCS) for interoperability

Root of Trust

Root of Trust defines how Certificate Authorities (CAs) validate each other by issuing certificates in a trust chain.

🔑 Key Terms

• Root Certificate: Self-signed by the CA itself; highest trust anchor.

• Certificate Chaining (a.k.a. Chain of Trust): Links leaf certificates back to a trusted root via intermediate CAs.

🌳 Models

• Single CA Model: One root CA issues all certs directly. Risky—if compromised, entire system collapses.

• Third-party CAs: Use hierarchical model with:

  • Root CA → Intermediate CA → End Entity

  • Enables scalability, policy control, and isolation of risk

⚠ Self-Signed Certificates

• Not issued by a trusted CA.

• May be used for:

  • Internal/dev environments

  • Consumer routers/web UIs

• Considered untrusted by browsers

• Should not be used for production security

: Certificate Signing Requests

A CSR is a formal request sent to a Certificate Authority (CA) asking them to issue a digital certificate.

📌 CSR Key Points

• CSR is submitted by a subject (user/server) to a CA.

• It includes:

  • Public key of the subject

  • Domain/organization info (e.g., Common Name, Alternative Names)

  • Chosen algorithm (e.g., RSA, ECC)

  • Key length (e.g., 2048 bits)

  • Hash/digest algorithm (e.g., SHA-256)

🛠 How it Works

1. Subject generates key pair (public/private).

2. Submits CSR to CA.

3. CA verifies info (e.g., domain ownership, WHOIS data).

4. If valid, CA signs certificate with its private key and returns it.

🔐 Security Note

• Private key stays secret with the requester.

• CA never sees the private key—only signs based on the public key and submitted details.

Subject Name Attributes

Subject Name Attributes identify who or what a certificate is issued to (e.g., a domain, user, organization).

---

📌 Common Name (CN)

• Originally used to identify the Fully Qualified Domain Name (FQDN), e.g., www.comptia.org.

• Deprecated for validation — can be ambiguous.

• Still included for backward compatibility.

---

🧾 Subject Alternative Name (SAN)

• Modern standard for identifying certificate subjects.

• Supports multiple identifiers:

  • Domains (e.g., example.com)

  • Subdomains (e.g., login.example.com)

  • IP addresses

  • Emails (for user certs)

• Browsers should ignore CN and validate SAN.

🌐 Wildcard Domains

• Format: *.example.com

• Covers all subdomains at one level (e.g., mail.example.com, www.example.com)

• Safer to use specific SANs when possible.

🧩 Distinguished Name (DN)

• Full identity of the subject (used in CSR):

  CN=www.example.com, OU=Web Hosting, O=Example LLC, L=Chicago, ST=Illinois, C=US

Certificate Revocation

Revoking a certificate ensures compromised or outdated certs can’t be trusted anymore.

🚫 Revoked Certificate

• Permanently invalid

• Cannot be re-enabled

• Common reasons:

  • Private key compromise

  • Certificate misuse

  • Ownership changes

  • Domain name updates

⏸ Suspended Certificate

• Temporarily disabled

• Can be reinstated

• Assigned "Certificate Hold" status

📄 Certificate Revocation List (CRL)

• List of revoked/suspended certs maintained by the CA

• Each certificate points to a CRL Distribution Point

• Attributes:

  • Publish Period – how often CRL is updated

  • Validity Period – how long CRL is trusted

  • Signature – digitally signed by CA

🌐 Online Certificate Status Protocol (OCSP)

• Real-time method to check revocation

• Lighter than CRL (no full list download)

• Relies on OCSP responder to check cert status

Certificate Revocation

Summary: Certificate Revocation

🔒 Revoking a certificate ensures compromised or outdated certs can’t be trusted anymore.

🚫 Revoked Certificate

• Permanently invalid

• Cannot be re-enabled

• Common reasons:

  • Private key compromise

  • Certificate misuse

  • Ownership changes

  • Domain name updates

⏸ Suspended Certificate

• Temporarily disabled

• Can be reinstated

• Assigned "Certificate Hold" status

📄 Certificate Revocation List (CRL)

• List of revoked/suspended certs maintained by the CA

• Each certificate points to a CRL Distribution Point

• Attributes:

  • Publish Period – how often CRL is updated

  • Validity Period – how long CRL is trusted

  • Signature – digitally signed by CA

🌐 Online Certificate Status Protocol (OCSP)

• Real-time method to check revocation

• Lighter than CRL (no full list download)

• Relies on OCSP responder to check cert status

Key Management

🔐 Key Management refers to how cryptographic keys are created, stored, used, and retired.

🧩 Key Lifecycle Stages:

1. Key Generation

   • Creates asymmetric or symmetric keys of required strength.

2. Storage

   • Protects keys from unauthorized access or physical loss/damage.

3. Revocation

   • Disables compromised keys; encrypted data must be re-encrypted with a new key.

4. Expiration & Renewal

   • Keys/certificates have a shelf life; can be renewed with same or new key pair.

🧭 Management Models:

• Decentralized

  • Keys managed on the device/user system directly.

  • Simple but harder to detect compromise.

• Centralized

  • Uses a Key Management System (KMS).

  • Often includes a dedicated server/appliance.

🔄 KMIP

• Key Management Interoperability Protocol – allows devices to securely communicate with a central KMS server.

Cryptoprocessors and Secure Enclaves

🧠 Problem with Software-Based Key Storage:

• Keys stored in a typical OS file system are vulnerable.

• Randomness/entropy is weak on standard systems.

• Software-based key storage can be compromised if the system is breached.

• Keys must often be loaded into memory to be used, creating attack surfaces.

🔑 Cryptoprocessor Hardware Advantages

Cryptoprocessors generate, store, and protect keys in tamper-evident, isolated environments.

🧩 Key Hardware Options:

1. Trusted Platform Module (TPM)

   • Embedded chip in PCs or mobile devices.

   • Different versions (1.2 & 2.0), not backward-compatible.

   • Stores cryptographic keys securely.

2. Hardware Security Module (HSM)

   • Dedicated/removable appliance (e.g., rack-mounted, USB, PCIe).

   • Key material never leaves the device.

   • Can be physical or virtual.

🧰 APIs and Standards

• Cryptoprocessors expose functions via an API, such as PKCS#11.

• Vendors follow FIPS 140-2 Level 2/3 standards for compliance and trust.

🛡 Secure Enclaves (Trusted Execution Environment - TEE):

• Prevent unauthorized memory access, even from OS or root users.

• Examples: Intel SGX, ARM TrustZone.

• Protects in-use data (not just at-rest or in-transit).

• Runs digitally signed, isolated processes for added protection.

Key Escrow

Key Escrow — Summary

📌 Problem:
If a private/secret key is lost or damaged:

• Encrypted data is permanently lost.

• Duplicating keys increases the risk of compromise.

🧾 Key Escrow Concept

• Escrow = storing key(s) with a trusted third party.

• Ensures recoverability without duplicating keys across systems.

🔢 M of N Control (Multi-party authorization)

• An operation (e.g., key recovery) requires M out of N people to authorize.

• Example: 3 of 5 trusted individuals must agree to recover the key.

• Prevents a single person from compromising the process.

🛡 Key Recovery Agent (KRA)

• Has permission to access escrowed keys.

• May require multiple KRAs to cooperate (per key recovery policy).

• This adds protection against impersonation or misuse.