How to test a build of the FIPS provider

[Ken Goldman]

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.

[Igor Ustinov]

You can build OpenSSL to be installed in a separate directory, e.g. $HOME/openssl, by calling Configure with parameters --prefix=$HOME/openssl --libdir=lib --openssldir=$HOME/openssl -Wl,-rpath,$HOME/openssl/lib

--
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-user...@openssl.org.
To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/10kmftm%2484v%241%40ciao.gmane.io.

--

Igor Ustinov

Senior Software Engineer, OpenSSL Foundation

Join the Code Protectors | Support us on Github Sponsors

[Wall, Stephen]

> From: openss...@openssl.org <openss...@openssl.org> On Behalf Of Ken Goldman
> Sent: Monday, January 19, 2026 6:49 PM

>
> I'd like to test it locally, as non-root, but not install it in the system area. Are there
> instructions for this?

On *nix:
LD_LIBRARY_PATH="." apps/openssl help

You can also run the self tests with "make test"

[Ken Goldman]

[Ken Goldman]

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

E.g., the fips provider is fips.so, not libfips.so, so I cannot simply
link with -lfips.

On 1/20/2026 3:09 AM, Igor Ustinov wrote:
> You can build OpenSSL to be installed in a separate directory, e.g.
> $HOME/openssl, by calling Configure with parameters --prefix=$HOME/
> openssl --libdir=lib --openssldir=$HOME/openssl -Wl,-rpath,$HOME/openssl/lib
>

> On Tue, 20 Jan 2026 at 00:49, Ken Goldman <kgoldman-r/
> Jw6+rmf7HQ...@public.gmane.org <mailto:kgoldman-r/

[Igor Ustinov]

It is not expected that an application will be linked with a provider directly; instead, link your application with libcrypto and use the provider via its API.

--
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-user...@openssl.org.

To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/10kol2o%24k77%241%40ciao.gmane.io.

[Ken Goldman]

Could you describe "its API".

I build in /home/openssl.

I set these to point there:

LD_LIBRARY_PATH
LIBRARY_PATH
CPATH
PATH

I set the linker to:

-L/home/openssl -Wl,-rpath,. -lcrypto

These all fail:

fips = OSSL_PROVIDER_load(NULL, "fips");
sha256 = EVP_MD_fetch(NULL, "SHA2-256", "fips=yes");
sha256 = EVP_MD_fetch(NULL, "SHA2-256", "provider=fips");

On 1/20/2026 4:22 PM, Igor Ustinov wrote:
> It is not expected that an application will be linked with a provider
> directly; instead, link your application with libcrypto and use the
> provider via its API.
>

[Viktor Dukhovni]

On Tue, Jan 20, 2026 at 05:26:12PM -0500, Ken Goldman wrote:

> Could you describe "its API".

Apologies for the poor advice you've seen so far...

Trying to make amends:

Providers are generally expected to be loaded via
the configuration file. In particular, for the
FIPS provider you'll need:

- A configuration file that requests that the FIPS
provider be loaded and used.

- A "modules"/ directory containing the "fips.so"
shared executable.

- A "fipsmodule.cnf" file created by "openssl fipsinstall".
This is normally installed by "make install_fips".

$ make -n install_fips
[...]
cp "providers/fips.so" "/usr/local/lib64/ossl-modules/fips.so.new"
chmod 755 "/usr/local/lib64/ossl-modules/fips.so.new"
mv -f "/usr/local/lib64/ossl-modules/fips.so.new" \
"/usr/local/lib64/ossl-modules/fips.so"
cp providers/fipsmodule.cnf "/usr/local/ssl/fipsmodule.cnf"

As a base config example, look at "test/fips-and-base.cnf"
(the base64 cruft in the demo script is a condensed version).

Demo script below my signature. At the bottom of that script
you can add any additional tests of your choice.

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

#! /bin/sh
set -e

DIR="$(mktemp -td ossl-test-dir.XXXXXX)"
TLOG="${DIR}/test.log"
CDIR="${DIR}/ssl"
LDIR="${DIR}/lib"
MDIR="${LDIR}/ossl-modules"
DSO="${MDIR}/fips.so"
mkdir -p "${CDIR}" "${MDIR}"

install -m 0755 providers/fips.so "${DSO}"

./util/wrap.pl ./apps/openssl fipsinstall \
-module "${DSO}" \
-out "${CDIR}/fipsmodule.cnf" \
-provider_name fips 2>"${TLOG}"

./util/wrap.pl ./apps/openssl fipsinstall \
-module "${DSO}" \
-in "${CDIR}/fipsmodule.cnf" \
-provider_name fips \
-verify >> "$TLOG" 2>&1

(
printf "%s\n%s\n%s\n%s\n" \
H4sIAGBwcGkAA1VOXQrDIAx+zymkByjsAD2JSHEaR8CpGBV2+8V1G+1Tvt8kuWBi \
jrvLKahN5S+lRA1WSi52jypQ4Wf2PeLqUgB9ThkoNQ/yWFn6P7wzugY2Pj6AchIP \
R9nFL1gbIYO+cgMeg+2xnTQpLfP29kJeQF+WG5iOJOY4zt0towhzHIL+QwNW3hi2 \
zcAN3r6sTF/2AAAA
) |
openssl base64 -d |
gunzip -c > "${CDIR}/openssl.cnf"

