Public Key Infrastructure

What PKI Is and How the Chain of Trust Works

PKI (Public Key Infrastructure) is the framework of hardware, software, policies, and procedures that manages digital certificates and public-key encryption.
PKI enables the trust relationship that makes HTTPS, code signing, email encryption (S/MIME), and VPN authentication possible.
When you connect to a website over HTTPS, PKI answers the question: “Is this really the server I think it is?” — PKI components: (a) Certificate Authority (CA) — a trusted entity that issues digital certificates. The CA’s digital signature vouches that the public key in the certificate belongs to the named entity. (b) Registration Authority (RA) — verifies the identity of entities requesting certificates. (c) Digital certificate — binds an identity to a public key, signed by the CA. (d) Certificate Revocation List (CRL) — a published list of certificates that were revoked before their expiration date. (e) Online Certificate Status Protocol (OCSP) — a real-time protocol to check if a certificate is still valid without downloading the full CRL.

Chain of Trust — Root, Intermediate, and Leaf Certificates

Root CA (self-signed, ultra-protected)
   └─ signs Intermediate CA 1
        └─ signs Intermediate CA 2
             └─ signs Leaf (server) certificate for bank.com

Root CA: The trust anchor. Its certificate is self-signed and pre-installed in OS/browser trust stores. If the root CA is compromised, everything below it is compromised.
Intermediate CA: Signed by the root CA. Issued to reduce risk — if an intermediate CA is compromised, only its issued certificates are affected. The root CA remains trusted.
Leaf certificate: The end-entity certificate (e.g., for a website’s TLS, code signing). Signed by an intermediate CA.

Detection implications: When investigating suspicious TLS traffic, check the certificate chain. A leaf certificate directly signed by a root CA (no intermediate) is unusual and may indicate a forged certificate or misconfigured infrastructure. Most legitimate certificates chain through 2-3 intermediates.

Operational Failures Attackers Exploit

CA Compromise — The Root of All Trust Erosion

When a Certificate Authority is compromised, attackers can issue valid certificates for any domain.

Incident	Year	Impact
DigiNotar	2011	Attacker issued 531 rogue certificates including *.google.com. DigiNotar was revoked by major browsers and went bankrupt.
Comodo	2011	Attacker compromised a Comodo RA and issued certificates for Google, Yahoo, Skype, and others. Less severe because the RA was the entry point, not the root CA.
Symantec	2017	Systematic mis-issuance of certificates (non-compromise, but lack of oversight). Symantec’s CA was distrusted by Google Chrome after years of non-compliance.
Trustico	2018	Admin claimed to have bulk-deleted 50,000 private keys sent via email — exposing the risk of centralized key management.

Detection: When a CA breach is announced, check your environment for certificates issued by that CA. Tools like crt.sh show all certificates currently valid per CA. Any certificate issued by the compromised CA during the breach window is suspect.

Rogue Certificates — What to Look For

Indicator	What It Suggests
Certificate issued by unexpected CA	The server’s cert chain includes a CA not in your organization’s normal set
Certificate for internal domain signed by external CA	`corp.internal` should not have a certificate issued by a public CA
Certificate for sensitive domain (bank.com, admin.google.com) issued by small/obscure CA	Potential compromise of that CA or a mis-issued cert
Certificate issued outside normal hours	CA certificate issuance at 3 AM local time is unusual
Certificate that was pre-announced before domain registration	The cert was created before the domain even existed — strong indicator of malicious intent
Self-signed certificate for a public-facing service	Legitimate public services use CA-signed certificates. Self-signed cert on a public-facing server suggests C2 infrastructure or a phishing site

OCSP and CRL — Why Revocation Often Fails

Certificate revocation is the weakest link in PKI. When a certificate is compromised (private key leaked), it should be revoked — but the system has fundamental flaws.

Revocation Method	Mechanism	Failure Mode
CRL	CA publishes list of revoked cert serial numbers. Client downloads periodically.	CRLs can be megabytes in size. Clients often skip downloads due to size or performance. Some browsers only check after a connection fails.
OCSP	Client asks CA’s OCSP responder “is this cert still valid?” Real-time check.	OCSP responder can be slow or unavailable. Most browsers use “soft-fail” — if OCSP is unreachable, the cert is treated as valid (fail-open). This is the gap attackers exploit.
OCSP Stapling	Server sends a time-stamped OCSP response along with the certificate during the TLS handshake. Server caches the response periodically.	Best available option, but not universally deployed. Requires server configuration.

