Re: How to test a build of the FIPS provider

On Thu, Jan 22, 2026 at 01:26:29PM +0100, Igor Ustinov wrote:

> The question was how to test "as non-root" and "not install it in the
> system area", and no word about "existing application".
> We don't know what conditions are most important for Ken, so let him decide.

The conditions are clear enough.  Test an application against a new FIPS
installed "on the side".

    Ken's first post said:

        Fedora 42, x86 - I built openssl 3.6.1 with enable-fips and got
        fips.so.
        I'd like to test it locally, as non-root, but not install it in
        the system area. Are there instructions for this?
        I want to test the EVP API, not TLS or the command line.

    His second post clarified:

        I know I can install there, but how does my C application and
        makefile point to it.

From which, and because the version (>= 3.0) of OpenSSL to which the
application is linked, and the version (also >= 3.0) of the FIPS module
are otherwise indepedent we can conclude that instructions on how to
link the application against the same non-default OpenSSL runtime that
was used to build the FIPS module are an unnecessary distraction.  One
can of course do that, but it still does not solve the problem and may
in some cases introduce new problems (e.g. the application, perhaps
indirectly, may also depend on the system's conflicting OpenSSL libraries).

The problem at hand is how to **CONFIGURE** use of a particular FIPS
module, whether it is installed in the same directory tree as the
OpenSSL runtime to which the application is linked, or not.

That requires making sure that the application's "openssl.cnf" file (or
whatever path the OPENSSL_CONF environment variable takes) contains
settings that load the "fips" and "default" providers (or in some cases
just "fips" and "base").  And making sure that the "fips" module is
properly installed with a matching "fipsmodule.cnf" found in
$OPENSSL_CONF_INCLUDE (if a relative file name and not in the default
location).

Relinking the application does not significantly advance that cause,
unless one is a platform vendor building a complete system with a
custom OpenSSL runtime, possibly matching FIPS module, and matching
applications.

Also note that users, who for some reason wants to use the FIPS module,
will want to use a FIPS module that is actually CMVP validated, rather
than the latest upstream version that hasn't yet gone through
validation.  So it will not be uncommon for the module and OpenSSL
library versions to be different.

Therefore, what Ken needs to know (even if perhaps he did not know to
ask) is how use a specific FIPS module.  He almost certainly already
knows how to link applications against a specific OpenSSL runtime, and
even with both FIPS and OpenSSL from a single build, one still needs to
apply the appropriate configuration settings.

Finally, anyone planning a FIPS-validated deployment needs to read,
understand and adhere to the security policy document of the validated
module in question.

Some relevant additional manpages are:

    openssl-fipsinstall(1)
    fips_config(5)
    fips_module(7)

basic installation of the "fips.so" and "fipsmodule.cnf"
can be accomplished via "make install_fips".

-- 
    Viktor.  🇺🇦 Слава Україні!

-- 
You received this message because you are subscribed to the Google Groups "openssl-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openssl-users+unsubscribe-MCmKBN63+Bmbup2nOX2J7Q@public.gmane.org
To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/aXI3fjyEkfl-EV30%40chardros.imrryr.org.