if openssl dgst -sha256 </dev/null
then : ok
else { printf "Unexpected sha256 failure\n" >&2; false; }; fi
if openssl dgst -ripemd </dev/null
then : ok
else { printf "Unexpected ripemd failure\n" >&2; false; }; fi

export OPENSSL_CONF="${CDIR}/openssl.cnf"
export OPENSSL_CONF_INCLUDE="${CDIR}"
export OPENSSL_MODULES="${MDIR}"
./util/wrap.pl ./apps/openssl fipsinstall -config "${OPENSSL_CONF}"

if openssl dgst -sha256 </dev/null
then : ok
else { printf "Unexpected sha256 failure\n" >&2; false; }; fi
if openssl dgst -ripemd </dev/null 2>/dev/null
then { printf "Unexpected ripemd success\n" >&2; false; }
else : ok; fi

# ... More tests here ...

[Igor Ustinov]

The linker options should be
-L/home/openssl/lib -Wl,-rpath=/home/openssl/lib -lcrypto

(providing /home/openssl is the correct path).

--
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-user...@openssl.org.

To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/80de5e3f-6b25-4668-b2a8-318e5fc10a02%40us.ibm.com.

[Ken Goldman]

When I do a build (configure, make), there is no
/home/openssl/lib.

The top level /home/openssl has libcrypto.so.

The fips library is in /home/openssl/providers/fips.so
but I don't know how to link to it.

[Viktor Dukhovni]

On Wed, Jan 21, 2026 at 06:15:55PM -0500, Ken Goldman wrote:

> When I do a build (configure, make), there is no
> /home/openssl/lib.
>
> The top level /home/openssl has libcrypto.so.
>
> The fips library is in /home/openssl/providers/fips.so
> but I don't know how to link to it.

Applications are NOT directly linked to provider code. Providers are
dynamically loaded not dynamically linked (DSO not DLL).

The instructions you're looking for are in:

https://groups.google.com/a/openssl.org/g/openssl-users/c/g4nAp5Ih2Jg/m/6HOu2NSIAgAJ

posted 16 hours before the message this is responding to and 9 minutes
before the message (sadly, a non-productive direction to follow) for
which that is a response.

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

[Igor Ustinov]

There are two OpenSSL directories: the build directory where you build OpenSSL, and the install directory where OpenSSL will be installed if you call

make install.

Viktor and I describe two different approaches: Viktor prefers to link an application directly with the library in the build directory, and I prefer to install OpenSSL first and then link an application with the installed library. You can choose one of these approaches that you like more.

If you choose Viktor's way, follow his instructions.

If you choose my way, set the install directory by Configure with parameters

--prefix=$MYPATH --libdir=lib --openssldir=$MYPATH -Wl,-rpath,$MYPATH/lib

(change $MYPATH to the desired install directory path or set MYPATH variables in advance),

build and install OpenSSL,

link your application with the installed library by using parameters

-L$MYPATH/lib -Wl,-rpath=$MYPATH/lib -lcrypto

--
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-user...@openssl.org.

To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/10krmnf%24ano%241%40ciao.gmane.io.

[Viktor Dukhovni]

On Thu, Jan 22, 2026 at 08:10:15AM +0100, Igor Ustinov wrote:

> There are two OpenSSL directories: the build directory where you build
> OpenSSL, and the install directory where OpenSSL will be installed if
> you call make install.
> Viktor and I describe two different approaches:

NO. I'm answering Ken's question about how to test a candidate FIPS
provider with an existing application. You've misunderstood his
question and are distracting his attention. :-(

> Viktor prefers to link an application directly with the library in the
> build directory,

No. I am not suggesting ANY steps to compile a *new* application. The
existing application linked against **ANY** OpenSSL 3.x version can be
tested with **ANY** version of the FIPS provider. The instructions
explain how to install a FIPS provider into a suitable test directory
and test the application. IF all goes well, later that FIPS provider
can be installed into a production "ossl-modules" directory used by
the live application.

> and I prefer to install OpenSSL first and then link an application
> with the installed library.

Which is a distraction. Please STOP.

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

[Igor Ustinov]

Viktor,

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.

--
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-user...@openssl.org.

To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/aXHsmzOHI73oYNnT%40chardros.imrryr.org.

[Viktor Dukhovni]

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. 🇺🇦 Слава Україні!

[Ken Goldman]

My requirement is to NOT install. I'm told that installing a
new openssl on Linux can break applications.

To summarize:

- not as root
- not installed in the system area
- C EVP API, not command line

On 1/22/2026 2:10 AM, Igor Ustinov wrote:
> There are two OpenSSL directories: the build directory where you build
> OpenSSL, and the install directory where OpenSSL will be installed if
> you call
> make install.
> Viktor and I describe two different approaches: Viktor prefers to link
> an application directly with the library in the build directory, and I
> prefer to install OpenSSL first and then link an application with the
> installed library. You can choose one of these approaches that you like
> more.
> If you choose Viktor's way, follow his instructions.
> If you choose my way, set the install directory by Configure with parameters
> --prefix=$MYPATH --libdir=lib --openssldir=$MYPATH -Wl,-rpath,$MYPATH/lib
> (change $MYPATH to the desired install directory path or set MYPATH
> variables in advance),
> build and install OpenSSL,
> link your application with the installed library by using parameters
> -L$MYPATH/lib -Wl,-rpath=$MYPATH/lib -lcrypto
>
>

> On Thu, 22 Jan 2026 at 00:16, Ken Goldman <kgoldman-r/
> Jw6+rmf7HQ...@public.gmane.org <mailto:kgoldman-r/

> Jw6+rmf7HQ...@public.gmane.org>> wrote:
>
> When I do a build (configure, make), there is no
> /home/openssl/lib.
>
> The top level /home/openssl has libcrypto.so.
>
> The fips library is in /home/openssl/providers/fips.so
> but I don't know how to link to it.
>
>
>
> On 1/21/2026 2:23 AM, Igor Ustinov wrote:
> > The linker options should be
> > -L/home/openssl/lib -Wl,-rpath=/home/openssl/lib -lcrypto
> > (providing /home/openssl is the correct path).
> >

> > On Tue, 20 Jan 2026 at 23:26, Ken Goldman <kgoldman-r/
> Jw6+rmf7HQ...@public.gmane.org <mailto:kgoldman-r/
> Jw6+rmf7HQ...@public.gmane.org>
> > <mailto:kgol...@us.ibm.com

[Ken Goldman]

These instructions include "install" steps. I don't want to
install. I want to test as non-root in a non-system area.

[Ken Goldman]

Initially, I want to run a toy application just to
understand how to link with the fips provider.

Later, I'll run existing C applications against the
fips provider, modifying the source and/or rebuilding
and/or adding a configuration file as needed.

[Igor Ustinov]

First of all, I'd like to clarify that you can install your custom build of OpenSSL into your home directory. Although it is technically an installation, it doesn't require root privileges and will not affect any existing application.

To do it, you need to configure OpenSSL with parameters

--prefix=$HOME/myopenssl --libdir=lib --openssldir=$HOME/myopenssl -Wl,-rpath,$HOME/myopenssl/lib

and after that

make

make install

You will have your build of OpenSSL in the myopenssl directory in your home. It will not affect any existing applications.

To link your application that uses the EVP API with this build, you need to use the linker parameters

 -L$HOME/myopenssl/lib -Wl,-rpath=$HOME/myopenssl/lib -lcrypto

After that, your application (and only this application) will use your build of OpenSSL instead of the system one.

If you want your application to work with the FIPS provider, you also need to edit the configuration file $HOME/myopenssl/ssl/openssl.cnf to load the FIPS provider.

--
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-user...@openssl.org.

To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/10l8lti%24lvr%241%40ciao.gmane.io.

[Ken Goldman]

Specifically, configure an application to link to my
local openssl build.

>
> 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).

Is there more specific documentation?

Perhaps I should copy openssl.conf to my application directory? And set
OPENSSL_CONF to its location?

There is a fips section. Must I edit it?

Should I copy providers/fipsmodule.cnf somewhere, perhaps a providers
subdirectory? And edit it or not?

Where would fips.so go? Do I link to it, or is there a runtime link
based on the configuration files?

Perhaps I don't have to copy anything but just set several env variables?

>
> 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.

CMVP is a complication that I don't want to consider immediately.

>
> 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.

I know how to link to a local libcrypto.so, but not how to link to a
local fips.so.

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

I'm not up to that yet.

>
> 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".

I don't want to install (or do anything as root), just
link and run against a local build (not in any system area).
>

[Viktor Dukhovni]

On Mon, Jan 26, 2026 at 05:32:44PM -0500, Ken Goldman wrote:

> > 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.
>
> Specifically, configure an application to link to my
> local openssl build.

No, you're confused. You don't **link** applications against the FIPS
provider, the provider is dynamically loaded (at runtime, not link
time). This applies equally to:

- The openssl(1) command-line utility and its various subcommands,
such as openssl-s_client(1), ...

- Existing applications that use an OpenSSL 3.x (or development 4.x
snapshot) library.

- Any "toy" applications you want to test.

All the above can be compiled against the headers in
/usr/include/ and linked with the system OpenSSL runtime in
/usr/lib (or /usr/lib64 depending on the OS). As already
explained, what makes them use the FIPS provider is the
CONFIGURATION file.

To test a non-default configuration (i.e. not make system-wide changes
as root), you set the OPENSSL_CONF environment variable to point at a
test configuration file in some directory that also contains the
"fipsmodule.cnf" file. The test directory structure is then something
like:

/some/where/ssl/openssl.cnf
/some/where/ssl/fipsmodule.cnf
/some/where/lib/ossl-modules/fips.so

The "fipsmodule.cnf" file is machine-generated by either the
"openssl fipsinstall" command as in the posted shell script,
or by running "make install_fips" (after a suitable choice
of "--prefix=..." when configuring the build).

You can in principle also obtain and install a pre-compiled "fips.so"
and a corresponding "fipsmodule.cnf" from a suitably reputable software
vendor. Building your own is not a requirement.

and you then adjust the "openssl.cnf" file to your liking and:

$ export OPENSSL_CONF=/some/where/ssl/openssl.cnf
$ export OPENSSL_CONF_INCLUDE=/some/where/ssl
$ export OPENSSL_MODULES=/some/where/lib/ossl-modules