Detection implications: If you suspect a compromised certificate is in use, check if the server supports OCSP stapling. If it does not, the attacker cannot provide a valid OCSP response — which is suspicious for a legitimate service but expected for attacker-controlled infrastructure.

Certificate Transparency (CT) — The Primary Detection Tool

Certificate Transparency (RFC 6962) is an open system that logs every publicly issued TLS certificate. Anyone can query the logs to find certificates for any domain.

Detection workflow using CT:

Search crt.sh for your organization’s domain
Look for certificates issued for domains you do not own (typosquats, lookalikes)
Look for certificates issued by CAs you do not use
Look for certificates issued with Subject Alternative Names that are not legitimate — an attacker who has a rogue cert for bank.com may list login.bank.com, admin.bank.com in the SANs

Search crt.sh for lookalike domains:

# Search for certificates containing variations of your domain
curl -s "https://crt.sh/?q=%25.example.com&output=json" | jq '.[].name_value'
# Look for: exarnple.com, examp1e.com, example-login.com, etc.

Detection — Investigating Suspicious TLS Traffic

JA3 Fingerprinting

JA3 creates a fingerprint of the TLS client (the browser or application) based on the TLS handshake — specifically the set of cipher suites, TLS extensions, and elliptic curves the client offers. JA3S fingerprints the server response.

What JA3 catches: A malware TLS client that uses a non-standard cipher suite order, omits common extensions, or bundles unusual TLS versions will have a JA3 fingerprint that differs from standard browsers.
What JA3 misses: Attackers who use the system’s TLS library (e.g., a Python script using requests on Windows) will have the same JA3 as legitimate software.
Detection: Check for JA3 fingerprints that are not associated with any known legitimate application in your environment. Compare against threat intelligence of known-bad JA3 hashes.

SPL query — detect unusual JA3 fingerprints:

index=network sourcetype=ja3
| search ja3_hash IN (known_good_hashes)
| where ja3_hash NOT IN (good_hashes)
| stats values(ja3_hash) as JA3, values(ja3s_hash) as JA3S, values(user_agent) as UA by src_ip, dest_ip
| eval alert = "SUSPICIOUS — unusual TLS fingerprint from " . src_ip

Self-Signed and Expired Certificates

C2 servers commonly use self-signed certificates because they avoid the cost and audit trail of CA-signed certificates.

Indicators to check:

Indicator	Suspicious For…
Self-signed certificate	C2 infrastructure, phishing pages, test environments exposed to internet
Certificate expired > 30 days	Abandoned infrastructure — or C2 that does not rotate certs
Certificate issued to “localhost” or IP address	Dev/test systems or attacker infrastructure
Certificate CN does not match the domain	Common Name `localhost` or IP address for a public-facing site is suspicious
Recently issued certificate on an old domain	Domain that existed for years suddenly gets a new cert = possible takeover

SPL query — detect outbound connections with self-signed certificates:

index=proxy sourcetype=ssl_cert
| search issuercn!="*" (self-signed check — issuer matches subject)
| where dest_port=443
| stats values(subjectcn) as SubjectCN, values(issuerorg) as IssuerOrg by src_ip, dest_ip, dest_port
| eval self_signed = if(subjectcn == IssuerOrg, "YES", "NO")
| where self_signed = "YES"
| eval alert = "HIGH — outbound connection to " . dest_ip . " with self-signed certificate"

PKI Hardening for Organizations

Control	What It Prevents	Implementation
Certificate Pinning	Connection to rogue certificate even if CA is compromised	Pin the expected certificate or public key in the client application. Fragile — avoid for long-lived apps.
Certificate Transparency Monitoring	Rogue certificate issued for your domain	Monitor crt.sh for your domains. Set up CT log monitoring service.
OCSP Must-Staple	Browser connection to a server that cannot provide a valid OCSP response	Add the `must-staple` extension to certificates. Server must provide OCSP during TLS handshake or browser rejects.
Short-lived certificates	Limits the window of compromise	Use ACME protocol (Let’s Encrypt) for 90-day certificates. Revocation becomes less important.
Private CA for internal services	Prevents external CAs from issuing certs for internal domains	Deploy an internal CA for `corp.example.com`. Trust it on all domain-joined devices.
HSTS Preloading	Prevents SSL stripping	Submit your domain to the HSTS preload list. Browsers will always use HTTPS.

Active Directory Basics — covers the active directory basics concepts
AWS Misconfigurations — detection and response for T1525, T1613 techniques
Cloud Security Fundamentals — detection and response for T1525 techniques