OpenSSL 3.0 FIPS questions
Jason Schultz
jetson23 at hotmail.com
Sun Oct 31 21:21:32 UTC 2021
Thanks to everyone for the help so far. I think I have things set up correctly as far as FIPS, providers, and library contexts. I'm hitting another problem that I think is related to the migration to OpenSSL 3.0, as this code works with OpenSSL 1.1.1 (and 1.0.2 before it). When looking at the documentation pages for 1.1.1 vs 3.0, I'm not seeing any differences between the OpenSSL APIs I'm calling in the 2 different release levels.
Here is the sequence, I'm basically setting up my certificate and private key, both in PEM format, for the server, then I need to extract some information from them:
ctx = SSL_CTX_new_ex(non_fips_libctx, NULL, TLS_method());
SSL_CTX_use_PrivateKey_file(ctx,<keyfile>,SSL_FILETYPE_PEM);
SSL_CTX_use_certificate_file(ctx,<certfile>,SSL_FILETYPE_PEM);
SSL_CTX_check_private_key(ctx);
fp = fopen(<certfile>, "r");
mycert = PEM_read_X509(fp, NULL, 0, NULL);
pkey = X509_get_pubkey(mycert);
All functions return good statuses or non-NULL pointers until the last one, X509_get_pubkey() returns NULL. I have tried this with RSA and Elliptic Curve cert/key pairs. I have tried with pairs created with OpenSSL 1.1.1 as well as 3.0 via the command line.
This seems like a pretty straightforward operation, but it appears that key->pkey is NULL in the code below:
EVP_PKEY *X509_PUBKEY_get0(const X509_PUBKEY *key)
{
if (key == NULL) {
ERR_raise(ERR_LIB_X509, ERR_R_PASSED_NULL_PARAMETER);
return NULL;
}
if (key->pkey == NULL) {
/* We failed to decode the key when we loaded it, or it was never set */
ERR_raise(ERR_LIB_EVP, EVP_R_DECODE_ERROR);
return NULL;
}
return key->pkey;
}
I got to this code from the error information I dumped from OpenSSL:
00079FF8647F0000:error:03000072:digital envelope routines:(unknown function):decode error:crypto/x509/x_pubkey.c:444:
I can paste certificates if anyone thinks it will help, but I've tried several types of cert/key pairs, and using the command line to do "openssl x509 -pubkey..." displays the public key just fine with the certificate file in question.
Here is an example of the openssl command line to create one of the cert/key pairs that hits this error:
openssl req -new -x509 -nodes -newkey ec:<(openssl ecparam -name secp384r1) -keyout threecert.key -out threecert.crt -days 365
I kept this on the same "FIPS OpenSSL 3.0" thread because I'm not 100% sure it's unrelated.
What am I missing here?
Thanks,
Jason
________________________________
From: Matt Caswell <matt at openssl.org>
Sent: Thursday, October 28, 2021 6:03 PM
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 28/10/2021 18:33, Jason Schultz wrote:
> 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);
Yes, but I would recommend unloading the default provider before freeing
the libctx it is associated with. Otherwise bad things might happen.
>
> 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.
Correct.
>
> Also, when I did try to unload the fips and base providers, the call to
> OSSL_PROVIDER_unload() hung, with the following backtrace:
Yeah. Don't do that. :-)
Matt
>
> #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 at openssl.org>
> *Sent:* Thursday, October 28, 2021 2:00 PM
> *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 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20211031/25e73573/attachment-0001.html>
More information about the openssl-users
mailing list