Bypassing mTLS Authentication via Certificate Chain Manipulation

TLDR: Mutual TLS is often treated as a silver bullet for authentication, but improper implementation in Java-based frameworks like Keycloak and Bouncy Castle creates critical bypass vectors. Attackers can manipulate certificate chains or exploit insecure certificate store lookups to achieve authentication bypass, SSRF, or even RCE. Security researchers should audit how applications extract and validate peer certificates, specifically looking for logic that trusts user-supplied certificate chains without strict signature verification.

Mutual TLS (mTLS) is frequently deployed as the gold standard for service-to-service authentication. The assumption is simple: if a client presents a certificate signed by a trusted Certificate Authority (CA), the connection is secure. However, this assumption falls apart when developers treat the certificate chain as a trusted input rather than a cryptographic proof. Recent research presented at Black Hat 2023 exposes how common Java frameworks fail to handle certificate chains correctly, turning a security feature into a massive attack surface.

The Flaw in Chain Validation

Most developers assume that if a library provides a method to extract a peer certificate, that certificate is inherently valid. In Java, methods like sslSession.getPeerCertificates() return an array of certificates. The critical mistake is assuming the first certificate in that array is the only one that matters.

The mTLS specification allows clients to send a full chain of certificates. The server is responsible for building a path from the client certificate to a trusted root. If an application iterates through this array and performs logic based on the first certificate it finds—or worse, searches for a certificate that matches specific criteria—it opens the door to authentication bypass.

Consider CVE-2023-2422, a vulnerability in Keycloak. The application iterates over the provided certificate chain to find one that matches a specific client ID. Because the server only verifies the signature of the first certificate in the chain, an attacker can provide a legitimate certificate followed by a self-signed certificate containing their own malicious data. The application logic, failing to enforce strict chain validation, accepts the attacker-controlled certificate as the primary identity.

Certificate Stores as Injection Vectors

Beyond chain validation, the way applications query certificate stores is a goldmine for Injection attacks. When a system does not store all intermediate certificates locally, it often uses a certificate store to fetch them dynamically via protocols like LDAP or HTTP.

The vulnerability lies in how these stores construct queries. If an application uses the subject field of a user-supplied certificate to build an LDAP filter, it creates an LDAP injection vulnerability. In CVE-2023-33201, the Bouncy Castle library was found to be susceptible to this exact issue. By crafting a certificate with a subject field containing LDAP filter syntax, an attacker can manipulate the query logic.

// Example of vulnerable LDAP filter construction
String filter = "(&(cn=" + certificate.getSubjectDN().getName() + ")(userCertificate=*))";

If an attacker provides a certificate with a subject like cn=Client)(userPassword=123, the resulting filter becomes (&(cn=Client)(userPassword=123)(userCertificate=*)). This allows an attacker to perform blind LDAP injection, potentially exfiltrating sensitive data or bypassing authentication checks entirely.

SSRF and RCE via Revocation Checks

Revocation checking is another area where implementation often goes wrong. Protocols like CRL (Certificate Revocation List) and OCSP (Online Certificate Status Protocol) require the server to fetch data from a URL specified within the certificate itself.

If an application performs these checks before fully validating the certificate signature, it becomes an SSRF oracle. An attacker can provide a certificate pointing to an internal service, forcing the server to make requests to sensitive endpoints. In the case of CVE-2023-28857 in Apereo CAS, the application would fetch revocation data from a user-supplied LDAP URL. Because the library used for these connections was vulnerable to JNDI resolution issues—similar to the classic CVE-2018-2633—this SSRF could be escalated to Remote Code Execution.

Practical Testing for Pentesters

When testing an application that uses mTLS, do not assume the authentication is impenetrable. Start by inspecting the certificate validation logic. If you are performing a black-box assessment, use OpenSSL to craft custom certificate chains.

1. Chain Manipulation: Attempt to send a chain where the first certificate is valid, but subsequent certificates contain malicious attributes or point to attacker-controlled revocation servers.
2. Input Injection: If the application logs the certificate subject or uses it in any backend query, inject common injection payloads (LDAP, SQL, or command injection) into the certificate's Distinguished Name (DN) fields.
3. Revocation Probing: Check if the application attempts to reach out to external URLs when you present a certificate with custom AIA (Authority Information Access) or CRL distribution point extensions. Use a tool like netcat to listen for incoming connections from the target server.

Defensive Hardening

Defenders must treat certificate data as untrusted user input. Never use the subject or other fields from a certificate to construct database queries or system commands without rigorous sanitization. Ensure that your TLS stack is configured to perform strict path validation against a known, static set of trusted root certificates. Disable dynamic fetching of revocation data from URLs provided in the certificate unless those URLs are strictly allowlisted and the fetching mechanism is hardened against SSRF and JNDI injection.

The next time you see an mTLS-protected endpoint, look past the handshake. The real bugs are often hidden in the logic that processes the certificate after the connection is established.