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
