PKI Infrastructure — Certificates and PKI | OneNoughtOne

0/121

Computer NetworksNetwork Security Protocols

Certificates and PKI

LevelIntermediate

Duration90 mins

TopicNetwork Security Protocols

5 / 5

PKI Infrastructure

The Complete Picture

We've explored X.509 certificates, Certificate Authorities, chains of trust, and revocation mechanisms. Now it's time to see how these pieces combine into Public Key Infrastructure (PKI) —complete systems that enable secure digital communications at scale. PKI isn't just about individual certificates. It's an ecosystem encompassing: Policies that define what certificates can be issued and for what purposes Procedures for identity verification, key management, and incident response Technology including CAs, directory services, OCSP responders, and key management systems Trust relationships between organizations, users, and automated systems Governance structures that ensure accountability and compliance From the web PKI securing billions of HTTPS connections to enterprise PKIs protecting corporate networks to specialized systems in healthcare, finance, and government—PKI implementations vary dramatically based on requirements. This page examines how PKI is deployed across these contexts, providing the complete picture of PKI infrastructure.

What You Will Master

By the end of this page, you will understand the complete PKI ecosystem: web PKI architecture and its governance, enterprise PKI design patterns, trust store management, specialized PKI applications, and best practices for deploying and managing PKI in various contexts.

The Web PKI Ecosystem

Web PKI is the PKI that secures HTTPS, the encrypted web. It's the most visible PKI system, used by billions of people daily—typically without awareness of its existence. Components of Web PKI:

Web PKI Components

