The tactic that the OpenSSL project took to get the FIPS 140-2 validation, but to avoid having to do it over again every time a new openssl release was issued,

The tactic that the OpenSSL project took to get the FIPS 140-2 validation, but to avoid having to do it over again every time a new openssl release was issued, was to build all the parts of openssl that were audited into a single object (fipscanister.o) that is to be loaded at run time. It is stored at some location on the machine along with a fingerprint, and when one enables FIPS mode, fipscanister.o's fingerprint is confirmed, and then the object is loaded. In practice, what this means is that you take one of the fips-openssl-x.y.z releases, and build fipscanister.o from it; that has the fundamental crypto bits in it, it's released as infrequently as possible. Then you build a plain old openssl-x.y.z release with a flag to enable the fips feature. At runtime when you enable FIPS mode, your local openssl library would switch to using crypto functions from fipscanister.o, which might be a year or two old. The idea is that the crypto bits don't generally change, although the rest of libssl/libcrypto might change several times during the year. Anyway building and using openssl this way is a giant pain in the ass, especially if you statically link. To make matters even more confusing, Redhat took an altogether different tack, and have their own variant of openssl that, when FIPS mode is enabled, switches to using the Linux Kernel crypto functions, which they got independently NIST validated, so if you're deploying the RHEL machines in the .gov space, a different FIPS 140-2 validation applies to you. It leads to a fair amount of crap in the configure scripts, and macros throughout the code.