... run whatever tests you want ...

> > 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).
>
> Is there more specific documentation?

I posted a shell script that does all the work, and a followup message
with manpage references if you'd like to read more, there is no
additional documentation needed in order to run tests. When I run
the script the directory ended up containing:

/tmp/ossl-test-dir.GOT9Fh/lib/ossl-modules/fips.so
/tmp/ossl-test-dir.GOT9Fh/ssl/openssl.cnf
/tmp/ossl-test-dir.GOT9Fh/ssl/fipsmodule.cnf

And the configuration was (verbatim):

openssl_conf = openssl_init
config_diagnostics = 1
.include fipsmodule.cnf

[openssl_init]
providers = provider_sect
alg_section = evp_properties

[evp_properties]
default_properties = "fips=yes"

[provider_sect]
fips = fips_sect
base = base_sect

[base_sect]
activate = 1

With those environment variables, that pair of configuration
files and the compiled module,

> Perhaps I should copy openssl.cnf to my application directory? And set
> OPENSSL_CONF to its location?

Yes, or any other location of your choice, where you'd also install the
"fipsmodule.cnf" file, and the "fips.so" dynamic shared object in a
related or even the same directory.

> There is a fips section. Must I edit it?

Exactly as shown above. The critical section is the unnamed
"default section" at the top of the file. This specifies
an "openssl_conf" parameter that names some section of your
choice:

# Any RHS section name will do
openssl_conf = larry-conf-42

# Required for FIPS
.include fipsmodule.cnf

[larry-conf-42]
providers = curly-providers-1729
alg_section = moe-evp-631

[curly-providers-1729]
# This has to match the "fipsmodule.cnf" file
fips = fips_sect

# With just "fips" and "base" this is a "FIPS-only" combination
base = groucho-432423

# You might instead
# want a "FIPS + default" combination, comment out "base"
# above and uncomment "default" below:
# default = groucho-432423

[moe-evp-631]
# Comment out if non-FIPS algorithms should also be available.
default_properties = "fips=yes"

[groucho-432423]
activate = 1

The names on the left of the "=" signs are compiled-in literals, you
have use these unchanged. The section names on the right are yours to
choose, but try to not make them silly like above.

> Should I copy providers/fipsmodule.cnf somewhere, perhaps a providers
> subdirectory? And edit it or not?

The "fipsmodule.cnf" file is machine-generated and critical for the
module to pass integrity checks during "power-on-self-test" (POST).
You SHOULD NOT edit it if you want the module to work.

> Where would fips.so go?

