On 21 September 2026 the CMVP moves the remaining FIPS 140-2 certificates to its Historical List. Historical status means the certificates should no longer be relied on for new procurements; what the move does and does not change is the subject of a companion article in this series. That includes the OpenSSL FIPS Provider as validated under 140-2, certificates #4282 and #4811, both of which ship with the OpenSSL Library 3.0 series. For an organization with an ongoing validation requirement, the move is to a module with an active FIPS 140-3 validation, and for the OpenSSL Library that module is the OpenSSL FIPS Provider validated as certificate #4985, module version 3.1.2, valid through March 2030 and, per the project's stated compatibility, usable across the 3.x series.
There are two moves to make, and they are separate. One is the library itself, because the OpenSSL Library 3.0 series reached end of life on 7 September 2026, two weeks before the certificate change, so staying on 3.0 is no longer a supported posture whichever module you load. The other is the validated module. This is the order to take them in.
Library 3.0 end of life
Two weeks before the certificate change. From this date, new vulnerabilities in the 3.0 line go unfixed.
140-2 goes Historical
The CMVP moves the remaining FIPS 140-2 certificates, #4282 and #4811 included, to its Historical List.
#4985 valid through
The FIPS 140-3 validation of the OpenSSL FIPS Provider, module version 3.1.2.
Get onto a supported library line.
The supported LTS line is 3.5, with security fixes through 2030, and the current major release is 4.0. For a team carrying the validation requirement the durable target is 3.5, the line the module's stated compatibility covers; 4.0, with end of life currently May 2027, suits teams that track major releases as they arrive. Applications written for the 1.1.1 series mostly run unchanged on 3.x, with the work concentrated in build, packaging, and any use of removed interfaces. After 7 September, new vulnerabilities in the 3.0 line go unfixed. For a team that cannot complete the move before 3.0 reaches end of life, Extended LTS continues security fixes for the older line and buys time to migrate without running unmaintained cryptography.
Confirm your operating environment is covered.
A FIPS certificate is validated against specific tested operating environments, the combinations of operating system, processor, and in some cases build that the lab exercised. If the platform you deploy on is named on the certificate, you inherit the validation. If it is not, that environment has to be tested and added before the validation covers you there, which is laboratory work rather than a configuration change. This is the step teams discover late most often, so check your platforms against the certificate early.
Platform listed on #4985
You inherit the validation as it stands. Deploy the module and reference the certificate.
Platform not listed
The environment has to be tested by a laboratory and added before the validation covers you there. That is lab time, so surface it early in the plan.
Install and enable the FIPS provider.
The FIPS provider is the component that carries the validation, and it is separable from the rest of the Library, which is what lets you treat the module and the library as two decisions. Build the Library with FIPS support enabled, which produces the FIPS module alongside the standard providers.
Installation has two steps. First the module is placed in the providers directory, by default /usr/local/lib/ossl-modules/fips.so. Then openssl fipsinstall is run, which executes the module self-tests and writes the FIPS module configuration file, fipsmodule.cnf, recording the self-test status and the module integrity check. This step has to run on every machine the module runs on, and the resulting file must not be copied from one machine to another. The file records the self-tests run on that host: copy it into a container image, for instance, and the record is not yours; the module may still load, but the deployment is outside the security policy the validation depends on.
The Library reads that configuration through the main configuration file, where the same file is included and the providers are activated:
openssl_conf = openssl_init.include /usr/local/ssl/fipsmodule.cnf [openssl_init]providers = provider_sectalg_section = algorithm_sect [provider_sect]fips = fips_sectbase = base_sect [base_sect]activate = 1 [algorithm_sect]default_properties = fips=yes
The fips_sect referenced here is supplied by the included fipsmodule.cnf. The base provider is activated alongside the FIPS provider because the FIPS provider does no key encoding, and the base provider supplies it, so without base a FIPS deployment cannot serialize keys. Setting fips=yes as the default property means algorithm fetches resolve to the FIPS provider unless an application asks otherwise.
Run fipsinstall on every machine
The file records the self-tests run on that host. openssl fipsinstall executes the module self-tests and writes fipsmodule.cnf on each machine the module runs on.
Copy fipsmodule.cnf between machines
Copy it into a container image, for instance, and the record is not yours; the module may still load, but the deployment is outside the security policy the validation depends on.
Update the application.
The 3.x FIPS model is not the 1.x one. The old FIPS_mode() and FIPS_mode_set() functions no longer exist and have to come out of application code. Code that reaches algorithms through the high-level EVP interfaces works through the FIPS provider; code that calls low level primitives directly bypasses it and has to change. Once the configuration is in place, confirm the result rather than assume it: the module runs its self-tests on load, and an algorithm fetched with a fips=yes property query should resolve to the FIPS provider.
Get the certificate in your own name.
Using the OpenSSL FIPS Provider under certificate #4985 covers a team that deploys the validated module. A team that ships a product and has to present a certificate in its own name, for federal procurement, FedRAMP, or DoDIN APL, needs more than that, and the route is a rebrand: a certificate listed in your company's name in the CMVP database, for the same validated module, with your operating environments and your security policy.
A rebrand reuses an existing validation rather than starting a new one, which is what makes it tractable. A full FIPS 140-3 validation runs to a year or more in CMVP review alone, on top of the testing that precedes it. A rebrand carries none of that from-scratch testing, because the module is already validated, so the realistic figure is months rather than the years a fresh validation takes. The exact timing depends on your operating environments and the queue at the time, which is something to scope rather than assume.
A rebrand carries none of the from-scratch testing, because the module is already validated.
When OpenSSL Corporation runs the rebrand, the module is the genuine upstream OpenSSL FIPS Provider, maintained by the people doing the rebrand rather than a third party working from a derivative of it. That is the distinction worth weighing alongside cost, because a rebrand ties your certificate to whoever maintains the module behind it.
The process is measured in months, and the 140-2 certificates move to the Historical List on 21 September 2026, so the room to start and still finish ahead of the deadline is narrowing.
Both 140-2 certificates and the 140-3 module are searchable by number in the CMVP Validated Modules database. Planning and running this migration, and the rebrand, is work OpenSSL Corporation does, by the people who maintain the OpenSSL FIPS Provider. If you are scoping the move from #4282 or #4811, or need a certificate in your own name, contact the team and we can size it against your environment.
Scoping the move from #4282 or #4811?
Planning and running this migration, and the rebrand, is work OpenSSL Corporation does, by the people who maintain the OpenSSL FIPS Provider. Contact the team and we can size it against your environment.
In this series: The Cyber Resilience Act (CRA) and your cryptography dependencies · What moving to the Historical List means for FIPS compliance, and what it does not
Sources: CMVP certificates #4282 and #4811 (140-2, sunset 21 September 2026) and #4985 (140-3, through March 2030); OpenSSL Library FIPS 140-3 announcement and release strategy; FIPS provider installation and configuration, the OpenSSL Library fips_module guide and README-FIPS.