recommended way to do created fipsmodule.cnf file on client machine.

[aniljadaun]

Hi Team,

We are using the OpenSSL 3.0 version in our product. We will be shipping the OpenSSL libraries with our package. Please recommend a way to make sure that the app installed on the client machine is FIPS compliant. Should we package the OpenSSL libraries and the openss.cnf file with our app, and then create the fipsmodule.cnf file at runtime? Are there any recommended ways to create this workflow, and are there any potential issues that we should be aware of?

Any documentation around this ? I already have https://www.openssl.org/docs/man3.0/man7/fips_module.html

[paulidale]

The README-FIPS.md file is also useful.

As per the security policy, you should create the fipsmodule.cnf file on the client machine. Not doing so isn't strictly FIPS compliant. The instructions for doing this are in the security policy (the latest version should always be linked from the download page). Look in the policy's first appendix. Essentially, you should run the openssl fipsinstall command on the client to do this.

Also note that currently only OpenSSL 3.0.0 and 3.0.8 have had their FIPS provider validated. Any other version will not produce a compliant FIPS provider. However, you can use any version of OpenSSL (3.0.x or 3.1.x) with either of these FIPS providers. Instructions for doing this are in the README-FIPS file.

[aniljadaun]

Hi @paulidale
After succesfully loading fips module and setting EVP_default_properties_enable_fips(NULL, 1);
Which of these is needed to load fips compliant version of digest algorithm

1. EVP_MD* md = EVP_sha256();
2. EVP_MD* md = EVP_MD_fetch(NULL, "SHA1", "provider=fips");

Case 2 works will surely load fips compliant version , what does the case 1 fetches ?

[paulidale]

Both will load a FIPS compliant version. The second is more efficient. However, I'd recommend this instead:

EVP_MD* md = EVP_MD_fetch(NULL, "SHA1", "");

The EVP_default_properties_enable_fips call is setting a default property query for provider=fips so no need to duplicate this.

[aniljadaun]

Hi @paulidale

I have a doubt regarding behaviour in fips mode for non-fips supported algorithm .

Workflow:
provider loaded for default,legacy,base and fips.
set EVP_default_properties_enable_fips(NULL,1);

Using EVP_MD_fetch(NULL, "algoname", "");

In case of above workflow where legacy provider is loaded but default provider being set to fips .Would we be able to fetch legacy algorithm

1. EVP_MD_fetch(NULL, "MD5", "");
2. EVP_MD_fetch(NULL, "MD5", "legacy");

My understanding is since legacy is independent of fips provider so it should be able to fetch legacy algorithm regardless of fips mode.
What would be behaviour for EVP_MD_fetch for non-fips suppported algorithm in fips mode ?

[paulidale]

Both of those should fail. Calling EVP_default_properties_enable_fips(NULL,1) sets the global property query fips=yes. So both of the calls you list will still be mandating that a FIPS approved algorithm is selected & MD5 won't be found.

This query ought to return a usable MD5 implementation: EVP_MD_fetch(NULL, "MD5", "fips=no").