•Certificate Authorities — Organizations that issue TLS certificates (DigiCert, Let's Encrypt, Sectigo, etc.)
•Root Programs — Browser/OS vendors that decide which CAs to trust (Mozilla, Microsoft, Apple, Google)
•CA/Browser Forum — Industry body that sets standards (Baseline Requirements)
•Certificate Transparency — Public logs of all issued certificates for auditing
•OCSP Responders — Services providing real-time certificate status
•Domain Registrars — Issue domain control for validation
•Trust Stores — Collections of root certificates bundled with browsers/OSes

The Governance Structure: Web PKI has evolved a complex governance structure: CA/Browser Forum: Industry consortium of CAs and browser vendors Creates binding requirements (Baseline Requirements, EV Guidelines) Voting members include major CAs and all major browser vendors Consensus-driven but browser vendors have ultimate power Root Programs: Each major browser/OS maintains its own root program: Mozilla Root Store Policy — Open, community-driven, influential despite Firefox's market share Microsoft Root Certificate Program — Windows and Edge; significant enterprise influence Apple Root Certificate Program — macOS, iOS, Safari; aligned with Mozilla Google Chrome Root Program — New, transitioning from OS trust stores Root programs can and do remove CAs for violations. Symantec's removal from Chrome (2017-2018) affected a third of all TLS certificates—demonstrating the power these programs hold.

The Power Dynamic

Browser vendors have ultimate authority. CAs need browser trust to remain viable businesses. This asymmetry has enabled browsers to push security improvements that CAs might otherwise resist—shorter certificate lifespans, Certificate Transparency requirements, deprecated algorithms—knowing CAs must comply or be distrusted.

Certificate Transparency: Auditing the PKI

Certificate Transparency (CT) is a revolutionary addition to PKI that makes all certificate issuance publicly auditable. Proposed by Google engineers and standardized in RFC 6962, CT fundamentally changes the PKI trust model. The Problem CT Solves: Before CT, certificate mis-issuance was essentially invisible: CA issues fraudulent certificate for google.com Unless Google happened to intercept the certificate in use, they'd never know Attacker could use the certificate for targeted MITM attacks No audit trail, no accountability How CT Works:

Certificate Transparency Flow

•Logging — CA submits certificate (or pre-certificate) to CT logs before or shortly after issuance
•SCT Issuance — Log returns a Signed Certificate Timestamp (SCT), a cryptographic promise that the certificate is logged
•Embedding — SCT is embedded in certificate, delivered via TLS extension, or OCSP stapling
•Verification — Browser verifies SCTs are present and valid; rejects certificates without them
•Monitoring — Domain owners monitor logs for unauthorized certificates bearing their domains
•Auditing — Anyone can audit logs for consistency and completeness

ct-sct-example.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# Example SCT embedded in a certificate
X509v3 extensions:
    CT Precertificate SCTs:
        Signed Certificate Timestamp:
            Version   : v1 (0x0)
            Log ID    : E8:3E:D0:DA:...(Google 'Argon2024' log)
            Timestamp : Jan 15 00:00:01.234 2024 UTC
            Extensions: none
            Signature : ecdsa-with-SHA256
                        30:45:02:20:...
        Signed Certificate Timestamp:
            Version   : v1 (0x0)
            Log ID    : 48:B0:E3:6B:...(DigiCert Yeti2024 log)
            Timestamp : Jan 15 00:00:02.567 2024 UTC
            Extensions: none
            Signature : ecdsa-with-SHA256
                        30:46:02:21:...
 
# Chrome requires SCTs from at least two different log operators
# This prevents a single compromised log from enabling undetected mis-issuance
 
# View SCTs from a live server
echo | openssl s_client -connect example.com:443 2>/dev/null | \
    openssl x509 -noout -ext "ct_precert_scts"

CT Log Requirements: Chrome's CT policy requires: SCTs from at least two different log operators Logs must be from Google's approved log list Log operator diversity (not all SCTs from same company) Monitoring for Domain Owners: Domain owners should monitor CT logs for unauthorized certificates: crt.sh (Sectigo) — Web search for certificates by domain Google Transparency Report — Certificate search Facebook Certificate Transparency Monitoring — Alerts for your domains Custom monitors — Parse CT logs for matching domains Companies like Meta, Google, and financial institutions actively monitor logs and have caught mis-issuance within hours of occurrence.

CT's Impact

Certificate Transparency has fundamentally improved PKI accountability. Mis-issuance that would have been invisible is now publicly discoverable. CAs know that every certificate they issue is logged and auditable. This has driven significant improvements in CA practices and enabled faster incident detection and response.

Trust Store Management

A trust store is the collection of root certificates that a system trusts. Understanding trust store management is crucial for both security and troubleshooting. Trust Store Locations by Platform:

Trust Store Locations
Platform	Location	Management Tool
Windows	Certificate Store (certmgr.mmc)	certmgr.msc, PowerShell
macOS	Keychain Access (/System/Library/Keychains/)	security command, Keychain Access.app
Linux (Debian/Ubuntu)	/etc/ssl/certs/, /usr/share/ca-certificates/	update-ca-certificates
Linux (RHEL/CentOS)	/etc/pki/tls/certs/, /etc/pki/ca-trust/	update-ca-trust
Java	$JAVA_HOME/lib/security/cacerts	keytool
Firefox	NSS database (uses own trust store)	certutil, about:preferences#privacy
Chrome (Windows)	Windows Certificate Store	(uses OS store)
Chrome (Linux)	NSS database or OS store	certutil

trust-store-management.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
# Linux (Debian/Ubuntu): Add a custom CA certificate
sudo cp custom-ca.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates
 
# Linux (RHEL/CentOS): Add a custom CA certificate
sudo cp custom-ca.pem /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust extract
 
# macOS: Add a trusted certificate
sudo security add-trusted-cert -d -r trustRoot \
    -k /Library/Keychains/System.keychain custom-ca.pem
 
# Java: Add certificate to cacerts
keytool -importcert -alias custom-ca \
    -keystore $JAVA_HOME/lib/security/cacerts \
    -file custom-ca.pem \
    -storepass changeit
 
# View certificates in Java trust store
keytool -list -keystore $JAVA_HOME/lib/security/cacerts \
    -storepass changeit | head -50
 
# Firefox: Add certificate to NSS database
certutil -A -n "Custom CA" -t "TC,C,T" \
    -i custom-ca.pem -d sql:$HOME/.pki/nssdb
 
# Windows PowerShell: Add certificate to machine store
Import-Certificate -FilePath custom-ca.cer \
    -CertStoreLocation Cert:\LocalMachine\Root
 
# List Windows root certificates
Get-ChildItem -Path Cert:\LocalMachine\Root

Enterprise Trust Store Management: Enterprise environments need centralized trust store management: Group Policy (Windows): Distribute root certificates via GPO Certificates pushed to all domain-joined machines Enables enterprise CA trust without manual installation Configuration Management: Ansible, Puppet, Chef can deploy certificates to Linux systems Ensures consistent trust across fleet Version control for trust store changes MDM (Mobile Device Management): Deploy certificates to iOS/Android devices Required for enterprise apps and internal sites Can enforce certificate policies Security Considerations:

Trust Store Security

Adding a root certificate grants complete trust for any certificate that CA issues. Before adding any root, verify: Who operates this CA? What domains might it issue for? Is it Name Constrained? Malicious root installation is a common attack vector for TLS interception and malware.

Enterprise PKI Design

Many organizations run private PKI for internal use, providing certificates without depending on public CAs. Use Cases for Enterprise PKI:

Enterprise PKI Applications

•Internal TLS — Secure internal websites, APIs, microservices without paying for public certificates
•Client Authentication — Mutual TLS (mTLS) for service-to-service authentication
•Smart Card/PIV Authentication — Physical security credentials for building access and login
•Code Signing — Sign internal applications and scripts
•Email Encryption — S/MIME certificates for encrypted internal email
•Document Signing — Digital signatures on internal documents
•VPN Authentication — Certificate-based VPN client authentication
•WiFi/802.1X — EAP-TLS authentication for network access

Typical Enterprise PKI Architecture: ┌─────────────────┐ │ Offline Root │ │ CA │ │ (Air-gapped) │ └────────┬────────┘ │ ┌────────────────┼────────────────┐ │ │ │ ┌───────┴───────┐ ┌──────┴──────┐ ┌───────┴───────┐ │ Issuing CA #1 │ │ Issuing CA │ │ Issuing CA #3 │ │ (TLS Certs) │ │ #2 (Users) │ │ (Code Sign) │ └───────┬───────┘ └──────┬──────┘ └───────┬───────┘ │ │ │ Servers Smart Cards Dev Machines Design Principles: Offline Root CA — Root private key never touches a network; stored in HSM in secure facility Purpose-Specific Issuing CAs — Separate CAs for different certificate types; limits blast radius of compromise Automated Issuance — Self-service portals, ACME servers, or integration with Active Directory Certificate Services (ADCS) Name Constraints — If root is added to devices, constrain to company domains Short Validity for Automated Certs — Internal certificates can have short lifetimes with automated renewal

enterprise-ca-openssl.cnf
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
# OpenSSL configuration for enterprise root CA
 
[ ca ]
default_ca = enterprise_root_ca
 
[ enterprise_root_ca ]
dir               = /ca/root
database          = $dir/index.txt
serial            = $dir/serial
certificate       = $dir/ca.crt
private_key       = $dir/ca.key
default_days      = 3650          # 10 years for root
default_md        = sha256
policy            = policy_strict
 
[ policy_strict ]
countryName             = match
organizationName        = match
commonName              = supplied
 
[ v3_issuing_ca ]
subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints       = critical, CA:true, pathlen:0
keyUsage               = critical, digitalSignature, cRLSign, keyCertSign
nameConstraints        = critical, @name_constraints
 
[ name_constraints ]
permitted;DNS.0 = .internal.example.com
permitted;DNS.1 = .corp.example.com
permitted;email.0 = .example.com
permitted;IP.0 = 10.0.0.0/255.0.0.0
permitted;IP.1 = 192.168.0.0/255.255.0.0
excluded;IP.0 = 0.0.0.0/0.0.0.0     # No public IPs
 
[ v3_end_entity ]
subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid,issuer
basicConstraints       = critical, CA:false
keyUsage               = critical, digitalSignature, keyEncipherment
extendedKeyUsage       = serverAuth, clientAuth

Modern Enterprise PKI

Consider solutions like HashiCorp Vault, step-ca, or cloud-based private CAs (AWS Private CA, Google Cloud CA Service) for modern enterprise PKI. These provide APIs, automation, and integration that manual OpenSSL/ADCS setups lack.

Modern PKI Tooling

The PKI landscape has evolved beyond manual OpenSSL commands and ADCS. Modern tools provide automation, APIs, and integration with contemporary infrastructure. Certificate Management Solutions:

PKI and Certificate Management Tools
Tool	Type	Best For	Key Features
Let's Encrypt / certbot	Public CA + Client	Web server TLS	Free, automated, ACME protocol
HashiCorp Vault PKI	Private CA	Microservices, Kubernetes	API-driven, short-lived certs, secrets management
step-ca / Smallstep	Private CA	Modern enterprises	ACME support, JWK provisioning, OAuth integration
CFSSL	Private CA	Container environments	JSON-based, Kubernetes integration
AWS Private CA	Cloud-managed	AWS-heavy environments	Managed HSM, IAM integration
Google Cloud CA Service	Cloud-managed	GCP environments	Tiered CA hierarchy, Kubernetes integration
cert-manager	Certificate controller	Kubernetes	Automates certificate lifecycle in K8s
Venafi	Enterprise management	Large enterprises	Visibility, policy enforcement, compliance

modern-pki-examples.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
# cert-manager Certificate resource for Kubernetes
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: api-tls-cert
  namespace: production
spec:
  secretName: api-tls-secret
  duration: 2160h    # 90 days
  renewBefore: 360h  # Renew 15 days before expiry
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  commonName: api.example.com
  dnsNames:
    - api.example.com
    - api-internal.example.com
 
---
# HashiCorp Vault PKI role configuration
vault write pki/roles/server-cert \
    allowed_domains="internal.example.com" \
    allow_subdomains=true \
    max_ttl="72h" \
    generate_lease=true \
    key_type="ec" \
    key_bits=256
 
# Request a certificate from Vault
vault write pki/issue/server-cert \
    common_name="api.internal.example.com" \
    ttl="24h"
 
---
# step-ca provisioner for ACME
step ca provisioner add acme --type ACME \
    --require-eab=false \
    --challenge="tls-alpn-01,http-01,dns-01"
 
# Client requesting cert via step CLI
step ca certificate api.internal.example.com \
    cert.pem key.pem \
    --ca-url https://ca.internal.example.com \
    --provisioner acme

The ACME Revolution: The ACME protocol (RFC 8555), pioneered by Let's Encrypt, has transformed certificate management: Standardized automation — Any ACME client works with any ACME server Short-lived certificates — Automatic renewal makes 90-day or shorter lifetimes practical Domain validation automation — HTTP, DNS, and TLS-ALPN challenges Wide adoption — Now used by private CAs, not just Let's Encrypt Organizations can run internal ACME servers (step-ca, Boulder) providing Let's Encrypt-style automation for internal certificates.

The End of Manual Certificate Management

Manual certificate management—generating CSRs, emailing CAs, copying certificates to servers, setting calendar reminders for renewal—is becoming obsolete. Modern infrastructure expects automated certificate lifecycle management. If you're still doing it manually, modernization should be a priority.

Specialized PKI Applications

Beyond web and enterprise PKI, numerous specialized PKI deployments serve specific industries and use cases. Government PKI:

Government PKI Examples

•U.S. Federal PKI (FPKI) — Interconnected PKI for federal agencies; enables cross-agency authentication
•Common Access Card (CAC) — DoD smart card with PKI credentials for personnel
•Personal Identity Verification (PIV) — Civilian federal employee smart card standard (FIPS 201)
•eIDAS (EU) — European framework for electronic identification and trust services
•Estonia e-Residency — National PKI enabling digital identity for citizens and e-residents

Healthcare PKI: DEA EPCS — Electronic Prescribing for Controlled Substances requires PKI-based authentication DirectTrust — PKI for secure health information exchange Certificate policies aligned with HIPAA — Specific assurance levels for protected health information Financial Services: PCI DSS requirements — TLS for cardholder data; certificate management controls SWIFT PKI — Certificates for financial messaging authentication Qualified Electronic Signatures — Legal equivalence to handwritten signatures in many jurisdictions IoT and Device PKI:

IoT PKI Challenges and Solutions
Challenge	Solution Approach
Massive scale (billions of devices)	Automated provisioning, device identity services
Resource constraints	Elliptic curve cryptography, lightweight protocols
Long device lifetimes	Certificate rotation, long-lived roots with short certificates
Limited connectivity	Batch updates, local validation caching
Manufacturing integration	Factory provisioning, secure element injection
Supply chain security	Hardware security modules in devices, attestation

Code Signing PKI: Code signing has its own PKI ecosystem: Extended Validation Code Signing — Requires hardware key storage (HSM or USB token) Timestamping — Proves code was signed while certificate was valid (signature remains valid after expiry) Platform-Specific Requirements: Windows: Authenticode, kernel-mode signing requires WHQL/WHCP Apple: Developer ID, notarization requirement Android: APK signing, Play App Signing Linux packages: GPG-based, but PKI emerging

Emerging: SPIFFE/SPIRE

SPIFFE (Secure Production Identity Framework For Everyone) is an emerging standard for service identity in distributed systems. SPIRE is its reference implementation. It provides automatically rotating X.509 certificates to workloads without requiring traditional CA infrastructure—particularly relevant for Kubernetes and microservices.

PKI Deployment Best Practices

Drawing from industry experience, CA audits, and security incidents, here are the essential best practices for PKI deployment: Key Management:

Key Management Best Practices

•Use HSMs for CA keys — Hardware Security Modules prevent key extraction; required for public trust
•Offline root CAs — Root CA systems should never connect to networks; bring certificates out on removable media
•Key ceremony documentation — Document all root key operations with video, witnesses, and detailed logs
•Key escrow (where appropriate) — Enterprise encryption keys may need escrow for business continuity; never escrow signing keys
•Regular key rotation — Plan for CA key rollover before expiration; overlap validity periods

Certificate Lifecycle:

Certificate Lifecycle Best Practices

•Automate everything — Manual certificate management is error-prone and doesn't scale; use ACME or equivalent
•Monitor expiration — Alert well before certificates expire; 30 days minimum, 60+ for critical systems
•Short validity periods — Shorter is better for security; 90 days is increasingly standard
•Inventory all certificates — You can't manage what you don't know about; scan networks, monitor CT logs
•Renewal before expiration — Renew when 1/3 of validity remains; handles transient failures

Security Operations:

Security Operations Best Practices

•Monitor Certificate Transparency — Set up alerts for your domains; detect mis-issuance quickly
•Use CAA records — Specify which CAs can issue for your domains; prevents unauthorized issuance
•Enable OCSP stapling — Improves performance and privacy; reduces load on CAs
•Incident response plans — Know how to revoke and replace certificates quickly; practice the process
•Separate duties — Different people for key generation, certificate issuance, and audit

caa-record-example.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# DNS CAA Records - Specify which CAs can issue for your domain
 
# Only Let's Encrypt can issue certificates for example.com
example.com.  IN  CAA  0 issue "letsencrypt.org"
 
# Only DigiCert can issue wildcard certificates
example.com.  IN  CAA  0 issuewild "digicert.com"
 
# Report policy violations to security team
example.com.  IN  CAA  0 iodef "mailto:security@example.com"
 
# Prohibit all issuance (for domains you don't use for web)
unused.example.com.  IN  CAA  0 issue ";"
 
# Multiple CAs allowed
example.com.  IN  CAA  0 issue "letsencrypt.org"
example.com.  IN  CAA  0 issue "sectigo.com"
example.com.  IN  CAA  0 issue "digicert.com"

The Most Common Mistake

The single most common PKI failure is certificate expiration causing outages. Major providers (Microsoft, Equifax, LinkedIn, Spotify, and many others) have all suffered public outages due to expired certificates. Automation and monitoring are not optional.

Computer NetworksNetwork Security Protocols

Certificates and PKI

LevelIntermediate

Duration90 mins

TopicNetwork Security Protocols

5 / 5

PKI Infrastructure

The Complete Picture

We've explored X.509 certificates, Certificate Authorities, chains of trust, and revocation mechanisms. Now it's time to see how these pieces combine into Public Key Infrastructure (PKI) —complete systems that enable secure digital communications at scale. PKI isn't just about individual certificates. It's an ecosystem encompassing: Policies that define what certificates can be issued and for what purposes Procedures for identity verification, key management, and incident response Technology including CAs, directory services, OCSP responders, and key management systems Trust relationships between organizations, users, and automated systems Governance structures that ensure accountability and compliance From the web PKI securing billions of HTTPS connections to enterprise PKIs protecting corporate networks to specialized systems in healthcare, finance, and government—PKI implementations vary dramatically based on requirements. This page examines how PKI is deployed across these contexts, providing the complete picture of PKI infrastructure.

What You Will Master

By the end of this page, you will understand the complete PKI ecosystem: web PKI architecture and its governance, enterprise PKI design patterns, trust store management, specialized PKI applications, and best practices for deploying and managing PKI in various contexts.

The Web PKI Ecosystem

Web PKI is the PKI that secures HTTPS, the encrypted web. It's the most visible PKI system, used by billions of people daily—typically without awareness of its existence. Components of Web PKI:

Web PKI Components

•Certificate Authorities — Organizations that issue TLS certificates (DigiCert, Let's Encrypt, Sectigo, etc.)
•Root Programs — Browser/OS vendors that decide which CAs to trust (Mozilla, Microsoft, Apple, Google)
•CA/Browser Forum — Industry body that sets standards (Baseline Requirements)
•Certificate Transparency — Public logs of all issued certificates for auditing
•OCSP Responders — Services providing real-time certificate status
•Domain Registrars — Issue domain control for validation
•Trust Stores — Collections of root certificates bundled with browsers/OSes

The Governance Structure: Web PKI has evolved a complex governance structure: CA/Browser Forum: Industry consortium of CAs and browser vendors Creates binding requirements (Baseline Requirements, EV Guidelines) Voting members include major CAs and all major browser vendors Consensus-driven but browser vendors have ultimate power Root Programs: Each major browser/OS maintains its own root program: Mozilla Root Store Policy — Open, community-driven, influential despite Firefox's market share Microsoft Root Certificate Program — Windows and Edge; significant enterprise influence Apple Root Certificate Program — macOS, iOS, Safari; aligned with Mozilla Google Chrome Root Program — New, transitioning from OS trust stores Root programs can and do remove CAs for violations. Symantec's removal from Chrome (2017-2018) affected a third of all TLS certificates—demonstrating the power these programs hold.

The Power Dynamic

Browser vendors have ultimate authority. CAs need browser trust to remain viable businesses. This asymmetry has enabled browsers to push security improvements that CAs might otherwise resist—shorter certificate lifespans, Certificate Transparency requirements, deprecated algorithms—knowing CAs must comply or be distrusted.

Certificate Transparency: Auditing the PKI

Certificate Transparency (CT) is a revolutionary addition to PKI that makes all certificate issuance publicly auditable. Proposed by Google engineers and standardized in RFC 6962, CT fundamentally changes the PKI trust model. The Problem CT Solves: Before CT, certificate mis-issuance was essentially invisible: CA issues fraudulent certificate for google.com Unless Google happened to intercept the certificate in use, they'd never know Attacker could use the certificate for targeted MITM attacks No audit trail, no accountability How CT Works:

Certificate Transparency Flow

•Logging — CA submits certificate (or pre-certificate) to CT logs before or shortly after issuance
•SCT Issuance — Log returns a Signed Certificate Timestamp (SCT), a cryptographic promise that the certificate is logged
•Embedding — SCT is embedded in certificate, delivered via TLS extension, or OCSP stapling
•Verification — Browser verifies SCTs are present and valid; rejects certificates without them
•Monitoring — Domain owners monitor logs for unauthorized certificates bearing their domains
•Auditing — Anyone can audit logs for consistency and completeness

ct-sct-example.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# Example SCT embedded in a certificate
X509v3 extensions:
    CT Precertificate SCTs:
        Signed Certificate Timestamp:
            Version   : v1 (0x0)
            Log ID    : E8:3E:D0:DA:...(Google 'Argon2024' log)
            Timestamp : Jan 15 00:00:01.234 2024 UTC
            Extensions: none
            Signature : ecdsa-with-SHA256
                        30:45:02:20:...
        Signed Certificate Timestamp:
            Version   : v1 (0x0)
            Log ID    : 48:B0:E3:6B:...(DigiCert Yeti2024 log)
            Timestamp : Jan 15 00:00:02.567 2024 UTC
            Extensions: none
            Signature : ecdsa-with-SHA256
                        30:46:02:21:...
 
# Chrome requires SCTs from at least two different log operators
# This prevents a single compromised log from enabling undetected mis-issuance
 
# View SCTs from a live server
echo | openssl s_client -connect example.com:443 2>/dev/null | \
    openssl x509 -noout -ext "ct_precert_scts"

CT Log Requirements: Chrome's CT policy requires: SCTs from at least two different log operators Logs must be from Google's approved log list Log operator diversity (not all SCTs from same company) Monitoring for Domain Owners: Domain owners should monitor CT logs for unauthorized certificates: crt.sh (Sectigo) — Web search for certificates by domain Google Transparency Report — Certificate search Facebook Certificate Transparency Monitoring — Alerts for your domains Custom monitors — Parse CT logs for matching domains Companies like Meta, Google, and financial institutions actively monitor logs and have caught mis-issuance within hours of occurrence.

CT's Impact

Certificate Transparency has fundamentally improved PKI accountability. Mis-issuance that would have been invisible is now publicly discoverable. CAs know that every certificate they issue is logged and auditable. This has driven significant improvements in CA practices and enabled faster incident detection and response.

Trust Store Management

A trust store is the collection of root certificates that a system trusts. Understanding trust store management is crucial for both security and troubleshooting. Trust Store Locations by Platform:

Trust Store Locations
Platform	Location	Management Tool
Windows	Certificate Store (certmgr.mmc)	certmgr.msc, PowerShell
macOS	Keychain Access (/System/Library/Keychains/)	security command, Keychain Access.app
Linux (Debian/Ubuntu)	/etc/ssl/certs/, /usr/share/ca-certificates/	update-ca-certificates
Linux (RHEL/CentOS)	/etc/pki/tls/certs/, /etc/pki/ca-trust/	update-ca-trust
Java	$JAVA_HOME/lib/security/cacerts	keytool
Firefox	NSS database (uses own trust store)	certutil, about:preferences#privacy
Chrome (Windows)	Windows Certificate Store	(uses OS store)
Chrome (Linux)	NSS database or OS store	certutil

trust-store-management.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
# Linux (Debian/Ubuntu): Add a custom CA certificate
sudo cp custom-ca.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates
 
# Linux (RHEL/CentOS): Add a custom CA certificate
sudo cp custom-ca.pem /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust extract
 
# macOS: Add a trusted certificate
sudo security add-trusted-cert -d -r trustRoot \
    -k /Library/Keychains/System.keychain custom-ca.pem
 
# Java: Add certificate to cacerts
keytool -importcert -alias custom-ca \
    -keystore $JAVA_HOME/lib/security/cacerts \
    -file custom-ca.pem \
    -storepass changeit
 
# View certificates in Java trust store
keytool -list -keystore $JAVA_HOME/lib/security/cacerts \
    -storepass changeit | head -50
 
# Firefox: Add certificate to NSS database
certutil -A -n "Custom CA" -t "TC,C,T" \
    -i custom-ca.pem -d sql:$HOME/.pki/nssdb
 
# Windows PowerShell: Add certificate to machine store
Import-Certificate -FilePath custom-ca.cer \
    -CertStoreLocation Cert:\LocalMachine\Root
 
# List Windows root certificates
Get-ChildItem -Path Cert:\LocalMachine\Root

Enterprise Trust Store Management: Enterprise environments need centralized trust store management: Group Policy (Windows): Distribute root certificates via GPO Certificates pushed to all domain-joined machines Enables enterprise CA trust without manual installation Configuration Management: Ansible, Puppet, Chef can deploy certificates to Linux systems Ensures consistent trust across fleet Version control for trust store changes MDM (Mobile Device Management): Deploy certificates to iOS/Android devices Required for enterprise apps and internal sites Can enforce certificate policies Security Considerations:

Trust Store Security

Adding a root certificate grants complete trust for any certificate that CA issues. Before adding any root, verify: Who operates this CA? What domains might it issue for? Is it Name Constrained? Malicious root installation is a common attack vector for TLS interception and malware.

Enterprise PKI Design

Many organizations run private PKI for internal use, providing certificates without depending on public CAs. Use Cases for Enterprise PKI:

Enterprise PKI Applications

•Internal TLS — Secure internal websites, APIs, microservices without paying for public certificates
•Client Authentication — Mutual TLS (mTLS) for service-to-service authentication
•Smart Card/PIV Authentication — Physical security credentials for building access and login
•Code Signing — Sign internal applications and scripts
•Email Encryption — S/MIME certificates for encrypted internal email
•Document Signing — Digital signatures on internal documents
•VPN Authentication — Certificate-based VPN client authentication
•WiFi/802.1X — EAP-TLS authentication for network access

Typical Enterprise PKI Architecture: ┌─────────────────┐ │ Offline Root │ │ CA │ │ (Air-gapped) │ └────────┬────────┘ │ ┌────────────────┼────────────────┐ │ │ │ ┌───────┴───────┐ ┌──────┴──────┐ ┌───────┴───────┐ │ Issuing CA #1 │ │ Issuing CA │ │ Issuing CA #3 │ │ (TLS Certs) │ │ #2 (Users) │ │ (Code Sign) │ └───────┬───────┘ └──────┬──────┘ └───────┬───────┘ │ │ │ Servers Smart Cards Dev Machines Design Principles: Offline Root CA — Root private key never touches a network; stored in HSM in secure facility Purpose-Specific Issuing CAs — Separate CAs for different certificate types; limits blast radius of compromise Automated Issuance — Self-service portals, ACME servers, or integration with Active Directory Certificate Services (ADCS) Name Constraints — If root is added to devices, constrain to company domains Short Validity for Automated Certs — Internal certificates can have short lifetimes with automated renewal

enterprise-ca-openssl.cnf
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
# OpenSSL configuration for enterprise root CA
 
[ ca ]
default_ca = enterprise_root_ca
 
[ enterprise_root_ca ]
dir               = /ca/root
database          = $dir/index.txt
serial            = $dir/serial
certificate       = $dir/ca.crt
private_key       = $dir/ca.key
default_days      = 3650          # 10 years for root
default_md        = sha256
policy            = policy_strict
 
[ policy_strict ]
countryName             = match
organizationName        = match
commonName              = supplied
 
[ v3_issuing_ca ]
subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints       = critical, CA:true, pathlen:0
keyUsage               = critical, digitalSignature, cRLSign, keyCertSign
nameConstraints        = critical, @name_constraints
 
[ name_constraints ]
permitted;DNS.0 = .internal.example.com
permitted;DNS.1 = .corp.example.com
permitted;email.0 = .example.com
permitted;IP.0 = 10.0.0.0/255.0.0.0
permitted;IP.1 = 192.168.0.0/255.255.0.0
excluded;IP.0 = 0.0.0.0/0.0.0.0     # No public IPs
 
[ v3_end_entity ]
subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid,issuer
basicConstraints       = critical, CA:false
keyUsage               = critical, digitalSignature, keyEncipherment
extendedKeyUsage       = serverAuth, clientAuth

Modern Enterprise PKI

Consider solutions like HashiCorp Vault, step-ca, or cloud-based private CAs (AWS Private CA, Google Cloud CA Service) for modern enterprise PKI. These provide APIs, automation, and integration that manual OpenSSL/ADCS setups lack.

Modern PKI Tooling

The PKI landscape has evolved beyond manual OpenSSL commands and ADCS. Modern tools provide automation, APIs, and integration with contemporary infrastructure. Certificate Management Solutions:

PKI and Certificate Management Tools
Tool	Type	Best For	Key Features
Let's Encrypt / certbot	Public CA + Client	Web server TLS	Free, automated, ACME protocol
HashiCorp Vault PKI	Private CA	Microservices, Kubernetes	API-driven, short-lived certs, secrets management
step-ca / Smallstep	Private CA	Modern enterprises	ACME support, JWK provisioning, OAuth integration
CFSSL	Private CA	Container environments	JSON-based, Kubernetes integration
AWS Private CA	Cloud-managed	AWS-heavy environments	Managed HSM, IAM integration
Google Cloud CA Service	Cloud-managed	GCP environments	Tiered CA hierarchy, Kubernetes integration
cert-manager	Certificate controller	Kubernetes	Automates certificate lifecycle in K8s
Venafi	Enterprise management	Large enterprises	Visibility, policy enforcement, compliance

modern-pki-examples.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
# cert-manager Certificate resource for Kubernetes
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: api-tls-cert
  namespace: production
spec:
  secretName: api-tls-secret
  duration: 2160h    # 90 days
  renewBefore: 360h  # Renew 15 days before expiry
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  commonName: api.example.com
  dnsNames:
    - api.example.com
    - api-internal.example.com
 
---
# HashiCorp Vault PKI role configuration
vault write pki/roles/server-cert \
    allowed_domains="internal.example.com" \
    allow_subdomains=true \
    max_ttl="72h" \
    generate_lease=true \
    key_type="ec" \
    key_bits=256
 
# Request a certificate from Vault
vault write pki/issue/server-cert \
    common_name="api.internal.example.com" \
    ttl="24h"
 
---
# step-ca provisioner for ACME
step ca provisioner add acme --type ACME \
    --require-eab=false \
    --challenge="tls-alpn-01,http-01,dns-01"
 
# Client requesting cert via step CLI
step ca certificate api.internal.example.com \
    cert.pem key.pem \
    --ca-url https://ca.internal.example.com \
    --provisioner acme

The ACME Revolution: The ACME protocol (RFC 8555), pioneered by Let's Encrypt, has transformed certificate management: Standardized automation — Any ACME client works with any ACME server Short-lived certificates — Automatic renewal makes 90-day or shorter lifetimes practical Domain validation automation — HTTP, DNS, and TLS-ALPN challenges Wide adoption — Now used by private CAs, not just Let's Encrypt Organizations can run internal ACME servers (step-ca, Boulder) providing Let's Encrypt-style automation for internal certificates.

The End of Manual Certificate Management

Manual certificate management—generating CSRs, emailing CAs, copying certificates to servers, setting calendar reminders for renewal—is becoming obsolete. Modern infrastructure expects automated certificate lifecycle management. If you're still doing it manually, modernization should be a priority.

Specialized PKI Applications

Beyond web and enterprise PKI, numerous specialized PKI deployments serve specific industries and use cases. Government PKI:

Government PKI Examples

•U.S. Federal PKI (FPKI) — Interconnected PKI for federal agencies; enables cross-agency authentication
•Common Access Card (CAC) — DoD smart card with PKI credentials for personnel
•Personal Identity Verification (PIV) — Civilian federal employee smart card standard (FIPS 201)
•eIDAS (EU) — European framework for electronic identification and trust services
•Estonia e-Residency — National PKI enabling digital identity for citizens and e-residents

Healthcare PKI: DEA EPCS — Electronic Prescribing for Controlled Substances requires PKI-based authentication DirectTrust — PKI for secure health information exchange Certificate policies aligned with HIPAA — Specific assurance levels for protected health information Financial Services: PCI DSS requirements — TLS for cardholder data; certificate management controls SWIFT PKI — Certificates for financial messaging authentication Qualified Electronic Signatures — Legal equivalence to handwritten signatures in many jurisdictions IoT and Device PKI:

IoT PKI Challenges and Solutions
Challenge	Solution Approach
Massive scale (billions of devices)	Automated provisioning, device identity services
Resource constraints	Elliptic curve cryptography, lightweight protocols
Long device lifetimes	Certificate rotation, long-lived roots with short certificates
Limited connectivity	Batch updates, local validation caching
Manufacturing integration	Factory provisioning, secure element injection
Supply chain security	Hardware security modules in devices, attestation

Code Signing PKI: Code signing has its own PKI ecosystem: Extended Validation Code Signing — Requires hardware key storage (HSM or USB token) Timestamping — Proves code was signed while certificate was valid (signature remains valid after expiry) Platform-Specific Requirements: Windows: Authenticode, kernel-mode signing requires WHQL/WHCP Apple: Developer ID, notarization requirement Android: APK signing, Play App Signing Linux packages: GPG-based, but PKI emerging

Emerging: SPIFFE/SPIRE

SPIFFE (Secure Production Identity Framework For Everyone) is an emerging standard for service identity in distributed systems. SPIRE is its reference implementation. It provides automatically rotating X.509 certificates to workloads without requiring traditional CA infrastructure—particularly relevant for Kubernetes and microservices.

PKI Deployment Best Practices

Drawing from industry experience, CA audits, and security incidents, here are the essential best practices for PKI deployment: Key Management:

Key Management Best Practices

•Use HSMs for CA keys — Hardware Security Modules prevent key extraction; required for public trust
•Offline root CAs — Root CA systems should never connect to networks; bring certificates out on removable media
•Key ceremony documentation — Document all root key operations with video, witnesses, and detailed logs
•Key escrow (where appropriate) — Enterprise encryption keys may need escrow for business continuity; never escrow signing keys
•Regular key rotation — Plan for CA key rollover before expiration; overlap validity periods

Certificate Lifecycle:

Certificate Lifecycle Best Practices

•Automate everything — Manual certificate management is error-prone and doesn't scale; use ACME or equivalent
•Monitor expiration — Alert well before certificates expire; 30 days minimum, 60+ for critical systems
•Short validity periods — Shorter is better for security; 90 days is increasingly standard
•Inventory all certificates — You can't manage what you don't know about; scan networks, monitor CT logs
•Renewal before expiration — Renew when 1/3 of validity remains; handles transient failures

Security Operations:

Security Operations Best Practices

•Monitor Certificate Transparency — Set up alerts for your domains; detect mis-issuance quickly
•Use CAA records — Specify which CAs can issue for your domains; prevents unauthorized issuance
•Enable OCSP stapling — Improves performance and privacy; reduces load on CAs
•Incident response plans — Know how to revoke and replace certificates quickly; practice the process
•Separate duties — Different people for key generation, certificate issuance, and audit

caa-record-example.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# DNS CAA Records - Specify which CAs can issue for your domain
 
# Only Let's Encrypt can issue certificates for example.com
example.com.  IN  CAA  0 issue "letsencrypt.org"
 
# Only DigiCert can issue wildcard certificates
example.com.  IN  CAA  0 issuewild "digicert.com"
 
# Report policy violations to security team
example.com.  IN  CAA  0 iodef "mailto:security@example.com"
 
# Prohibit all issuance (for domains you don't use for web)
unused.example.com.  IN  CAA  0 issue ";"
 
# Multiple CAs allowed
example.com.  IN  CAA  0 issue "letsencrypt.org"
example.com.  IN  CAA  0 issue "sectigo.com"
example.com.  IN  CAA  0 issue "digicert.com"

The Most Common Mistake

The single most common PKI failure is certificate expiration causing outages. Major providers (Microsoft, Equifax, LinkedIn, Spotify, and many others) have all suffered public outages due to expired certificates. Automation and monitoring are not optional.

PKI Infrastructure

The Complete Picture

The Web PKI Ecosystem

Certificate Transparency: Auditing the PKI

Trust Store Management

Enterprise PKI Design

Modern PKI Tooling

Specialized PKI Applications

PKI Deployment Best Practices

There’s more to understand.

PKI Infrastructure

The Complete Picture

The Web PKI Ecosystem

Certificate Transparency: Auditing the PKI

Trust Store Management

Enterprise PKI Design

Modern PKI Tooling

Specialized PKI Applications

PKI Deployment Best Practices

There’s more to understand.