Impact
Erlang/OTP's OCSP response verification in the public_key application does not check the validity period (notBefore/notAfter) of the OCSP responder certificate. An attacker who has obtained the private key of an expired CA-designated OCSP responder certificate can forge OCSP responses that Erlang/OTP accepts as valid.
This affects:
- SSL/TLS clients using OCSP stapling — a malicious or compromised server can present a revoked TLS certificate together with a forged OCSP response signed by an expired responder key. The client will accept the revoked certificate as valid.
- Applications calling
public_key:pkix_ocsp_validate/5 directly — the impact depends on the application's use case. Server-side client certificate validation using this API may allow authentication bypass with a revoked client certificate.
The attacker must possess the private key of a legitimately issued OCSP responder certificate whose validity period has expired (or has not yet started). The attacker must also be able to deliver the forged OCSP response to the victim (e.g. by controlling the server or performing a man-in-the-middle attack).
Workarounds
There is no configuration-level workaround that adds the missing validity check. The following mitigations reduce exposure:
- SSL users: For OCSP stapling via the
ssl application (TLS 1.2 and TLS 1.3), the CA certificate's own validity is already enforced during path validation before OCSP verification runs. The vulnerability is therefore limited to cases where a separate
responder certificate is used (RFC 6960 §4.2.2.2 criteria 1 and 3).
To eliminate exposure entirely, disable OCSP stapling with {stapling, no_staple} or switch to CRL-based revocation checking with {crl_check, true}.
- Direct API users: Applications calling
public_key:pkix_ocsp_validate/5 directly have no prior path validation — all three RFC 6960 §4.2.2.2 authorization criteria are affected. Validate the responder certificate's validity period in application code before calling the function.
Affected/Unaffected Versions
A version larger than or equal to one of the listed patched versions is unaffected; otherwise, a version that satisfies an expression listed under affected versions is affected, and if it does not, it is unaffected.
The documentation of the new OTP version scheme describes how versions should be compared. Note that versions used prior to OTP 17.0, when the new OTP version scheme was introduced, are never listed since it is not well defined how to compare those versions.
In the case of this vulnerability, versions prior to OTP 27.0 are unaffected.
Impact
Erlang/OTP's OCSP response verification in the
public_keyapplication does not check the validity period (notBefore/notAfter) of the OCSP responder certificate. An attacker who has obtained the private key of an expired CA-designated OCSP responder certificate can forge OCSP responses that Erlang/OTP accepts as valid.This affects:
public_key:pkix_ocsp_validate/5directly — the impact depends on the application's use case. Server-side client certificate validation using this API may allow authentication bypass with a revoked client certificate.The attacker must possess the private key of a legitimately issued OCSP responder certificate whose validity period has expired (or has not yet started). The attacker must also be able to deliver the forged OCSP response to the victim (e.g. by controlling the server or performing a man-in-the-middle attack).
Workarounds
There is no configuration-level workaround that adds the missing validity check. The following mitigations reduce exposure:
sslapplication (TLS 1.2 and TLS 1.3), the CA certificate's own validity is already enforced during path validation before OCSP verification runs. The vulnerability is therefore limited to cases where a separateresponder certificate is used (RFC 6960 §4.2.2.2 criteria 1 and 3).
To eliminate exposure entirely, disable OCSP stapling with
{stapling, no_staple}or switch to CRL-based revocation checking with{crl_check, true}.public_key:pkix_ocsp_validate/5directly have no prior path validation — all three RFC 6960 §4.2.2.2 authorization criteria are affected. Validate the responder certificate's validity period in application code before calling the function.Affected/Unaffected Versions
A version larger than or equal to one of the listed patched versions is unaffected; otherwise, a version that satisfies an expression listed under affected versions is affected, and if it does not, it is unaffected.
The documentation of the new OTP version scheme describes how versions should be compared. Note that versions used prior to OTP 17.0, when the new OTP version scheme was introduced, are never listed since it is not well defined how to compare those versions.
In the case of this vulnerability, versions prior to OTP 27.0 are unaffected.