OpenSSL 3.0 FIPS questions

[Matt Caswell]

On 28/10/2021 14:49, Jason Schultz wrote:
> A call to OSSL_PROVIDER_available() says the "default" provider is 
> available;  however, I'm wondering if I should be loading the default 
> provider via *load_config() as well? I would have to uncomment the 
> "activate = 1" in the default section of my config though.

This is entirely a matter of personal taste. It makes no difference 
functionally whether you load a provider via OSSL_PROVIDER_load() 
directly, or whether you do it via the config file. Obviously if you do 
it via a config file it gives you the ability to modify what providers 
get loaded later without having to recompile.

If you decided to do it via config then you probably want *2* different 
config files. One for the fips libctx and one for the non-fips libctx.


> 
> I also still have this in my code:
> 
>      /* Disallow falling back to the default library context */
>      nullp = OSSL_PROVIDER_load(NULL, "null");
> 
> But not sure it's having any affect?

You could attempt to test it by attempting to fetch an algorithm. We 
would expect it to fail if it is working as expected. E.g.

EVP_MD *md = EVP_MD_fetch(NULL, "SHA2-256", NULL);
if (md != NULL) {
     /* Should not happen! The null provider should prevent this */
}


> 
> I do know that later in my application, both in "FIPS" or "non-FIPS" 
> mode, I can  create an SSL_CTX with SSL_CTX_new_ex(). I also 
> successfully call several APIs using both the fips_libctx or the 
> non_fips_libctx, for example:
> 
> status = SSL_CTX_use_PrivateKey_file(ctx,<file>,SSL_FILETYPE_PEM);
> 
> status = SSL_CTX_use_certificate_file(ctx,<file>,SSL_FILETYPE_PEM);
> 
> status = SSL_CTX_check_private_key(ctx);
> 
> 
> All return successfully. So I think what I have between configuration 
> files and API calls accomplishes what I need to. Would anyone reading 
> this agree?

It sounds correct from what you have described.

Matt

> 
> I'm running into another issue that I need to troubleshoot a bit more 
> before I add too much information and too many questions to a single 
> message.
> 
> Thanks to everyone for their help with this, things are starting to make 
> more sense now.
> 
> 
> 
> ------------------------------------------------------------------------
> *From:* Matt Caswell <matt at openssl.org>
> *Sent:* Thursday, October 28, 2021 7:39 AM
> *To:* Jason Schultz <jetson23 at hotmail.com>; Dr Paul Dale 
> <pauli at openssl.org>; openssl-users at openssl.org <openssl-users at openssl.org>
> *Subject:* Re: OpenSSL 3.0 FIPS questions
> 
> 
> On 27/10/2021 17:28, Jason Schultz wrote:
>> With these config files and the code above, the 
>> OSSL_PROVIDER_load(fips_libctx, "fips") call fails. Here are the 
>> messages from the ERR_print_errors_fp() call:
>> 
>> 2097C692B57F0000:error:1C8000D5:Provider routines:(unknown 
>> function):missing config data:providers/fips/self_test.c:289:
>> 2097C692B57F0000:error:1C8000E0:Provider routines:(unknown 
>> function):fips module entering error state:providers/fips/self_test.c:387:
>> 2097C692B57F0000:error:1C8000D8:Provider routines:(unknown 
>> function):self test post failure:providers/fips/fipsprov.c:706:
>> 2097C692B57F0000:error:078C0105:common libcrypto routines:(unknown 
>> function):init fail:crypto/provider_core.c:903:name=fips
> 
> 
> This tells us that the fips provider has successfully loaded, but then
> subsequently failed during its self-test because it cannot find its
> config data.
> 
> I can see that you have created a separate libctx for fips. However
> automatic loading of the config file only works for the *default*
> libctx. If you create your own one then you need to explicitly load the
> config file:
> 
> if (!OSSL_LIB_CTX_load_config(fips_libtx, "/usr/local/ssl/openssl.cnf")) {
>       /* error handling */
> }
> 
> Actually if you do this then you should not need to call
> OSSL_PROVIDER_load() explicitly to load the fips provider since you
> already activated it in the config file. You can either drop the
> explicit call to OSSL_PROVIDER_load() for the fips provider, or remove
> the "activate = 1" line in "fips_sect" in fipsmodule.cnf. This is just a
> minor optimisation though. Doing both is redundant but harmless. You
> could also load the base provider via config if you wanted to.
> 
> Matt
> 
>