Threat Model - 2 Tier PKI for Web Server Certificates

System: Two-Tier Public Key Infrastructure (PKI)
Version: 1.0
System: Two-Tier Public Key Infrastructure (PKI)
Scope: PKI issuing and validating X.509 certificates for internal web servers.

1. System Overview

The PKI enables secure TLS authentication for corporate web servers.
It uses a two-tier architecture:

• Offline Root CA (Trust Anchor)
  • Kept completely offline (air-gapped)
  • Signs the Intermediate CA certificate only
  • Publishes Root CA CRL periodically
• Online Intermediate CA
  • Hosted on a hardened server
  • Issues and revokes end-entity (web server) certificates
  • Publishes CRL and/or OCSP responses
• Web Server (End Entity)
  • Requests and installs its certificate
  • Uses the certificate for TLS authentication
• Relying Party (Client / Browser)
  • Validates the certificate chain and revocation status
• CRL/OCSP Distribution Point
  • Provides certificate status information for revocation checking

2. Architecture Diagram

flowchart TD
    A -->[Offline Root CA] -->(Signs) B[Online Intermediate CA]
    B -->(Issues) C[Web Server Certificate]
    B -->(Publishes CRL/OCSP) D[CRL/OCSP Server]
    C -->(Presents Cert) E[Relying Party]
    E -->(Validates via CRL/OCSP) D

3. Assets and Trust Boundaries

Category	Asset	Description	Trust Boundary
Root CA	Root private key	Ultimate trust anchor; compromise is catastrophic	Offline / Air-gapped
Intermediate CA	Intermediate private key	Used to issue all operational certs	Online CA boundary
Web Server	End-entity private key	Used for TLS authentication	Within server boundary
Certificates	X.509 chain	Proof of identity and trust chain	Crosses network
CRL/OCSP	Revocation data	Used to validate certificate status	Publicly accessible
Configuration	OpenSSL config, policies	Defines certificate profiles and validity	CA management zone
Audit Logs	Event records	Record issuance, revocation, access	CA operational zone

4. Trust Boundaries

• Offline Root Boundary – Air-gapped, only accessible during key ceremonies.
• CA Management Boundary – Restricted zone where Intermediate CA operates.
• Network Boundary – Between CA and CRL/OCSP publication endpoints.
• Public Boundary – Between web server and external clients.
• Each boundary crossing introduces confidentiality and integrity risks.

5. Threat Enumeration (STRIDE)

Threat Category	Example Threats	Affected Assets	Mitigations
Spoofing	Fake intermediate CA or web server impersonation	Certificates, keys	Chain validation, CA pinning, HSM-protected keys
Tampering	Unauthorized modification of CRL or certs	CRL, DB, cert files	Signed CRLs, integrity checks, digital signatures
Repudiation	CA operator denies issuing/revoking a cert	Logs, issuance records	Audit trails, signed logs, secure timestamps
Information Disclosure	Exposure of private keys or internal CA details	Private keys, config files	Encryption at rest, strict access control, air-gapped root
Denial of Service	CRL/OCSP unavailability, CA overload	CRL/OCSP server	Load balancing, caching, redundant distribution
Elevation of Privilege	Compromise of CA operator or system account	CA host, keys	MFA, least privilege, HSM-based signing, OS hardening

6. Risk Assessment

Threat Impact Likelihood Risk Level Mitigation Summary Root key compromise Critical Rare High Offline root, HSM, multi-person control Intermediate CA compromise Critical Possible High HSM, network isolation, MFA CRL tampering High Low Medium Signed CRL, integrity checks Unauthorized certificate issuance High Medium High Role separation, issuance policy enforcement OCSP outage Medium Medium Medium Redundant responders, failover mechanisms Audit log tampering High Low Medium Immutable storage, signed logs Weak crypto algorithms High Low Medium Enforce RSA 4096 / ECDSA P-384, SHA-256+ Misconfigured web server certs Medium Medium Medium Automated validation, linting, cert monitoring

7. Mitigation Recommendations

• Root CA
  • Keep offline at all times except during signing ceremonies.
  • Use multi-person control (M of N) and HSM protection.
  • Periodically issue Root CRLs to support revocation of intermediate certs.
• Intermediate CA
  • Harden OS and isolate from other networks.
  • Store private key in HSM or TPM.
  • Enforce certificate policies and approval workflows.
  • Regularly rotate and review access credentials.
• CRL/OCSP
  • Ensure redundancy and synchronization.
  • Digitally sign all responses.
  • Use short-lived OCSP responses to reduce risk exposure.
• Operational Controls
  • Maintain immutable, centralized logs.
  • Perform periodic key ceremonies and audits.
  • Use internal monitoring for unauthorized issuance or access.

8. Assumptions and Dependencies

• Relying parties trust the Root CA certificate.
• Private keys are generated securely and never exported in plaintext.
• Network time (NTP) is synchronized for cert validity checking.
• OpenSSL is configured with FIPS-compliant algorithms.

9. References

• NIST SP 800-32: Introduction to PKI = RFC 5280: Internet X.509 PKI Certificate and CRL Profile
• Microsoft PKI Best Practices
• OWASP Cryptographic Storage Cheat Sheet