mTLS: When Certificate Authentication is Done Wrong
summary
Mutual TLS deployments often break when apps trust the wrong certificate in the chain: Java TLS verifies the first certificate only, but some code iterates and accepts a later cert’s subject — exploited to impersonate users against Keycloak by sending a fake chain. Certificate stores and AIA/CRL URLs lead to LDAP injection via subject and CRL/OCSP URL SSRF, and reverse proxies that forward client cert headers without revalidating let any internal host spoof identities. Fixes: validate the first cert, sanitize certificate fields before LDAP/SQL use, and perform revocation/network checks after signature verification.
AI-written summary · about
chapters (5)
related talks
33mHow TLS Can Get You Hacked — When Encryption Becomes Trust
48mChain of Fools: An Exploration of Certificate Chain Validation Mishaps
31mPKI the Wrong Way: Simple TLS Mistakes and Surprising Consequences
30mHashiTLS: Demystifying Security Certs
31mPractical TLS Advice for Large Infrastructure
31mHow We Solved TLS at Scale: Self-Service, Multi-Tenant Cert-manager
28mTrustBase: An Architecture to Repair and Strengthen...
46mSelf-Signed, Why Not! Exploiting Insecure Certificate Validation In iOS And macOS