Anywhere you want. The directory that contains it is specified
via the "OPENSSL_MODULES" environment variable (otherwise it
is whatever is whatever is reported by "openssl version -m",
for example with Fedora 43:

$ /usr/bin/openssl version -m
MODULESDIR: "/usr/lib64/ossl-modules"

> Do I link to it, or is there a runtime link based on the configuration
> files?

In this and in more than one upthread post, which I'd like to recommend
you read closely, I've made it quite clear that you DO NOT link your
code against the FIPS module, it is loaded at runtime if the
configuration specifies "fips" as one of the "providers" to "activate".

> Perhaps I don't have to copy anything but just set several env
> variables?

You can indeed use everything directly from the build tree if you wish,
in which case:

export OPENSSL_MODULES=$PWD/providers
export OPENSSL_CONF_INCLUDE=$PWD/providers
export OPENSSL_CONF=$PWD/test/fips-and-base.cnf

or instead:

export OPENSSL_CONF=$PWD/test/default-and-fips.cnf

depending on whether you want you want a FIPS-only, or
a fips-optional configuration. The below may be
helpful:

$ diff -U1 <(grep -v '^#' test/default-and-fips.cnf) \
<(grep -v '^#' test/fips-and-base.cnf)
--- /dev/fd/63 2026-01-27 12:02:49.636190765 +1100
+++ /dev/fd/62 2026-01-27 12:02:49.637190768 +1100
@@ -9,7 +9,10 @@

+[evp_properties]
+default_properties = "fips=yes"
+
[provider_sect]
-default = default_sect
fips = fips_sect
+base = base_sect

-[default_sect]
-activate = yes
+[base_sect]
+activate = 1

> > 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.
>
> I know how to link to a local libcrypto.so, but not how to link to a local
> fips.so.

That's because the latter is not a matter of "linking", as noted.

> > 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".
>
> I don't want to install (or do anything as root), just
> link and run against a local build (not in any system area).

I did not suggest any steps that require "root" privileges or modify the
ambient OS environment outside your test runs.

My recommendation is to copy ("install" as a non-root user) the
requisite files to a dedicated private filesystem tree outside the build
directory. This decouples your tests from the OpenSSL build, you can
test any version (or multiple versions) of the module, and gives an
indication of how you'd actually deploy the module for live use.

As noted above, if you want to skip all of that, you can use the
files in directly out of the build tree:

$ export OPENSSL_MODULES=$PWD/providers
$ export OPENSSL_CONF_INCLUDE=$PWD/providers
$ export OPENSSL_CONF=$PWD/test/fips-and-base.cnf

... run your tests ...

$ export OPENSSL_MODULES=$PWD/providers
$ export OPENSSL_CONF_INCLUDE=$PWD/providers
$ export OPENSSL_CONF=$PWD/test/default-and-fips.cnf

... run your tests ...

The latter exposes both FIPS and non-FIPS algorithms, the application
can then selectively use a "property string" (propq) of "fips=yes" when
desired, and otherwise still use non-FIPS algorithms.

An example from the build tree:

$ fipsrun() { (
export LD_LIBRARY_PATH=$PWD \
OPENSSL_CONF=$1 \
OPENSSL_CONF_INCLUDE=$PWD/providers \
OPENSSL_MODULES=$PWD/providers
shift
./apps/openssl "$@"
); }

$ fipsrun test/default-and-fips.cnf list -digest-algorithms | wc -l
103

# The FIPS module does include some non-validated algorithms,
# visible unless the property string is set to "fips=yes".
#
$ fipsrun test/fips-and-base.cnf list -digest-algorithms | wc -l
75

Finally, with "fips=yes", just the FIPS validated algorithms:

$ fipsrun test/fips-and-base.cnf list -digest-algorithms -propquery='"fips=yes"'
Provided:
{ 2.16.840.1.101.3.4.2.10, SHA3-512 } @ fips
{ 2.16.840.1.101.3.4.2.6, SHA-512/256, SHA2-512/256, SHA512-256 } @ fips
{ 2.16.840.1.101.3.4.2.4, SHA-224, SHA2-224, SHA224 } @ fips
{ 1.3.14.3.2.26, SHA-1, SHA1, SSL3-SHA1 } @ fips
{ 2.16.840.1.101.3.4.2.7, SHA3-224 } @ fips
{ 2.16.840.1.101.3.4.2.9, SHA3-384 } @ fips
{ 2.16.840.1.101.3.4.2.3, SHA-512, SHA2-512, SHA512 } @ fips
{ 2.16.840.1.101.3.4.2.5, SHA-512/224, SHA2-512/224, SHA512-224 } @ fips
{ 2.16.840.1.101.3.4.2.12, SHAKE-256, SHAKE256 } @ fips
{ 2.16.840.1.101.3.4.2.2, SHA-384, SHA2-384, SHA384 } @ fips
{ 2.16.840.1.101.3.4.2.8, SHA3-256 } @ fips
{ 2.16.840.1.101.3.4.2.1, SHA-256, SHA2-256, SHA256 } @ fips
{ 2.16.840.1.101.3.4.2.11, SHAKE-128, SHAKE128 } @ fips
ML-DSA-MU @ fips

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

[Michael Richardson]

Ken Goldman <kgol...@us.ibm.com> wrote:
> My requirement is to NOT install. I'm told that installing a new
> openssl on Linux can break applications.

Yes, that can be the case.
But, not if you install into a very much non-standard directory (so, not
/usr/local even). ./Configure --prefix=$HOME/myjunk etc.

The challenge is that, having installed some shared libraries there,
convincing other code (your test program) to use those shared libraries can
be a PITA. It's possible, it's just easy to wind up with the system
librairies by mistake.

> To summarize:

> - not as root - not installed in the system area - C EVP API, not
> command line

As I suggested, build with no-shared, so you get .a files, and link that.
no-shared != no-dso, and you need dso to be able to load the fips.so (or any
other provider [or engine] not built in)

I'm sure a container could help, the challenge is having one with *no* libssl,
and yet your test code build process still function if it wants to download things.
Not impossible, but annoying, especially if you then find that you want to
maybe debug something.

[Viktor Dukhovni]

On Tue, Jan 27, 2026 at 02:23:48AM -0500, Michael Richardson wrote:

> But, not if you install into a very much non-standard directory (so, not
> /usr/local even). ./Configure --prefix=$HOME/myjunk etc.

That may be interesting, but not relevant to Ken's original issue, so I
changed the subject header accoringly, if Ken's question is the topic of
interest, please ignore what follows...

> The challenge is that, having installed some shared libraries there,
> convincing other code (your test program) to use those shared libraries can
> be a PITA. It's possible, it's just easy to wind up with the system
> librairies by mistake.

Also off-topic for Ken's issue, but relevant to this diversion, It is
possible to build libraries with custom "SONAME" strings, so that, once
linked, applications won't accidentally use or conflict with the
system library. Look for "shlib_variant" in Configurations/README.md.
Thus I have (season to taste):

; cat Configurations/99-foo.conf
my %targets = (
"linux-x86_64-foo" => {
inherit_from => [ "linux-x86_64" ],
shlib_variant => "foo",
},
"BSD-x86_64-foo" => {
inherit_from => [ "BSD-x86_64" ],
shlib_variant => "foo",
},
);

which after, e.g.

$ DEST=/opt/openss/master
$ ./Configure --prefix=$DEST -Wl,-R,$DEST/lib64 \
enable-fips --prefixlinux-x86_64-foo
$ make
$ sudo "make install_sw install_ssldirs install_fips"

gives:

$ ls -l /opt/openssl/master/lib64/*.so*
lrwxrwxrwx 1 root root 17 Jan 13 20:01 /opt/openssl/master/lib64/libcrypto.so -> libcryptofoo.so.4
-rwxr-xr-x 1 root root 7180344 Apr 3 2025 /opt/openssl/master/lib64/libcryptofoo.so.3
-rwxr-xr-x 1 root root 7323960 Jan 13 20:01 /opt/openssl/master/lib64/libcryptofoo.so.4
lrwxrwxrwx 1 root root 14 Jan 13 20:01 /opt/openssl/master/lib64/libssl.so -> libsslfoo.so.4
-rwxr-xr-x 1 root root 1258696 Apr 3 2025 /opt/openssl/master/lib64/libsslfoo.so.3
-rwxr-xr-x 1 root root 1266776 Jan 13 20:01 /opt/openssl/master/lib64/libsslfoo.so.4

$ readelf -d /opt/openssl/master/lib64/libcrypto.so | grep -Ew 'SONAME|RUNPATH|NEEDED'
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x000000000000000e (SONAME) Library soname: [libcryptofoo.so.4]
0x000000000000001d (RUNPATH) Library runpath: [/opt/openssl/master/lib64]

$ readelf -d /opt/openssl/master/lib64/libssl.so | grep -Ew 'SONAME|RUNPATH|NEEDED'
0x0000000000000001 (NEEDED) Shared library: [libcryptofoo.so.4]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x000000000000000e (SONAME) Library soname: [libsslfoo.so.4]
0x000000000000001d (RUNPATH) Library runpath: [/opt/openssl/master/lib64]

$ readelf -d /opt/openssl/master/bin/openssl | grep -Ew 'SONAME|RUNPATH|NEEDED'
0x0000000000000001 (NEEDED) Shared library: [libsslfoo.so.4]
0x0000000000000001 (NEEDED) Shared library: [libcryptofoo.so.4]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x000000000000001d (RUNPATH) Library runpath: [/opt/openssl/master/lib64]

The variant shared libraries avoid conflict with any related system
library symbol versions:

$ objdump -T /opt/openssl/master/lib64/libcrypto.so | grep '\.text' | head
00000000000ff5a0 g DF .text 00000000000001ea OPENSSLFOO_4.0.0 OSSL_ENCODER_do_all_provided
0000000000130d50 g DF .text 00000000000000ab OPENSSLFOO_4.0.0 EVP_PKEY_get_int_param
00000000002ca5f0 g DF .text 0000000000000009 OPENSSLFOO_4.0.0 X509_REVOKED_get_ext_by_critical
00000000000497e0 g DF .text 0000000000000005 OPENSSLFOO_4.0.0 BIO_meth_get_puts
0000000000106480 g DF .text 000000000000000f OPENSSLFOO_4.0.0 ESS_CERT_ID_V2_dup
000000000003b570 g DF .text 0000000000000095 OPENSSLFOO_4.0.0 ASN1_item_ex_d2i
00000000000c0a60 g DF .text 000000000000005b OPENSSLFOO_4.0.0 DH_security_bits
00000000002bf1b0 g DF .text 0000000000000026 OPENSSLFOO_4.0.0 X509_PURPOSE_get_count
0000000000258440 g DF .text 0000000000000027 OPENSSLFOO_4.0.0 i2d_RSAPublicKey
0000000000060fa0 g DF .text 0000000000000036 OPENSSLFOO_4.0.0 BN_mod_lshift1

Any application linked against these can (just like bin/openssl above)
safely also (dynamically) link with other system libraries that in turn
depend on the system OpenSSL, with the custom and system OpenSSL
libraries coëxising in the same address space without conflict.

Static linking with ".a" libraries is less flexible, and does not
support symbol versions, makes upgrades much less modular, and so I
don't recommend it.

> > To summarize:
> >
> > - not as root - not installed in the system area - C EVP API, not
> > command line
>
> As I suggested, build with no-shared, so you get .a files, and link that.
> no-shared != no-dso, and you need dso to be able to load the fips.so (or any
> other provider [or engine] not built in)
>
> I'm sure a container could help, the challenge is having one with *no* libssl,
> and yet your test code build process still function if it wants to download things.
> Not impossible, but annoying, especially if you then find that you want to
> maybe debug something.

The "sblib_variant" approach is sufficiently robust (on ELF platforms
with SONAMEs and symbol versioning, e.g. Linux and the various BSDs), no
need for containers. Still off-topic w.r.t. the original question.

The "shlib_variant" approach does not directly extend to MacOS or
Windows, where the runtime linker is substantially different.

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

[Viktor Dukhovni]

On Tue, Jan 27, 2026 at 07:21:22PM +1100, Viktor Dukhovni wrote:

> $ ./Configure --prefix=$DEST -Wl,-R,$DEST/lib64 \
> enable-fips --prefixlinux-x86_64-foo

Sorry about the typo, should have been:

$ ./Configure --prefix=$DEST -Wl,-R,$DEST/lib64 \
enable-fips linux-x86_64-foo

and perhaps setting the "shlib_variant" to "-foo" (as suggested in
Configurations/README.md) instead of just "foo", makes for more readable
file names, SONAMEs and symbol versions.

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

[Michael Richardson]

--------

Viktor Dukhovni <openss...@dukhovni.org> wrote:
> Static linking with ".a" libraries is less flexible, and does not
> support symbol versions, makes upgrades much less modular, and so I
> don't recommend it.

yes, but when testing and debugging code, none of the things you mention are
features.

[Ken Goldman]

On 1/21/2026 2:15 AM, Viktor Dukhovni wrote:

> Providers are generally expected to be loaded via
> the configuration file. In particular, for the
> FIPS provider you'll need:
>
> - A configuration file that requests that the FIPS
> provider be loaded and used.
>
> - A "modules"/ directory containing the "fips.so"
> shared executable.
>
> - A "fipsmodule.cnf" file created by "openssl fipsinstall".
> This is normally installed by "make install_fips".
>
> $ make -n install_fips
> [...]
> cp "providers/fips.so" "/usr/local/lib64/ossl-modules/fips.so.new"
> chmod 755 "/usr/local/lib64/ossl-modules/fips.so.new"
> mv -f "/usr/local/lib64/ossl-modules/fips.so.new" \
> "/usr/local/lib64/ossl-modules/fips.so"
> cp providers/fipsmodule.cnf "/usr/local/ssl/fipsmodule.cnf"

It's still not finding the fips module. I ran this:

make install_fips

And uncommented these in openssl.cnf

.include fipsmodule.cnf
fips = fips_sect

It feels like I'm missing a step. How does my application (via
configuration files) point to

lib/ossl-modules/fips.so

I also tried adding

[evp_properties]
default_properties = "fips=yes"

[Ken Goldman]

On 1/22/2026 2:10 AM, Igor Ustinov wrote:

> There are two OpenSSL directories: the build directory where you build
> OpenSSL, and the install directory where OpenSSL will be installed if
> you call
> make install.
> Viktor and I describe two different approaches: Viktor prefers to link
> an application directly with the library in the build directory, and I
> prefer to install OpenSSL first and then link an application with the
> installed library. You can choose one of these approaches that you like
> more.
> If you choose Viktor's way, follow his instructions.
> If you choose my way, set the install directory by Configure with parameters
> --prefix=$MYPATH --libdir=lib --openssldir=$MYPATH -Wl,-rpath,$MYPATH/lib
> (change $MYPATH to the desired install directory path or set MYPATH
> variables in advance),
> build and install OpenSSL,
> link your application with the installed library by using parameters
> -L$MYPATH/lib -Wl,-rpath=$MYPATH/lib -lcrypto

It seems like there are more steps. At run time, the application has to
find the fips module.

I suspect that some configuration files must be edited.

base = OSSL_PROVIDER_load(NULL, "base"); - success
fips = OSSL_PROVIDER_load(NULL, "fips"); - fails

[Viktor Dukhovni]

On Tue, Jan 27, 2026 at 05:37:06PM -0500, Ken Goldman wrote:

> > the configuration file. In particular, for the
> > FIPS provider you'll need:
> >
> > - A configuration file that requests that the FIPS
> > provider be loaded and used.

> It's still not finding the fips module. I ran this:
>
> make install_fips

This installs the "fipsmodule.cnf" and "fips.so" files, but
does not update "openssl.cnf", which is still required to
"enable" activation of the provider.

> And uncommented these in openssl.cnf
>
> .include fipsmodule.cnf
> fips = fips_sect

When the ".include" filename is a "relative" filename the directory
searched sadly does not default to either the one containing the
configuration file with the ".include" or the directory reported by
"openssl version -d". Rather, you one of the below is needed:

- Setting the OPENSSL_CONF_INCLUDE environment variable to
the directory containing "fipsmodule.cnf"

export OPENSSL_CONF_INCLUDE=/some/where/ssl

- Adding a configuration pragma that specifies the base path
of relative include file names.

.pragma includedir:/some/where

My configuration file for FIPS module tests has the below diff relative
to fthe stock "openssl.cnf" installed by "make install_ssldirs":

--- openssl.cnf 2026-01-28 11:24:26.969524459 +1100
+++ fips.cnf 2026-01-28 11:35:46.611998701 +1100
@@ -17,2 +17,4 @@
openssl_conf = openssl_init
+.pragma includedir:/opt/openssl/master/ssl
+.include fipsmodule.cnf

@@ -57,6 +59,4 @@
[provider_sect]
-default = default_sect
-# The fips section name should match the section name inside the
-# included fipsmodule.cnf.
-# fips = fips_sect
+base = default_sect
+fips = fips_sect

@@ -71,4 +71,3 @@
[default_sect]
-# activate = 1
-
+activate = 1

> It feels like I'm missing a step. How does my application (via
> configuration files) point to
>
> lib/ossl-modules/fips.so

As posted upthread, that requires either:

- Setting the OPENSSL_MODULES environment variable:

export OPENSSL_MODULES=/some/where/lib/ossl-modules

- Adding an explicit module path to the fipsmodule.cnf file:

fipsmodule.cnf:
[fips_sect]
module = /some/where/lib/ossl-modules/fips.so
...

> I also tried adding
>
> [evp_properties]
> default_properties = "fips=yes"

That'll only work once you're able to load the FIPS module.
Before testing your application, test the "openssl list"
command. For example:

$ export PATH=/opt/openssl/master/bin:$PATH

$ export OPENSSL_CONF=/opt/openssl/master/ssl/openssl.cnf
$ openssl list -providers
Providers:
default
name: OpenSSL Default Provider
version: 4.0.0
status: active

$ export OPENSSL_CONF=/opt/openssl/master/ssl/fips.cnf
$ openssl list -providers
Providers:
base
name: OpenSSL Base Provider
version: 4.0.0
status: active
fips
name: OpenSSL FIPS Provider
version: 4.0.0
status: active

The diff between "openssl.cnf" and "fips.cnf" is as shown above.

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

[Ken Goldman]

On 1/27/2026 7:51 PM, Viktor Dukhovni wrote:
> On Tue, Jan 27, 2026 at 05:37:06PM -0500, Ken Goldman wrote:
>
> This installs the "fipsmodule.cnf" and "fips.so" files, but
> does not update "openssl.cnf", which is still required to
> "enable" activation of the provider.
>

> When the ".include" filename is a "relative" filename the directory
> searched sadly does not default to either the one containing the
> configuration file with the ".include" or the directory reported by
> "openssl version -d". Rather, you one of the below is needed:
>
> - Setting the OPENSSL_CONF_INCLUDE environment variable to
> the directory containing "fipsmodule.cnf"
>
> export OPENSSL_CONF_INCLUDE=/some/where/ssl
>
> - Adding a configuration pragma that specifies the base path
> of relative include file names.
>
> .pragma includedir:/some/where

The .pragma works. I had used a full path name, which also works.

Thank you. This is the step I was missing.

[Ken Goldman]

On 1/19/2026 6:49 PM, Ken Goldman wrote:
> 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.
>

For the record, here are working instructions, creating
a fips build in myopenssl:

./config -shared --prefix=/home/kgold/myopenssl --libdir=lib
--openssldir=/home/kgold/myopenssl -Wl,-rpath,$HOME/myopenssl/lib
--debug zlib enable-fips
make
creates
./providers/libfips.a
./providers/fips.so
make install
installs to myopenssl directory
make test
make install_fips
creates
/home/kgold/myopenssl/lib/ossl-modules/fips.so
/home/kgold/myopenssl/fipsmodule.cnf

openssl.cnf
add
.pragma includedir:/home/myopenssl/
uncomment
.include fipsmodule.cnf
comment
#default = default_sect
add
base = default_sect
fips = fips_sect
in default_sect, uncomment
activate = 1

fipsmodule.cnf
add
module = /home/myopenssl/lib/ossl-modules/fips.so

LNFLAGS += -L/home/myopenssl/lib -Wl,-rpath=/home/myopenssl/lib -lcrypto

Test with

openssl list -providers

Providers:
base
name: OpenSSL Base Provider

version: 3.6.1

status: active
fips
name: OpenSSL FIPS Provider

version: 3.6.1
status: active

[Viktor Dukhovni]

On Wed, Jan 28, 2026 at 06:26:32PM -0500, Ken Goldman wrote:

> For the record, here are working instructions, creating
> a fips build in myopenssl:
>
> ./config -shared --prefix=/home/kgold/myopenssl --libdir=lib
> --openssldir=/home/kgold/myopenssl -Wl,-rpath,$HOME/myopenssl/lib --debug zlib enable-fips

So far, so good, but you can also add:

$ grep -v '#' <<-\EOF > Configurations/99-test.conf
# Leading <TAB>s below to go with the "-\EOF" above
my %targets = (
"kgold" => {
inherit_from => [ "linux-x86_64" ],
shlib_variant => "-test",
shared_ldflag => "-Wl,-rpath,$ENV{'HOME'}/myopenssl/lib",
module_ldflags => "",
bin_lflags => "-Wl,-rpath,$ENV{'HOME'}/myopenssl/lib",
},
EOF

And then set "kgold" as the last "config" (or "Configure") argument.

./config -shared --debug --prefix=/home/kgold/myopenssl \
--libdir=lib --openssldir=/home/kgold/myopenssl \
--debug zlib enable-fips kgold

This produces a "shlib_variant" with "-test" in the SONAMEs and "_TEST"
in the symbol names, and goes the extra mile to not add an RPATH to the
othewise self-contained FIPS module. (Apologies about the rather
haphazard naming of the various LD flag variables, there are even it
seems some inconsistencies in the names used between Unix, Windows and
VMS, the above workds for Unix).

> openssl.cnf
> add
> .pragma includedir:/home/myopenssl/
> uncomment
> .include fipsmodule.cnf
> comment
> #default = default_sect
> add
> base = default_sect
> fips = fips_sect
> in default_sect, uncomment
> activate = 1

This looks good for default base + fips activation.

> fipsmodule.cnf
> add
> module = /home/myopenssl/lib/ossl-modules/fips.so

Yes, this obviates the need for an explicit OPENSSL_MODULES
environment variable, and loads this particular module even
in applications that have a different default MODULESDIR
("openssl version -m").

> LNFLAGS += -L/home/myopenssl/lib -Wl,-rpath=/home/myopenssl/lib -lcrypto

Sounds like you're linking your application against this OpenSSL
runtime, but that's not required. Given your choice of "openssldir",,
It suffixes to just:

export OPENSSL_CONF=/home/myopenssl/openssl.cnf

and link the tests against the default system OpenSSL library,
but you can of course link against the custom runtime if you
wish.

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