CVE-2026-45388

In OCaml-TLS before 2.1.0, the client implementation does insufficient checks of the certificate provided by the server, which allows impersonation with certificates that are not meant for server authentication (because of KeyUsage and ExtendedKeyUsage).

In OCaml-TLS before 2.1.0, the client implementation does insufficient checks of the certificate provided by the server, which allows impersonation with certificates that are not meant for server authentication (because of KeyUsage and ExtendedKeyUsage).

In OCaml-TLS before 2.1.0, the client implementation does insufficient checks of the certificate provided by the server, which allows impersonation with certificates that are not meant for server authentication (because of KeyUsage and ExtendedKeyUsage).

In OCaml-TLS before 2.1.0, the client implementation does insufficient checks of the certificate provided by the server, which allows impersonation with certificates that are not meant for server authentication (because of KeyUsage and ExtendedKeyUsage).

The ocaml-TLS 1.3 client does not validate the KeyUsage and ExtendedKeyUsage extensions of the server certificate. This can lead to impersonation with a certificate issued to a client.

Scenario

Every employee at a major bank carries a smart card. The card holds a clientAuth certificate issued by the bank's corporate PKI: identifying the employee for VPN, for badge access, for signing emails. The certificate's Extended Key Usage field marks it "TLS client, not TLS server" — the bank's own CA states what the cert may and may not do. To an ocaml-tls TLS 1.3 client, the marking is invisible. A laptop pulled from a desk, a smart card left in a coffee shop, malware on a workstation — anyone holding any clientAuth cert from any CA in the trust store, with a SAN naming a hostname an ocaml-tls client connects to, impersonates that hostname as a TLS 1.3 server. The same hole catches public-CA misissuance, codeSigning certs with DNS SANs, S/MIME certs with DNS SANs. Any cert in any non-server class becomes a TLS 1.3 server cert.

RFC 5280 §4.2.1.12 binds a cert with an Extended Key Usage extension to the indicated purposes; RFC 8446 §4.4.2.4 carries the constraint into TLS 1.3. ocaml-tls enforces it on its TLS 1.2 path — validate_keyusage in handshake_client.ml:201 checks for Server_auth, wired to answer_certificate_RSA and answer_certificate_DHE. When TLS 1.3 was added, a separate answer_certificate was written in handshake_client13.ml; the EKU check was not ported.

Detailed description

ocaml-tls clients complete the TLS 1.3 handshake with a server presenting a leaf certificate whose Extended Key Usage extension omits id-kp-serverAuth (OID 1.3.6.1.5.5.7.3.1). The probe leaf carries id-kp-clientAuth (1.3.6.1.5.5.7.3.2) and id-kp-codeSigning (1.3.6.1.5.5.7.3.3) only — the cert was issued by its CA for purposes other than TLS server authentication. ocaml-tls accepts the cert, completes ECDHE, verifies CertificateVerify, and delivers application data.

The library has the correct EKU check, in handshake_client.ml:201:validate_keyusage. The TLS 1.3 entry point in handshake_client13.ml:answer_certificate is simply not wired to it. TLS 1.2 handshakes through answer_certificate_RSA and answer_certificate_DHE correctly reject a non-serverAuth cert; the same library accepts it on the TLS 1.3 path.

A sibling finding reports the same class of gap for the KeyUsage extension.

Attack

Numbered attack sequence:

1. Attacker obtains a leaf cert from any CA in the victim's trust store, with EKU including any of clientAuth, codeSigning, emailProtection, etc. — and excluding serverAuth. Practical sources: commercial S/MIME CAs, code-signing CAs, internal corporate PKI that issues clientAuth certs, public-CA misissuance.
2. Attacker stands up a TLS 1.3 server with that cert and binds the leaf's SAN hostname to a network position the victim's client will reach (DNS spoof, BGP hijack, captive portal, off-path redirect).
3. ocaml-tls 1.3 client opens a handshake. Server presents the non-serverAuth cert in its Certificate message.
4. validate_chain returns Ok. The TLS 1.3 path advances toAwaitServerCertificateVerify13 without checking EKU.
5. CertificateVerify is signed correctly (attacker holds the leaf's private key); signature verifies.
6. Handshake completes. Application data flows over the attacker-authenticated session.

ASCII trace:

Attacker                     ocaml-tls client
--------                     ----------------
(holds a cert issued with
 EKU=clientAuth + codeSigning
 from a CA the victim trusts)
ServerHello ------------->
Certificate(EKU=¬serverAuth) -> validate_chain → Ok
CertificateVerify ---------> signature OK
Finished ----------------->
                             ACCEPT
{AppData} <------>           delivered to application

Attack properties:

• The CA-issuance boundary that normally separates "may run a TLS server…