Review OpenSSL 3.1 End of Support
Disclaimer: I am not directing anyone on the FIPS module to use and/or on your compliance story around FIPS modules and security patching.
OpenSSL recently attained FIPS 140-3 validation of OpenSSL 3.1.2 FIPS Module https://openssl-library.org/post/2025-03-11-fips-140-3/
Version 3.1 will be supported until 2025-03-14 https://openssl-library.org/policies/releasestrat/index.html
I am concerned about what this means for public consumption of a secure OpenSSL FIPS module. I expect that as of the 14th we do not actually stop applying security fixes to 3.1, but it would be good to have more of a guarantee that there will be security fixes available for this FIPS module until the 3.5 Module is approved for use.
Alternatively many could continue to use the 3.0 FIPS module (FIPS 140-2) for their FIPS workloads.
Craig Lorentzen Tue 8 Apr 2025 3:03PM
This is something I think OpenSSL needs to provide a clear and detailed document so that companies can make an informed decision when selecting versions of the FIPS module and surrounding OpenSSL software.
Jeff Johnson Wed 9 Apr 2025 1:33PM
@Neil Horman If I am not mistaken, the support contracts only apply to LTS branches. OpenSSL 3.1 is not an LTS branch, hence the desire for more clarification around EOS. BTW, thank you for the discussion. It is very helpful to the community, as Craig L. is pointing out.
Anton Arapov Wed 9 Apr 2025 6:30PM
@Jeff Johnson The commercial support contract includes all supported versions of the OpenSSL library until their official end-of-life (EOL), and extends support for long-term support (LTS) versions beyond their EOL.
Jeff Johnson Wed 9 Apr 2025 7:17PM
@Anton Arapov Yes, so accordingly OpenSSL3.1 from your support page... "Version 3.1 will be supported until 2025-03-14". Am I perhaps confusing EOL and EOS? My understanding (fully aware of how wrong I can be sometime), is that the support contracts were for LTS branches and while supported branches like 3.1 will continue to get security fixes during their support period (a fixed 2 year length of time), after that time they would not be supported.
Anton Arapov Wed 9 Apr 2025 7:28PM
@Jeff Johnson OpenSSL 3.1 is not an LTS release and is supported for a fixed 2-year period, ending on 2025-03-14. During that time, it receives security updates. After that date, it reaches end of life (EOL) and will no longer be supported. Only LTS releases like 3.0 and 3.5 are eligible for extended commercial support through contracts.
The release cycle graph on that page might be helpful: https://openssl-library.org/roadmap/index.html
Note that starting with OpenSSL 3.6, regular releases are supported for a fixed 1-year period instead of 2.
Jeff Johnson Wed 9 Apr 2025 7:34PM
@Anton Arapov That was exactly my understanding, thanks for confirming. That leads to the question that @Benjamin has posed. I know it seems like a simple concept but can be confusing when you have requirements that raise a lot of doubts (like FedRamp), so again, really appreciate the time given to this.
Neil Horman Wed 9 Apr 2025 2:01PM
That is a question I'm unable to answer. The language in
https://openssl-corporation.org/support/
Seems to suggest that, but I'm not sure how flexible that is. @Anton Arapov can you comment here?
Neil Horman · Mon 7 Apr 2025 3:47PM
Ok, thank you for the clarification. The only input I think I can reasonably make on the support question is historic, in that for all our releases we indicate that we offer premium support contracts on releases that are beyond their EoL dates for this purpose:
https://openssl-corporation.org/support/
We've done this for openssl 1.0.2 and 1.1.1 (which of course don't have FIPS certifications attached to them), but regardless, thats how we have traditionally handled support for releases beyond those dates. I would expect that, if a using entity wishes to ensure support/CVE updates to 3.0.8/3.0.9 between now and the FIPS certificate sunset date (Sept 21, 2026), that a premium support contract would be the path forward, though I've not seen any documentation spelling that out specifically, nor am I aware of any technical methodology for how we will administer that (i.e. will we keep updating a private fork of the repo for those with support contracts).