|
Thanks Matt. I think I have what I need as far as loading providers. I also did the test you suggested with EVP_MD_fetch() and things failed as expected, the fetch did not work.
One other question on providers, given how I load everything, it seems like before application exit, the cleanup should be the following:
OSSL_LIB_CTX_free(fips_libctx);
OSSL_LIB_CTX_free(non_fips_libctx);
OSSL_PROVIDER_unload(defp);
Since I didn't "explicitly" load the fips and base providers with API calls, I only need to unlead the default provider, as well as free both library contexts.
Also, when I did try to unload the fips and base providers, the call to OSSL_PROVIDER_unload() hung, with the following backtrace:
#1 0x00007fb37f51d709 in CRYPTO_THREAD_read_lock () from /lib64/libcrypto.so.3
#2 0x00007fb37f50c068 in ossl_lib_ctx_get_data () from /lib64/libcrypto.so.3
#3 0x00007fb37f519482 in get_provider_store () from /lib64/libcrypto.so.3
#4 0x00007fb37f519af9 in provider_deactivate () from /lib64/libcrypto.so.3
#5 0x00007fb37f51b813 in ossl_provider_deactivate () from /lib64/libcrypto.so.3
#6 0x00007fb37f518399 in OSSL_PROVIDER_unload () from /lib64/libcrypto.so.3
Thanks,
Jason
From: Matt Caswell <matt@xxxxxxxxxxx>
Sent: Thursday, October 28, 2021 2:00 PM To: Jason Schultz <jetson23@xxxxxxxxxxx>; Dr Paul Dale <pauli@xxxxxxxxxxx>; openssl-users@xxxxxxxxxxx <openssl-users@xxxxxxxxxxx> Subject: Re: OpenSSL 3.0 FIPS questions 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@xxxxxxxxxxx> > *Sent:* Thursday, October 28, 2021 7:39 AM > *To:* Jason Schultz <jetson23@xxxxxxxxxxx>; Dr Paul Dale > <pauli@xxxxxxxxxxx>; openssl-users@xxxxxxxxxxx <openssl-users@xxxxxxxxxxx> > *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 > > |
