Summary
A wolfSSL verification flaw ignores the public key associated with a trusted peer certificate, allowing a forged certificate authority clone to pass authentication. When affected trust-peer APIs and build configurations are used, a malicious TLS or DTLS peer that knows the client's accepted certificate authorities may impersonate a trusted endpoint.
Affected context
The issue can occur in wolfSSL builds that enable WOLFSSL_TRUST_PEER_CERT and load CA certificates through wolfSSL_CTX_trust_peer_cert() or wolfSSL_trust_peer_cert(). Builds that also enable OPENSSL_COMPATIBLE_DEFAULTS may expose the behavior across broader CA loading paths. Risk is higher when a peer can determine which certificate authorities are trusted and the application relies on TLS or DTLS peer authentication, including mutual authentication.
Exploit preconditions
- Attack surface: TLS or DTLS certificate verification - Required access: No local access is necessarily required; the attacker
must generally be able to act as or influence a network peer
- Trigger point: Verification of a certificate associated with a configured
trusted peer or CA
- Knowledge requirement: The attacker must know which CA certificates the
target accepts or has loaded
- Why exploitation is possible: The verification path does not correctly
bind trust to the expected public key, allowing a forged CA clone to be
treated as trusted
Why this happens
The verification logic associated with MatchTrustedPeer fails to use the expected public key when deciding whether a certificate matches a trusted peer. This creates an improper certificate validation condition: possession of a certificate signed or structured to resemble an accepted trust anchor can be sufficient even when its public key is not the one that should be trusted. The behavior maps to CWE-295, Improper Certificate Validation, because identity and trust decisions are not completely bound to the authenticated key material.
Potential impact
- A malicious TLS or DTLS server may bypass client-side authentication
- An attacker could impersonate a trusted service
- Mutual TLS authentication may be weakened in either direction
- Sensitive application data could be disclosed or modified
- An attacker may gain access to services that rely on certificate identity
General mitigation guidance
Mitigation generally focuses on ensuring that certificate validation binds the authenticated identity to the intended public key and trust anchor. Secure-by-default patterns include using a verification path that performs explicit public-key and certificate-chain checks, avoiding trust-peer APIs when their semantics do not match the application's authentication model, and disabling compatibility behavior that broadens legacy CA-loading paths where it is not required. CA stores should be treated as protected security policy, and applications should minimize which authorities they trust. Least-privilege process permissions and restricted configuration access can reduce the impact of trust-store tampering. Applying the vendor-provided security correction or equivalent source-level fix is also appropriate.
How teams detect issues like this
Detection can include static analysis and code review for trust decisions that compare certificate metadata without verifying the associated public key, as well as searches for uses of trusted-peer APIs under compatibility macros. Test suites should exercise forged certificates that resemble accepted CA identities but use different keys, including one-way and mutual TLS scenarios. Policy enforcement can require explicit certificate-chain, hostname, identity, and public-key validation, while runtime telemetry can record unexpected trust-anchor changes and authentication failures. Automated security review tools may help identify incomplete certificate validation patterns.
