Review OpenSSL 3.1 End of Support

@Anton Arapov , @Neil Horman - Did we firm this up?

@Jeff Johnson This has been agreed, but I haven’t yet reflected it on our public pages - it’s been sitting in my backlog.

That said, it’s time to close the gap. I will make sure we have the language finalized and published this month. Please hold me to that.

Apologies, @Craig , for the delay here, and thank you again for the wording you suggested earlier - it’s been helpful in shaping this.

@Anton Arapov Happy to help, looking forward to seeing the policy document.

@Anton @Neil Horman So with the CVE announcement yesterday there was one inside the FIPS boundary: CVE-2026-42770. However there is no corresponding mention of it being fixed or affected in the announcement. What is the disposition of this CVE in regards to FP 3.1.2? What about rebrands?

Additionally, is OpenSSL pursuing an UPDT to the affected FP's?

I added to this thread because it was basically the same subject.

thx,

-jj

@Jeff Johnson This CVE unfortunately affects 3.1.2 FIPS module. There is a workaround, though. It is described on https://openssl-library.org/news/fips-cve/index.html

The https://openssl-library.org/news/fips-cve/index.html web page is now updated with the latest CVEs.

@Tomas Mraz So code changes for the user. Still have 2 questions? Is the FP for 3.1.2 supported (it isn't listed as affected on the page you sent). And for any FP affected is there going to be CMVP UPDT pursued?

@Tomas Mraz 

Thank you for confirming that CVE-2026-42770 affects the 3.1.2 FIPS module. However, two issues remain unresolved, both of which are the exact concerns for which this thread was raised.

The FIPS CVE page has dropped 3.1 from the newer entries.

https://openssl-library.org/news/fips-cve/ includes the 3.1 module for older CVEs (those fixed through 3.1.8), but the recent 2026 CVEs — including CVE-2026-42770 which you just confirmed impacts 3.1.2 — only list fix versions for 3.0, 3.4, 3.5, 3.6, and 4.0. There is no 3.1 row. This forces customers to make assumptions about whether their actively-certified module is vulnerable — assumptions they should not have to make when OpenSSL has the definitive answer. The page needs to explicitly state the impact to 3.1 for every CVE where it applies, even when no fix version exists yet.

CVE-2026-42770

3.0.21 3.4.6 3.5.7 3.6.3 4.0.1

yes

FFC-DH (X9.42/DHX) peer validation uses the attacker-supplied q instead of the local key’s q, skipping proper subgroup membership checking. Workaround: Call EVP_PKEY_parameters_eq() to compare the parameters of the remote and local keys before performing the key exchange.

Workarounds do not replace fix commits for centralized remediation.

The suggested workaround — calling EVP_PKEY_parameters_eq() before every DH key exchange — requires each consumer to audit and modify every call site across their entire portfolio. For organizations running this module across hundreds of services, that is not centralized remediation. It is an unbounded application-level campaign.

As Benjamin noted earlier in this thread, FedRAMP policy explicitly permits security fixes to validated modules and distinguishes "modules derived from an update stream of an existing validated module." The mechanism exists for library-level fixes to be applied once and deployed centrally. Expecting every consumer to independently implement a workaround at the application layer is not an equivalent outcome.

What we need:

1. Add 3.1 impact to the newer CVE entries on the FIPS CVE page — if the module is affected, say so publicly, even if no fix version is available yet. The page currently hides the situation.

2. Make fix commits publicly available for CVEs that impact the 3.1 FIPS boundary until module sunset (2030-03-10) or with a suitable notification period after 3.5's FIPS 140-3 module is validated. Consumers need to be able to patch the module centrally rather than campaign workaround code changes across every application.

This situation is precisely what this thread was intended to address. In April, Anton committed to publishing policy language on FIPS module maintenance; that timeline has now passed. In the interim, a CVE affecting the FIPS boundary has been identified in the only FIPS 140-3 validated OpenSSL module. At this point, consumers have no documented impact assessment on the public page, no fix commits, and no stated remediation plan — the available workaround is not practical at scale.

We are working on this.

The CVE page needs an update for 3.1: according to my notes, 25 (of 41) CVEs (since EOL) affect 3.1 in general.

For the FIPS 3.1 provider, the exact steps are being discussed internally. Stay tuned, please.

@Milan Broz Has any progress been made on this issue? Looking forward to hearing the path forward for FP3.1. Thanks!

Hi Jeff,

Since upstream 3.1 has reached end of life, we have prepared an internal build containing the related CVE fixes, which is currently undergoing lab analysis. This build is being handled internally by OpenSSL Corporation in a manner similar to extended support.

The next steps are still being discussed with the lab, so I'm unfortunately not able to share more details at this point. Anton should be able to provide further information later.

Thank you for your patience.

The policy this thread asked for is published:

Project policy: https://openssl-library.org/policies/general/fips-module-support-policy/
Corporation delivery terms: https://openssl-corporation.org/solutions-fips-policy.html
Validated modules and certificate end dates: https://openssl-library.org/news/fips-cve/

Answers to the questions still open here:

@Yi Ouyang : yes. The 3.1.2 module is supported for the lifetime of certificate #4985, until 10 March 2030. This does not depend on the 3.5 validation.

@Jeff Johnson : the 3.1.2 provider is supported (policy, section 2). A CVE re-validation of certificate #4985 is underway, adding 3.1.9 alongside 3.1.2, so existing validations remain valid; the CMVP handles this scenario on an expedited track. Certificates derived from #4985 by rebranding can take the corresponding update once the base re-validation completes.

@Norman Ashley : correct, the module is built from 3.1 source. Maintenance source releases exist for that purpose (3.1.9), produced after public support ends and delivered through support agreements. The module version matches the release it is built from; there are no FIPS-only branches (policy, section 4).

@Chris Brych : instead of extending 3.1 library support, module support is tied to the certificate lifetime, which runs past both dates you mentioned.

@Craig Lorentzen : the FIPS and CVEs page now carries per-CVE module impact including end-of-life versions, and from the next release advisories state module impact for every actively validated module. Thank you for the November draft language and for keeping this thread alive since March 2025.

This closes the thread from our side. :-)