Preface: In Bouncy Castle Java, a Stapled OCSP (Online Certificate Status Protocol) response refers to a mechanism where an SSL/TLS server attaches a pre-fetched, digitally signed proof of its certificate’s validity directly into the TLS handshake. Instead of requiring the client (like a web browser or Java client application) to contact a third-party Certificate Authority (CA) to check if a certificate is revoked, the client reads the “stapled” status response provided immediately by the server.
Background: If the cryptographic flaw happens entirely within the user-space Java framework (Bouncy Castle/Conscrypt), why does your architecture slide map all the way down to the Kernel and the TEE/KeyMint TA? Doesn’t the TEE protect itself?
That is a crucial distinction. The TEE and KeyMint TA are cryptographically secure, but they operate on a ‘garbage in, garbage out’ model regarding external network state. The TEE handles hardware-bound keys and cryptographic operations, but it relies on the rich user-space Java layer to fetch, parse, and validate the transport-layer revocation status—like the stapled OCSP response. If the Bouncy Castle or Conscrypt validation engine tells the system a certificate is valid when it is actually revoked, the user-space daemon passes valid parameters down the stack. The architecture map highlights that a high-level logic flaw completely undermines our low-level hardware protections, making it a full-stack security concern.
If an attacker is leveraging a mismatched CertID from a completely different, valid certificate, wouldn’t the cryptographic signature on that OCSP response fail when checked against the target server’s certificate chain?
No, and that is exactly why this design weakness is so deceptive. The attacker intercepts the connection via a Man-in-the-Middle attack and presents a revoked certificate. However, they staple a valid OCSP response belonging to a completely different, legitimate website that happens to be signed by the same Intermediate Certificate Authority (CA). Because both certificates share the same issuer, the Bouncy Castle engine successfully verifies the CA’s signature on the stapled token and marks it cryptographically valid. Because the original code omitted the strict identity binding check between the token’s internal serial number and the server’s actual certificate serial number, the mismatch went unnoticed.
Vulnerability details: CVE-2026-58062 – In Bouncy Castle for Java before 1.85, Stapled OCSP response accepted without binding to the checked certificate. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series).
Official announcement: Please refer to the link for details – https://nvd.nist.gov/vuln/detail/CVE-2026-58062