Re: OpenSSL 3.0 FIPS questions

[Jason Schultz]

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,,SSL_FILETYPE_PEM);
SSL_CTX_use_certificate_file(ctx,,SSL_FILETYPE_PEM);
SSL_CTX_check_private_key(ctx);
fp = fopen(, "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:

00079FF8647F:error:0372: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 
Sent: Thursday, October 28, 2021 6:03 PM
To: Jason Schultz ; Dr Paul Dale ; 
openssl-users@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  0x7fb37f51d709 in CRYPTO_THREAD_read_lock () from
> /lib64/libcrypto.so.3
> #2  0x7fb37f50c068 in ossl_lib_ctx_get_data () from
> /lib64/libcrypto.so.3
> #3  0x7fb37f519482 in get_provider_store () from /lib64/libcrypto.so.3
> #4  0x7fb37f519af9 in provider_deactivate () from /lib64/libcrypto.so.3
> #5  0x7fb37f51b813 in ossl_provider_deactivate () from
> /lib64/libcrypto.so.3
> #6  0x7fb37f518399 in OSSL_PROVIDER_unload () from /lib64/libcrypto.so.3
>
> Thanks,
>
> Jason
>
>
> ----
> *From:* Matt Caswell 
> *Sent:* Thursday, October 28, 2021 2:00 PM
> *To:* Jason Schultz ; Dr Paul Dale
> ; openssl-users@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

Re: OpenSSL 3.0 FIPS questions

[Matt Caswell]

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  0x7fb37f51d709 in CRYPTO_THREAD_read_lock () from 
/lib64/libcrypto.so.3
#2  0x7fb37f50c068 in ossl_lib_ctx_get_data () from 
/lib64/libcrypto.so.3

#3  0x7fb37f519482 in get_provider_store () from /lib64/libcrypto.so.3
#4  0x7fb37f519af9 in provider_deactivate () from /lib64/libcrypto.so.3
#5  0x7fb37f51b813 in ossl_provider_deactivate () from 
/lib64/libcrypto.so.3

#6  0x7fb37f518399 in OSSL_PROVIDER_unload () from /lib64/libcrypto.so.3

Thanks,

Jason



*From:* Matt Caswell 
*Sent:* Thursday, October 28, 2021 2:00 PM
*To:* Jason Schultz ; Dr Paul Dale 
; openssl-users@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,,SSL_FILETYPE_PEM);

status = SSL_CTX_use_certificate_file(ctx,,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 
*Sent:* Thursday, October 28, 2021 7:39 AM
*To:* Jason Schultz ; Dr Paul Dale 
; openssl-users@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:


2097C692B57F:error:1C8000D5:Provider routines:(unknown 
function):missing config data:providers/fips/self_test.c:289:
2097C692B57F:error:1C8000E0:Provider routines:(unknown 
function):fips module entering error state:providers/fips/self_test.c:387:
2097C692B57F:error:1C8000D8:Provider routines:(unknown 
function):self test post failure:providers/fips/fipsprov.c:706:
2097C692B57F: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
c

Re: OpenSSL 3.0 FIPS questions

[Jason Schultz]

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  0x7fb37f51d709 in CRYPTO_THREAD_read_lock () from /lib64/libcrypto.so.3
#2  0x7fb37f50c068 in ossl_lib_ctx_get_data () from /lib64/libcrypto.so.3
#3  0x7fb37f519482 in get_provider_store () from /lib64/libcrypto.so.3
#4  0x7fb37f519af9 in provider_deactivate () from /lib64/libcrypto.so.3
#5  0x7fb37f51b813 in ossl_provider_deactivate () from /lib64/libcrypto.so.3
#6  0x7fb37f518399 in OSSL_PROVIDER_unload () from /lib64/libcrypto.so.3

Thanks,

Jason



From: Matt Caswell 
Sent: Thursday, October 28, 2021 2:00 PM
To: Jason Schultz ; Dr Paul Dale ; 
openssl-users@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,,SSL_FILETYPE_PEM);
>
> status = SSL_CTX_use_certificate_file(ctx,,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 
> *Sent:* Thursday, October 28, 2021 7:39 AM
> *To:* Jason Schultz ; Dr Paul Dale
> ; openssl-users@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:
>>
>> 2097C692B57F:error:1C8000D5:Provider routines:(unknown
>> function):missing config data:providers/fips/self_test.c:289:
>> 2097C692B57F:error:1C8000E0:Provider routines:(unknown
>> function):fips module entering error state:providers/fips/self_test.c:387:
>> 2097C692B57F:error:1C8000D8:Provider routines:(unknown
>> function):self test post failure:providers/fips/fipsprov.c:706:
>> 2097C692B57F: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

Re: 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,,SSL_FILETYPE_PEM);

status = SSL_CTX_use_certificate_file(ctx,,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 
*Sent:* Thursday, October 28, 2021 7:39 AM
*To:* Jason Schultz ; Dr Paul Dale 
; openssl-users@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:


2097C692B57F:error:1C8000D5:Provider routines:(unknown 
function):missing config data:providers/fips/self_test.c:289:
2097C692B57F:error:1C8000E0:Provider routines:(unknown 
function):fips module entering error state:providers/fips/self_test.c:387:
2097C692B57F:error:1C8000D8:Provider routines:(unknown 
function):self test post failure:providers/fips/fipsprov.c:706:
2097C692B57F: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

Re: OpenSSL 3.0 FIPS questions

[Jason Schultz]

Thanks Matt. I actually had this working (loading the fips_libctx using the 
*load_config() API) but I was hitting other issues and thought I was doing 
something wrong (more on that later).

So to review, I have my own config file, /usr/local/ssl/openssl-fips, with the 
relevant contents(some comments snipped):

.include /usr/local/ssl/fipsmodule.cnf

[openssl_init]
providers = provider_sect

# List of providers to load
[provider_sect]
default = default_sect
# The fips section name should match the section name inside the
# included fipsmodule.cnf.
fips = fips_sect
base = base_sect

[default_sect]
# activate = 1

[base_sect]
activate = 1

And then fipsmodule.cnf contains:

[fips_sect]
activate = 1
conditional-errors = 1
security-checks = 1
module-mac = 
E4:0D:C8:C3:1E:DB:2B:30:E6:F2:49:7B:F5:BD:10:5C:9A:2B:CC:C1:33:49:31:B5:C5:AF:50:AB:82:1E:AE:C9

By activating the fips and base providers via config, my application then calls:

OSSL_LIB_CTX_load_config(fips_libctx, "/usr/local/ssl/openssl-fips.cnf");

Which loads the "fips" and "base" providers in the fips_libctx, which I verify 
with:

OSSL_PROVIDER_available(fips_libctx, "fips");
and
OSSL_PROVIDER_available(fips_libctx, "base")

...and both are available.

However, remember I am trying to create two non-default library contexts (from 
earlier code):

fips_libctx = OSSL_LIB_CTX_new();
non_fips_libctx = OSSL_LIB_CTX_new();

Again, I think I have what I need for the fibs_libctx. For the non_fips_libctx, 
I'm calling:

defp = OSSL_PROVIDER_load(non_fips_libctx, "default");
nullp = OSSL_PROVIDER_load(NULL, "null");

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.

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?

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,,SSL_FILETYPE_PEM);

status = SSL_CTX_use_certificate_file(ctx,,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?

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 
Sent: Thursday, October 28, 2021 7:39 AM
To: Jason Schultz ; Dr Paul Dale ; 
openssl-users@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:
>
> 2097C692B57F:error:1C8000D5:Provider routines:(unknown
> function):missing config data:providers/fips/self_test.c:289:
> 2097C692B57F:error:1C8000E0:Provider routines:(unknown
> function):fips module entering error state:providers/fips/self_test.c:387:
> 2097C692B57F:error:1C8000D8:Provider routines:(unknown
> function):self test post failure:providers/fips/fipsprov.c:706:
> 2097C692B57F: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

Re: OpenSSL 3.0 FIPS questions

[Matt Caswell]

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:


2097C692B57F:error:1C8000D5:Provider routines:(unknown 
function):missing config data:providers/fips/self_test.c:289:
2097C692B57F:error:1C8000E0:Provider routines:(unknown 
function):fips module entering error state:providers/fips/self_test.c:387:
2097C692B57F:error:1C8000D8:Provider routines:(unknown 
function):self test post failure:providers/fips/fipsprov.c:706:
2097C692B57F: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

Re: OpenSSL 3.0 FIPS questions

[Jason Schultz]

Sorry, I meant to include the config information in my previous email. I should 
probably go back to the beginning, I've been trying a lot of different 
combinations without success, so unwinding to the beginning and taking one step 
at a time is probably appropriate. Since I want the FIPS changes limited to my 
application only, this is based on the response from Dr. Paul Dale earlier in 
the thread, the first approach he recommended, so the application code looks 
like this:

fipsp = OSSL_PROVIDER_load(fips_libctx, "fips");
if (fipsp == NULL)
  {
// error handling
 }

basep = OSSL_PROVIDER_load(fips_libctx, "base"); /* can't load keys without 
this */
if (basep == NULL)
  {
/* error handling */
   }

defp = OSSL_PROVIDER_load(non_fips_libctx, "default");
if (defp == NULL)
  {
/* error handling */

  }

Since I'm back to not using my own config file, this is the relevant content in 
/usr/local/ssl/openssl.cnf. Again, from Dr. Paul Dale's advice of needing a 
FIPS section, and not needing base or default sections:

openssl_conf = openssl_init

.include /usr/local/ssl/fipsmodule.cnf

[openssl_init]
providers = provider_sect

# List of providers to load
[provider_sect]
default = default_sect
# The fips section name should match the section name inside the
# included fipsmodule.cnf.
fips = fips_sect

[default_sect]
# activate = 1

Here is the /usr/local/ssl/fipsmodule.cnf file:

[fips_sect]
activate = 1
conditional-errors = 1
security-checks = 1
module-mac = 
E4:0D:C8:C3:1E:DB:2B:30:E6:F2:49:7B:F5:BD:10:5C:9A:2B:CC:C1:33:49:31:B5:C5:AF:50:AB:82:1E:AE:C9

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:

2097C692B57F:error:1C8000D5:Provider routines:(unknown function):missing 
config data:providers/fips/self_test.c:289:
2097C692B57F:error:1C8000E0:Provider routines:(unknown function):fips 
module entering error state:providers/fips/self_test.c:387:
2097C692B57F:error:1C8000D8:Provider routines:(unknown function):self test 
post failure:providers/fips/fipsprov.c:706:
2097C692B57F:error:078C0105:common libcrypto routines:(unknown 
function):init fail:crypto/provider_core.c:903:name=fips

So this does seem like I have something wrong as far as setup/install or 
configuration. I'm not sure if it's something in the config files above, or 
something with my application being able to find the fips.so, which was also 
mentioned. The code above in self_test.c that's throwing the error looks like 
the st parameter to SELF_TESET_post() is NULL, but I'm not sure what the actual 
problem is. The self test isn't set up to run correctly, the self test failed, 
maybe both, or maybe something else?

One of the links from Matt included a function  
OSSL_PROVIDER_set_default_search_path(). I'm wondering if that's needed since I 
don't have any environment variables set up? I'm not sure what the default 
search path is.

Jason



From: Matt Caswell 
Sent: Wednesday, October 27, 2021 10:34 AM
To: Jason Schultz ; Dr Paul Dale ; 
openssl-users@openssl.org 
Subject: Re: OpenSSL 3.0 FIPS questions



On 26/10/2021 20:17, Jason Schultz wrote:
> Thanks for all of the help so far. Unfortunately, I'm still struggling
> with this. There could be a number of issues, starting with the
> installation of OpenSSL. I basically followed the documentation and did
> the following:
>
> ./Configure enable-fips
>
> make
>
> make test
>
> make install
>
>
> The "make test" actually fails, but I did not troubleshoot as it seems
> like a lot of systems have issues here. But I know the .so produced when
> I build my application is linking to the correct OpenSSL libraries
> (libssl.so.3 and libcrypto.so.3). Checking the OpenSSL version shows 3.0.
>
> I've tried a number of combinations trying to make this work, starting
> with the code from Dr. Paul Dale in a previous message:
>
>  fips_libctx = OSSL_LIB_CTX_new();
>  if (!fips_libctx)
>  // error handling
>
>  non_fips_libctx = OSSL_LIB_CTX_new();
>  if (!non_fips_libctx)
>  // error handling
>
>  fipsp = OSSL_PROVIDER_load(fips_libctx, "fips");
>  if (fipsp == NULL)
>{
>  /* error handling */
>}
>
>  basep = OSSL_PROVIDER_load(fips_libctx, "base");
>  if (basep == NULL)
>{
>  /* error handling */
>}
>
>  defp = OSSL_PROVIDER_load(non_fips_libctx, "default");
>  if (defp == NULL)
>{
>  /* error handling */
>}
>
>  /* Disallow falling back to the default library context */
>  nullp = OSSL_PROVIDER_load(NULL, &q

Re: OpenSSL 3.0 FIPS questions

[Matt Caswell]

On 26/10/2021 20:17, Jason Schultz wrote:
Thanks for all of the help so far. Unfortunately, I'm still struggling 
with this. There could be a number of issues, starting with the 
installation of OpenSSL. I basically followed the documentation and did 
the following:


./Configure enable-fips

make

make test

make install


The "make test" actually fails, but I did not troubleshoot as it seems 
like a lot of systems have issues here. But I know the .so produced when 
I build my application is linking to the correct OpenSSL libraries 
(libssl.so.3 and libcrypto.so.3). Checking the OpenSSL version shows 3.0.


I've tried a number of combinations trying to make this work, starting 
with the code from Dr. Paul Dale in a previous message:


     fips_libctx = OSSL_LIB_CTX_new();
     if (!fips_libctx)
         // error handling

     non_fips_libctx = OSSL_LIB_CTX_new();
     if (!non_fips_libctx)
         // error handling

     fipsp = OSSL_PROVIDER_load(fips_libctx, "fips");
     if (fipsp == NULL)
       {
         /* error handling */
       }

     basep = OSSL_PROVIDER_load(fips_libctx, "base");
     if (basep == NULL)
       {
         /* error handling */
       }

     defp = OSSL_PROVIDER_load(non_fips_libctx, "default");
     if (defp == NULL)
       {
         /* error handling */
       }

     /* Disallow falling back to the default library context */
     nullp = OSSL_PROVIDER_load(NULL, "null");
     if (nullp == NULL)
       {
         /*error handling */
       }

With the code like the above, the OSSL_PROVIDER_load() calls fails for 
fips. If I try to use the fips_libctx in SSL_CTX_new_ex(), it fails and 
returns NULL, which is probably expected given the fips provider didn't 
load.


At that point, I wasn't sure if my application was using the (correct) 
config file in /usr/local/ssl/. I don't have any environment variables 
set up, and would prefer not to have to set any to get this to work. So 
I changed the provider load for FIPS to use OSSL_LIB_CTX_load_config():


     if (!OSSL_LIB_CTX_load_config(fips_libctx, 
"/usr/local/ssl/openssl-fips.cnf"))


What is in the /usr/local/ssl/openssl-fips.cnf config file?

Does the config file attempt to activate the FIPS provider itself? Does 
it supply the necessary FIPS provider config parameters?


Typically the config file has a ".include" directive in it which 
includes the necessary FIPS config params. That included file will look 
something like this:


$ cat fipsmodule.cnf

[fips_sect]

activate = 1

conditional-errors = 1

security-checks = 1

module-mac = 
95:06:06:D1:85:17:92:F6:7B:7D:C2:43:36:A4:59:5D:75:6F:39:E6:13:0B:4B:26:5A:1B:48:78:33:5B:BE:F0


Most likely what is happening is that the FIPS provider is failing to 
load. Either because it cannot find the fips.so file, or because the 
necessary FIPS config parameters above are not found or not correct.


You can test whether a provider is actually available for use or not 
using the OSSL_PROVIDER_available() function call. E.g.:


if (!OSSL_PROVIDER_available(fips_libctx, "fips")) {
/* error handling */
}

https://www.openssl.org/docs/man3.0/man3/OSSL_PROVIDER_available.html

If things are failing then you might find it helpful to dump the OpenSSL 
error stack to try and get some clues as to what the problem might be, e.g.


ERR_print_errors_fp(stdout);

https://www.openssl.org/docs/man3.0/man3/ERR_print_errors_fp.html

Matt

Re: OpenSSL 3.0 FIPS questions

[Jason Schultz]

Ah, OK. Yes, I am running on the same machine. Thanks for clarifying.



From: Kory Hamzeh 
Sent: Tuesday, October 26, 2021 9:15 PM
To: Jason Schultz 
Cc: Dr Paul Dale ; openssl-users@openssl.org 

Subject: Re: OpenSSL 3.0 FIPS questions

Actually, if you are running on the same machine that you built OpenSSL, you 
are fine. I cross-compile and have to do a fipsinstall each time. My apologies.


On Oct 26, 2021, at 12:17 PM, Jason Schultz 
mailto:jetso...@hotmail.com>> wrote:

Thanks for all of the help so far. Unfortunately, I'm still struggling with 
this. There could be a number of issues, starting with the installation of 
OpenSSL. I basically followed the documentation and did the following:

./Configure enable-fips
make
make test
make install

The "make test" actually fails, but I did not troubleshoot as it seems like a 
lot of systems have issues here. But I know the .so produced when I build my 
application is linking to the correct OpenSSL libraries (libssl.so.3 and 
libcrypto.so.3). Checking the OpenSSL version shows 3.0.

I've tried a number of combinations trying to make this work, starting with the 
code from Dr. Paul Dale in a previous message:

fips_libctx = OSSL_LIB_CTX_new();
if (!fips_libctx)
// error handling

non_fips_libctx = OSSL_LIB_CTX_new();
if (!non_fips_libctx)
// error handling

fipsp = OSSL_PROVIDER_load(fips_libctx, "fips");
if (fipsp == NULL)
  {
/* error handling */
  }


basep = OSSL_PROVIDER_load(fips_libctx, "base");
if (basep == NULL)
  {
/* error handling */
  }

defp = OSSL_PROVIDER_load(non_fips_libctx, "default");
if (defp == NULL)
  {
/* error handling */
  }

/* Disallow falling back to the default library context */

nullp = OSSL_PROVIDER_load(NULL, "null");
if (nullp == NULL)
  {
/*error handling */
  }

With the code like the above, the OSSL_PROVIDER_load() calls fails for fips. If 
I try to use the fips_libctx in SSL_CTX_new_ex(), it fails and returns NULL, 
which is probably expected given the fips provider didn't load.

At that point, I wasn't sure if my application was using the (correct) config 
file in /usr/local/ssl/. I don't have any environment variables set up, and 
would prefer not to have to set any to get this to work. So I changed the 
provider load for FIPS to use OSSL_LIB_CTX_load_config():

if (!OSSL_LIB_CTX_load_config(fips_libctx, 
"/usr/local/ssl/openssl-fips.cnf"))
  // error handling

This seems to work load the provider; however, there are two separate problems 
at this point. If FIPS is enabled by my application creating the SSL_CTX with  
the FIPS library context fails, returning NULL.

If FIPS is turned OFF by my application, creating an SSL_CTX with the 
non_fips_libctx  is successful, but later calling X509_get_pubkey() returns 
NULL, implying maybe something is wrong with the non_fips_libctx as well.

I've tried other combinations, but at this point I'm just guessing. Is there 
anything obvious I could be missing and I should be checking?

Thanks,

Jason



From: Dr Paul Dale mailto:pa...@openssl.org>>
Sent: Monday, October 25, 2021 9:37 PM
To: Jason Schultz mailto:jetso...@hotmail.com>>; 
openssl-users@openssl.org<mailto:openssl-users@openssl.org> 
mailto:openssl-users@openssl.org>>
Subject: Re: OpenSSL 3.0 FIPS questions

It was meant for the second method only.  The first method is using different 
library contexts to distinguish FIPS algorithms.  Using the properties in 
addition is harmless and might prevent a future mistake that breaks compliance.

Pauli

On 26/10/21 4:46 am, Jason Schultz wrote:
Thanks again. I think most of that makes sense. Going back to your initial 
response, there is something I'm not clear on.

The second method you explained (which I don't plan to use) starting with 
"Alternatively,..." included the calls to OSSL_PRIVIDER_load(), and then 
discussed calling the following API for FIPS:

   EVP_set_default_properties(NULL, “fips=yes”);

Was the EVP_set_default_properties() call specifically and only for the 2nd 
method, or did that API call apply to both the first and second methods you 
explained? From reading the doc for that call, it seems like I should be doing 
it if I use the first method as well.

Regards,

Jason


From: openssl-users 
<mailto:openssl-users-boun...@openssl.org> 
on behalf of Dr Paul Dale <mailto:pa...@openssl.org>
Sent: Sunday, October 24, 2021 11:12 PM
To: openssl-users@openssl.org<mailto:openssl-users@openssl.org> 
<mailto:openssl-users@openssl.org>
Subject: Re: OpenSSL 3.0 FIPS questions

The configuration shouldn't have much impact.  You will need a fips section 
specifying where the integrity check data are.  You shoul

Re: OpenSSL 3.0 FIPS questions

[Kory Hamzeh]

Actually, if you are running on the same machine that you built OpenSSL, you 
are fine. I cross-compile and have to do a fipsinstall each time. My apologies.


> On Oct 26, 2021, at 12:17 PM, Jason Schultz  wrote:
> 
> Thanks for all of the help so far. Unfortunately, I'm still struggling with 
> this. There could be a number of issues, starting with the installation of 
> OpenSSL. I basically followed the documentation and did the following:
> 
> ./Configure enable-fips
> make
> make test
> make install
> 
> The "make test" actually fails, but I did not troubleshoot as it seems like a 
> lot of systems have issues here. But I know the .so produced when I build my 
> application is linking to the correct OpenSSL libraries (libssl.so.3 and 
> libcrypto.so.3). Checking the OpenSSL version shows 3.0.
> 
> I've tried a number of combinations trying to make this work, starting with 
> the code from Dr. Paul Dale in a previous message:
> 
> fips_libctx = OSSL_LIB_CTX_new();
> if (!fips_libctx)
> // error handling
> 
> non_fips_libctx = OSSL_LIB_CTX_new();
> if (!non_fips_libctx)
> // error handling
> 
> fipsp = OSSL_PROVIDER_load(fips_libctx, "fips");
> if (fipsp == NULL)
>   {
> /* error handling */
>   }
> 
> 
> basep = OSSL_PROVIDER_load(fips_libctx, "base"); 
> if (basep == NULL)
>   {
> /* error handling */
>   }
> 
> defp = OSSL_PROVIDER_load(non_fips_libctx, "default");
> if (defp == NULL)
>   {
> /* error handling */
>   }
> 
> /* Disallow falling back to the default library context */
> 
> nullp = OSSL_PROVIDER_load(NULL, "null");
> if (nullp == NULL)
>   {
> /*error handling */
>   }
> 
> With the code like the above, the OSSL_PROVIDER_load() calls fails for fips. 
> If I try to use the fips_libctx in SSL_CTX_new_ex(), it fails and returns 
> NULL, which is probably expected given the fips provider didn't load.
> 
> At that point, I wasn't sure if my application was using the (correct) config 
> file in /usr/local/ssl/. I don't have any environment variables set up, and 
> would prefer not to have to set any to get this to work. So I changed the 
> provider load for FIPS to use OSSL_LIB_CTX_load_config():
> 
> if (!OSSL_LIB_CTX_load_config(fips_libctx, 
> "/usr/local/ssl/openssl-fips.cnf"))
>   // error handling
> 
> This seems to work load the provider; however, there are two separate 
> problems at this point. If FIPS is enabled by my application creating the 
> SSL_CTX with  the FIPS library context fails, returning NULL. 
> 
> If FIPS is turned OFF by my application, creating an SSL_CTX with the 
> non_fips_libctx  is successful, but later calling X509_get_pubkey() returns 
> NULL, implying maybe something is wrong with the non_fips_libctx as well. 
> 
> I've tried other combinations, but at this point I'm just guessing. Is there 
> anything obvious I could be missing and I should be checking?
> 
> Thanks,
> 
> Jason
> 
> 
> From: Dr Paul Dale 
> Sent: Monday, October 25, 2021 9:37 PM
> To: Jason Schultz ; openssl-users@openssl.org 
> 
> Subject: Re: OpenSSL 3.0 FIPS questions
>  
> It was meant for the second method only.  The first method is using different 
> library contexts to distinguish FIPS algorithms.  Using the properties in 
> addition is harmless and might prevent a future mistake that breaks 
> compliance.
> 
> Pauli
> 
> On 26/10/21 4:46 am, Jason Schultz wrote:
>> Thanks again. I think most of that makes sense. Going back to your initial 
>> response, there is something I'm not clear on. 
>> 
>> The second method you explained (which I don't plan to use) starting with 
>> "Alternatively,..." included the calls to OSSL_PRIVIDER_load(), and then 
>> discussed calling the following API for FIPS:
>>EVP_set_default_properties(NULL, “fips=yes”);
>> 
>> Was the EVP_set_default_properties() call specifically and only for the 2nd 
>> method, or did that API call apply to both the first and second methods you 
>> explained? From reading the doc for that call, it seems like I should be 
>> doing it if I use the first method as well.
>> 
>> Regards,
>> 
>> Jason
>> 
>> From: openssl-users  
>> <mailto:openssl-users-boun...@openssl.org> on behalf of Dr Paul Dale 
>>  <mailto:pa...@openssl.org>
>> Sent: Sunday, October 24, 2021 11:12 PM
>> To: openssl-users@openssl.org <mailto:openssl-users@openssl.org> 
>>  <mailto:openssl-

Re: OpenSSL 3.0 FIPS questions

[Jason Schultz]

Kory-

If I'm understanding the README-FIPS.md file, I don't need to do the 
"fipsinstall", it is done during the normal installation process when FIPS is 
enabled, presumably with the "enable-fips" on the configure command:

Installing the FIPS module
==

If the FIPS provider is enabled, it gets installed automatically during the
normal installation process. Simply follow the normal procedure (configure,
make, make test, make install) as described in the [INSTALL](INSTALL.md) file.

For example, on Unix the final command

$ make install

effectively executes the following install targets

$ make install_sw
$ make install_ssldirs
$ make install_docs
$ make install_fips # for `enable-fips` only

It looks like the fips.so shared object was produced from these steps on my 
system, in /usr/local/lib64/ossl-modules/.

Are you saying I still needed to do "openssl fipsinstall" after the 4 steps I 
already did?

Thanks,

Jason



From: Kory Hamzeh 
Sent: Tuesday, October 26, 2021 8:13 PM
To: Jason Schultz 
Cc: Dr Paul Dale ; openssl-users@openssl.org 

Subject: Re: OpenSSL 3.0 FIPS questions

Did you follow the steps in README-FIPS.md and do the “fipsinstall”?


On Oct 26, 2021, at 12:17 PM, Jason Schultz 
mailto:jetso...@hotmail.com>> wrote:

Thanks for all of the help so far. Unfortunately, I'm still struggling with 
this. There could be a number of issues, starting with the installation of 
OpenSSL. I basically followed the documentation and did the following:

./Configure enable-fips
make
make test
make install

The "make test" actually fails, but I did not troubleshoot as it seems like a 
lot of systems have issues here. But I know the .so produced when I build my 
application is linking to the correct OpenSSL libraries (libssl.so.3 and 
libcrypto.so.3). Checking the OpenSSL version shows 3.0.

I've tried a number of combinations trying to make this work, starting with the 
code from Dr. Paul Dale in a previous message:

fips_libctx = OSSL_LIB_CTX_new();
if (!fips_libctx)
// error handling

non_fips_libctx = OSSL_LIB_CTX_new();
if (!non_fips_libctx)
// error handling

fipsp = OSSL_PROVIDER_load(fips_libctx, "fips");
if (fipsp == NULL)
  {
/* error handling */
  }


basep = OSSL_PROVIDER_load(fips_libctx, "base");
if (basep == NULL)
  {
/* error handling */
  }

defp = OSSL_PROVIDER_load(non_fips_libctx, "default");
if (defp == NULL)
  {
/* error handling */
  }

/* Disallow falling back to the default library context */

nullp = OSSL_PROVIDER_load(NULL, "null");
if (nullp == NULL)
  {
/*error handling */
  }

With the code like the above, the OSSL_PROVIDER_load() calls fails for fips. If 
I try to use the fips_libctx in SSL_CTX_new_ex(), it fails and returns NULL, 
which is probably expected given the fips provider didn't load.

At that point, I wasn't sure if my application was using the (correct) config 
file in /usr/local/ssl/. I don't have any environment variables set up, and 
would prefer not to have to set any to get this to work. So I changed the 
provider load for FIPS to use OSSL_LIB_CTX_load_config():

if (!OSSL_LIB_CTX_load_config(fips_libctx, 
"/usr/local/ssl/openssl-fips.cnf"))
  // error handling

This seems to work load the provider; however, there are two separate problems 
at this point. If FIPS is enabled by my application creating the SSL_CTX with  
the FIPS library context fails, returning NULL.

If FIPS is turned OFF by my application, creating an SSL_CTX with the 
non_fips_libctx  is successful, but later calling X509_get_pubkey() returns 
NULL, implying maybe something is wrong with the non_fips_libctx as well.

I've tried other combinations, but at this point I'm just guessing. Is there 
anything obvious I could be missing and I should be checking?

Thanks,

Jason



From: Dr Paul Dale mailto:pa...@openssl.org>>
Sent: Monday, October 25, 2021 9:37 PM
To: Jason Schultz mailto:jetso...@hotmail.com>>; 
openssl-users@openssl.org<mailto:openssl-users@openssl.org> 
mailto:openssl-users@openssl.org>>
Subject: Re: OpenSSL 3.0 FIPS questions

It was meant for the second method only.  The first method is using different 
library contexts to distinguish FIPS algorithms.  Using the properties in 
addition is harmless and might prevent a future mistake that breaks compliance.

Pauli

On 26/10/21 4:46 am, Jason Schultz wrote:
Thanks again. I think most of that makes sense. Going back to your initial 
response, there is something I'm not clear on.

The second method you explained (which I don't plan to use) starting with 
"Alternatively,..." included the calls to OSSL_PRIVIDER_load(), and then 
discussed calling the

Re: OpenSSL 3.0 FIPS questions

[Kory Hamzeh]

Did you follow the steps in README-FIPS.md and do the “fipsinstall”?


> On Oct 26, 2021, at 12:17 PM, Jason Schultz  wrote:
> 
> Thanks for all of the help so far. Unfortunately, I'm still struggling with 
> this. There could be a number of issues, starting with the installation of 
> OpenSSL. I basically followed the documentation and did the following:
> 
> ./Configure enable-fips
> make
> make test
> make install
> 
> The "make test" actually fails, but I did not troubleshoot as it seems like a 
> lot of systems have issues here. But I know the .so produced when I build my 
> application is linking to the correct OpenSSL libraries (libssl.so.3 and 
> libcrypto.so.3). Checking the OpenSSL version shows 3.0.
> 
> I've tried a number of combinations trying to make this work, starting with 
> the code from Dr. Paul Dale in a previous message:
> 
> fips_libctx = OSSL_LIB_CTX_new();
> if (!fips_libctx)
> // error handling
> 
> non_fips_libctx = OSSL_LIB_CTX_new();
> if (!non_fips_libctx)
> // error handling
> 
> fipsp = OSSL_PROVIDER_load(fips_libctx, "fips");
> if (fipsp == NULL)
>   {
> /* error handling */
>   }
> 
> 
> basep = OSSL_PROVIDER_load(fips_libctx, "base"); 
> if (basep == NULL)
>   {
> /* error handling */
>   }
> 
> defp = OSSL_PROVIDER_load(non_fips_libctx, "default");
> if (defp == NULL)
>   {
> /* error handling */
>   }
> 
> /* Disallow falling back to the default library context */
> 
> nullp = OSSL_PROVIDER_load(NULL, "null");
> if (nullp == NULL)
>   {
> /*error handling */
>   }
> 
> With the code like the above, the OSSL_PROVIDER_load() calls fails for fips. 
> If I try to use the fips_libctx in SSL_CTX_new_ex(), it fails and returns 
> NULL, which is probably expected given the fips provider didn't load.
> 
> At that point, I wasn't sure if my application was using the (correct) config 
> file in /usr/local/ssl/. I don't have any environment variables set up, and 
> would prefer not to have to set any to get this to work. So I changed the 
> provider load for FIPS to use OSSL_LIB_CTX_load_config():
> 
> if (!OSSL_LIB_CTX_load_config(fips_libctx, 
> "/usr/local/ssl/openssl-fips.cnf"))
>   // error handling
> 
> This seems to work load the provider; however, there are two separate 
> problems at this point. If FIPS is enabled by my application creating the 
> SSL_CTX with  the FIPS library context fails, returning NULL. 
> 
> If FIPS is turned OFF by my application, creating an SSL_CTX with the 
> non_fips_libctx  is successful, but later calling X509_get_pubkey() returns 
> NULL, implying maybe something is wrong with the non_fips_libctx as well. 
> 
> I've tried other combinations, but at this point I'm just guessing. Is there 
> anything obvious I could be missing and I should be checking?
> 
> Thanks,
> 
> Jason
> 
> 
> From: Dr Paul Dale 
> Sent: Monday, October 25, 2021 9:37 PM
> To: Jason Schultz ; openssl-users@openssl.org 
> 
> Subject: Re: OpenSSL 3.0 FIPS questions
>  
> It was meant for the second method only.  The first method is using different 
> library contexts to distinguish FIPS algorithms.  Using the properties in 
> addition is harmless and might prevent a future mistake that breaks 
> compliance.
> 
> Pauli
> 
> On 26/10/21 4:46 am, Jason Schultz wrote:
>> Thanks again. I think most of that makes sense. Going back to your initial 
>> response, there is something I'm not clear on. 
>> 
>> The second method you explained (which I don't plan to use) starting with 
>> "Alternatively,..." included the calls to OSSL_PRIVIDER_load(), and then 
>> discussed calling the following API for FIPS:
>>EVP_set_default_properties(NULL, “fips=yes”);
>> 
>> Was the EVP_set_default_properties() call specifically and only for the 2nd 
>> method, or did that API call apply to both the first and second methods you 
>> explained? From reading the doc for that call, it seems like I should be 
>> doing it if I use the first method as well.
>> 
>> Regards,
>> 
>> Jason
>> 
>> From: openssl-users  
>> <mailto:openssl-users-boun...@openssl.org> on behalf of Dr Paul Dale 
>>  <mailto:pa...@openssl.org>
>> Sent: Sunday, October 24, 2021 11:12 PM
>> To: openssl-users@openssl.org <mailto:openssl-users@openssl.org> 
>>  <mailto:openssl-users@openssl.org>
>> Subject: Re: OpenSSL 3.0 FIPS questions
>>  
>>

Re: OpenSSL 3.0 FIPS questions

[Jason Schultz]

Thanks for all of the help so far. Unfortunately, I'm still struggling with 
this. There could be a number of issues, starting with the installation of 
OpenSSL. I basically followed the documentation and did the following:


./Configure enable-fips

make

make test

make install

The "make test" actually fails, but I did not troubleshoot as it seems like a 
lot of systems have issues here. But I know the .so produced when I build my 
application is linking to the correct OpenSSL libraries (libssl.so.3 and 
libcrypto.so.3). Checking the OpenSSL version shows 3.0.

I've tried a number of combinations trying to make this work, starting with the 
code from Dr. Paul Dale in a previous message:

fips_libctx = OSSL_LIB_CTX_new();
if (!fips_libctx)
// error handling

non_fips_libctx = OSSL_LIB_CTX_new();
if (!non_fips_libctx)
// error handling

fipsp = OSSL_PROVIDER_load(fips_libctx, "fips");
if (fipsp == NULL)
  {
/* error handling */
  }


basep = OSSL_PROVIDER_load(fips_libctx, "base");
if (basep == NULL)
  {
/* error handling */
  }

defp = OSSL_PROVIDER_load(non_fips_libctx, "default");
if (defp == NULL)
  {
/* error handling */
  }

/* Disallow falling back to the default library context */

nullp = OSSL_PROVIDER_load(NULL, "null");
if (nullp == NULL)
  {
/*error handling */
  }

With the code like the above, the OSSL_PROVIDER_load() calls fails for fips. If 
I try to use the fips_libctx in SSL_CTX_new_ex(), it fails and returns NULL, 
which is probably expected given the fips provider didn't load.

At that point, I wasn't sure if my application was using the (correct) config 
file in /usr/local/ssl/. I don't have any environment variables set up, and 
would prefer not to have to set any to get this to work. So I changed the 
provider load for FIPS to use OSSL_LIB_CTX_load_config():

if (!OSSL_LIB_CTX_load_config(fips_libctx, 
"/usr/local/ssl/openssl-fips.cnf"))
  // error handling

This seems to work load the provider; however, there are two separate problems 
at this point. If FIPS is enabled by my application creating the SSL_CTX with  
the FIPS library context fails, returning NULL.

If FIPS is turned OFF by my application, creating an SSL_CTX with the 
non_fips_libctx  is successful, but later calling X509_get_pubkey() returns 
NULL, implying maybe something is wrong with the non_fips_libctx as well.

I've tried other combinations, but at this point I'm just guessing. Is there 
anything obvious I could be missing and I should be checking?

Thanks,

Jason



From: Dr Paul Dale 
Sent: Monday, October 25, 2021 9:37 PM
To: Jason Schultz ; openssl-users@openssl.org 

Subject: Re: OpenSSL 3.0 FIPS questions

It was meant for the second method only.  The first method is using different 
library contexts to distinguish FIPS algorithms.  Using the properties in 
addition is harmless and might prevent a future mistake that breaks compliance.

Pauli

On 26/10/21 4:46 am, Jason Schultz wrote:
Thanks again. I think most of that makes sense. Going back to your initial 
response, there is something I'm not clear on.

The second method you explained (which I don't plan to use) starting with 
"Alternatively,..." included the calls to OSSL_PRIVIDER_load(), and then 
discussed calling the following API for FIPS:

   EVP_set_default_properties(NULL, “fips=yes”);

Was the EVP_set_default_properties() call specifically and only for the 2nd 
method, or did that API call apply to both the first and second methods you 
explained? From reading the doc for that call, it seems like I should be doing 
it if I use the first method as well.

Regards,

Jason


From: openssl-users 
<mailto:openssl-users-boun...@openssl.org> 
on behalf of Dr Paul Dale <mailto:pa...@openssl.org>
Sent: Sunday, October 24, 2021 11:12 PM
To: openssl-users@openssl.org<mailto:openssl-users@openssl.org> 
<mailto:openssl-users@openssl.org>
Subject: Re: OpenSSL 3.0 FIPS questions

The configuration shouldn't have much impact.  You will need a fips section 
specifying where the integrity check data are.  You shouldn't need base or 
default sections.


Pauli

On 25/10/21 5:23 am, Jason Schultz wrote:
Thank you for your response. I think all of that makes sense, and seems to 
accomplish what I want programmatically, limiting it to my application. I guess 
the only question I have is what about the config files? Should they remain as 
they were installed, or do I need to provide sections for fips, base, default, 
etc?

Regards,

Jason



From: openssl-users 
<mailto:openssl-users-boun...@openssl.org> 
on behalf of Dr Paul Dale <mailto:pa...@openssl.org>
Sent: Sunday, October 24, 2021 12:28 AM
To: openssl-users@opens

Re: OpenSSL 3.0 FIPS questions

[Dr Paul Dale]

It was meant for the second method only.  The first method is using 
different library contexts to distinguish FIPS algorithms.  Using the 
properties in addition is harmless and might prevent a future mistake 
that breaks compliance.


Pauli

On 26/10/21 4:46 am, Jason Schultz wrote:
Thanks again. I think most of that makes sense. Going back to your 
initial response, there is something I'm not clear on.


The second method you explained (which I don't plan to use) starting 
with "Alternatively,..." included the calls to OSSL_PRIVIDER_load(), 
and then discussed calling the following API for FIPS:

    EVP_set_default_properties(NULL, “fips=yes”);

Was the EVP_set_default_properties() call specifically and only for 
the 2nd method, or did that API call apply to both the first and 
second methods you explained? From reading the doc for that call, it 
seems like I should be doing it if I use the first method as well.


Regards,

Jason


*From:* openssl-users  on behalf of 
Dr Paul Dale 

*Sent:* Sunday, October 24, 2021 11:12 PM
*To:* openssl-users@openssl.org 
*Subject:* Re: OpenSSL 3.0 FIPS questions
The configuration shouldn't have much impact.  You will need a fips 
section specifying where the integrity check data are.  You shouldn't 
need base or default sections.



Pauli

On 25/10/21 5:23 am, Jason Schultz wrote:
Thank you for your response. I think all of that makes sense, and 
seems to accomplish what I want programmatically, limiting it to my 
application. I guess the only question I have is what about the 
config files? Should they remain as they were installed, or do I need 
to provide sections for fips, base, default, etc?


Regards,

Jason



*From:* openssl-users  
<mailto:openssl-users-boun...@openssl.org> on behalf of Dr Paul Dale 
 <mailto:pa...@openssl.org>

*Sent:* Sunday, October 24, 2021 12:28 AM
*To:* openssl-users@openssl.org <mailto:openssl-users@openssl.org> 
 <mailto:openssl-users@openssl.org>

*Subject:* Re: OpenSSL 3.0 FIPS questions
Oops, the second time this occurs "defp = 
OSSL_PROVIDER_load(non_fips_libctx, "default");" it should be "defp = 
OSSL_PROVIDER_load(NULL, "default");"



Pauli

On 24/10/21 10:06 am, Dr Paul Dale wrote:

defp = OSSL_PROVIDER_load(non_fips_libctx, "default");

Re: OpenSSL 3.0 FIPS questions

[Jason Schultz]

Thanks again. I think most of that makes sense. Going back to your initial 
response, there is something I'm not clear on.

The second method you explained (which I don't plan to use) starting with 
"Alternatively,..." included the calls to OSSL_PRIVIDER_load(), and then 
discussed calling the following API for FIPS:


   EVP_set_default_properties(NULL, “fips=yes”);

Was the EVP_set_default_properties() call specifically and only for the 2nd 
method, or did that API call apply to both the first and second methods you 
explained? From reading the doc for that call, it seems like I should be doing 
it if I use the first method as well.

Regards,

Jason


From: openssl-users  on behalf of Dr Paul 
Dale 
Sent: Sunday, October 24, 2021 11:12 PM
To: openssl-users@openssl.org 
Subject: Re: OpenSSL 3.0 FIPS questions

The configuration shouldn't have much impact.  You will need a fips section 
specifying where the integrity check data are.  You shouldn't need base or 
default sections.


Pauli

On 25/10/21 5:23 am, Jason Schultz wrote:
Thank you for your response. I think all of that makes sense, and seems to 
accomplish what I want programmatically, limiting it to my application. I guess 
the only question I have is what about the config files? Should they remain as 
they were installed, or do I need to provide sections for fips, base, default, 
etc?

Regards,

Jason



From: openssl-users 
<mailto:openssl-users-boun...@openssl.org> 
on behalf of Dr Paul Dale <mailto:pa...@openssl.org>
Sent: Sunday, October 24, 2021 12:28 AM
To: openssl-users@openssl.org<mailto:openssl-users@openssl.org> 
<mailto:openssl-users@openssl.org>
Subject: Re: OpenSSL 3.0 FIPS questions

Oops, the second time this occurs "defp = OSSL_PROVIDER_load(non_fips_libctx, 
"default");" it should be "defp = OSSL_PROVIDER_load(NULL, "default");"


Pauli

On 24/10/21 10:06 am, Dr Paul Dale wrote:
defp = OSSL_PROVIDER_load(non_fips_libctx, "default");

Re: OpenSSL 3.0 FIPS questions

[Dr Paul Dale]

The configuration shouldn't have much impact.  You will need a fips 
section specifying where the integrity check data are.  You shouldn't 
need base or default sections.



Pauli

On 25/10/21 5:23 am, Jason Schultz wrote:
Thank you for your response. I think all of that makes sense, and 
seems to accomplish what I want programmatically, limiting it to my 
application. I guess the only question I have is what about the config 
files? Should they remain as they were installed, or do I need to 
provide sections for fips, base, default, etc?


Regards,

Jason



*From:* openssl-users  on behalf of 
Dr Paul Dale 

*Sent:* Sunday, October 24, 2021 12:28 AM
*To:* openssl-users@openssl.org 
*Subject:* Re: OpenSSL 3.0 FIPS questions
Oops, the second time this occurs "defp = 
OSSL_PROVIDER_load(non_fips_libctx, "default");" it should be "defp = 
OSSL_PROVIDER_load(NULL, "default");"



Pauli

On 24/10/21 10:06 am, Dr Paul Dale wrote:

defp = OSSL_PROVIDER_load(non_fips_libctx, "default");

Re: OpenSSL 3.0 FIPS questions

[Jason Schultz]

Thank you for your response. I think all of that makes sense, and seems to 
accomplish what I want programmatically, limiting it to my application. I guess 
the only question I have is what about the config files? Should they remain as 
they were installed, or do I need to provide sections for fips, base, default, 
etc?

Regards,

Jason



From: openssl-users  on behalf of Dr Paul 
Dale 
Sent: Sunday, October 24, 2021 12:28 AM
To: openssl-users@openssl.org 
Subject: Re: OpenSSL 3.0 FIPS questions

Oops, the second time this occurs "defp = OSSL_PROVIDER_load(non_fips_libctx, 
"default");" it should be "defp = OSSL_PROVIDER_load(NULL, "default");"


Pauli

On 24/10/21 10:06 am, Dr Paul Dale wrote:
defp = OSSL_PROVIDER_load(non_fips_libctx, "default");

Re: OpenSSL 3.0 FIPS questions

[Dr Paul Dale]

Oops, the second time this occurs "defp = 
OSSL_PROVIDER_load(non_fips_libctx, "default");" it should be "defp = 
OSSL_PROVIDER_load(NULL, "default");"



Pauli

On 24/10/21 10:06 am, Dr Paul Dale wrote:

defp = OSSL_PROVIDER_load(non_fips_libctx, "default");

Re: OpenSSL 3.0 FIPS questions

[Dr Paul Dale]

There are several approaches you could take.  With two library contexts:

   fips_libctx = OSSL_LIB_CTX_new();
   non_fips_libctx = OSSL_LIB_CTX_new();

   fipsp = OSSL_PROVIDER_load(fips_libctx, "fips");
   basep = OSSL_PROVIDER_load(fips_libctx,"base");  /* can't load keys
   without this */
   defp = OSSL_PROVIDER_load(non_fips_libctx, "default");
   nullp = OSSL_PROVIDER_load(NULL, "null");       /* Disallow falling
   back to the default library context */


Then use either fips_libctx or non_fips_libctx for operations.


Alternatively, it can be done in one library context (the default here), 
although there is some risk of using non-FIPS crypto in a FIPS context:


   fipsp = OSSL_PROVIDER_load(NULL, "fips");
   defp = OSSL_PROVIDER_load(non_fips_libctx, "default");


For FIPS, make sure that "fips=yes" is included as a property query.  
The easiest way is to do this globally:


   EVP_set_default_properties(NULL, “fips=yes”);

For non-FIPS, just don't do anything.


Personally, I'd do the former two library contexts based approach and 
not worry about the properties.



Pauli

On 24/10/21 2:58 am, Jason Schultz wrote:


Quick aside: I know the 3.0 FIPS module is not "approved" yet, I'm 
just trying to get my application updates done in advance.



I’m porting an application from OpenSSL 1.1.1, which was originally 
written for OpenSSL 1.0.2, to OpenSSL 3.0. Going to 3.0, I need to 
incorporate FIPS usage. My Linux application basically is told if its 
user wants to use FIPS or not. We don’t use the cryptographic APIs 
(EVP_*), we just need to create an SSL_CTX, and SSL objects created 
with SSL_new() based on this SSL_CTX, which will then call SSL_read(), 
SSL_write(), etc. The application won’t “fetch” any algorithms. So my 
focus can been on Section 7.7 of the Wiki:


https://wiki.openssl.org/index.php/OpenSSL_3.0#Using_the_FIPS_module_in_SSL.2FTLS

Based on if FIPS is on or off, I will use the replacement for 
SSL_CTX_new() and call SSL_CTX_new_ex() either something like this:


ctx = SSL_CTX_new_ex(non_fips_libctx, NULL, TLS_method());

or this:

ctx = SSL_CTX_new_ex(fips_libctx, NULL, TLS_method());

Depending on if the users does not want FIPS, or wants FIPS, 
respectively.


Based on that and what Section 7.7 tells me, I know I need:

 1. A non-default library context with the FIPS provider loaded
(called fips_libctx), and
 2. A non-default library context with the default provider loaded
(called non_fips_libctx)

I know that I don’t want all applications using OpenSSL to use the 
FIPS module by default, so I’m just trying to configure mine 
correctly, using the APIs (and possibly config files). I also 
obviously don’t want to make my application use the FIPS module only.


Given all of the above I’m confused on how to set up #1 and #2. It 
seems like I need to use a combination of configuration files and 
programmatically calling APIs in my application. In the Wiki and the 
fips_module man page there is a section called “Programmatically 
loading the FIPS module (nondefault library context)”. I’m pretty sure 
this is what I want. The code example says it “assumes the existence 
of a config file called openssl-fips.cnf that automatically loads and 
configures the FIPS and base providers.”


The .cnf files that I have after the (FIPS) install of OpenSSL 3.0 are 
in /usr/local/ssl/: openssl.cnf and fipsmodule.cnf.


I guess the first thing is I’m confused on if the “openssl-fips.cnf” 
file referred to in the example is in addition to the two files above, 
or a replacement for one of them, and also what the contents of it 
need to be.


I had already made changes to the openssl.cnf file for FIPS (described 
in earlier sections of the Wiki):


# For FIPS

# Optionally include a file that is generated by the OpenSSL fipsinstall

# application. This file contains configuration data required by the 
OpenSSL


# fips provider. It contains a named section e.g. [fips_sect] which is

# referenced from the [provider_sect] below.

# Refer to the OpenSSL security policy for more information.

.include */usr/local/ssl/fipsmodule.cnfß***uncommented

[openssl_init]

providers = provider_sect

# List of providers to load

[provider_sect]

default = default_sect

# The fips section name should match the section name inside the

# included fipsmodule.cnf.

fips = fips_sectßuncommented

# If no providers are activated explicitly, the default one is 
activated implicitly.


# See man 7 OSSL_PROVIDER-default for more details.

#

# If you add a section explicitly activating any other provider(s), 
you most


# probably need to explicitly activate the default provider, otherwise it

# becomes unavailable in openssl.As a consequence applications 
depending on


# OpenSSL may not work correctly which could lead to significant system

# problems including inability to remotely access the system.

[default_sect]

activate = 1ßuncommented

I did this to make sure the FIPS provider was available and make 

Re: OpenSSL 3.0 FIPS questions

[Kory Hamzeh]

One way to do what you want is with two config file, and and in the first line 
of your main() function, add:

putenv(“OPENSSL_CONF=/path/to/your/conf”)

depending on whether you want to run in FIPS mode or not. Of course, this only 
works if FIPS is needed application wide, not on a per connection basis.

If running in FIPS mode, I would also call:

EVP_set_default_properties(NULL, “fips=yes”);


> On Oct 23, 2021, at 9:58 AM, Jason Schultz  wrote:
> 
> Quick aside: I know the 3.0 FIPS module is not "approved" yet, I'm just 
> trying to get my application updates done in advance.
> 
> I’m porting an application from OpenSSL 1.1.1, which was originally written 
> for OpenSSL 1.0.2, to OpenSSL 3.0. Going to 3.0, I need to incorporate FIPS 
> usage. My Linux application basically is told if its user wants to use FIPS 
> or not. We don’t use the cryptographic APIs (EVP_*), we just need to create 
> an SSL_CTX, and SSL objects created with SSL_new() based on this SSL_CTX, 
> which will then call SSL_read(), SSL_write(), etc. The application won’t 
> “fetch” any algorithms. So my focus can been on Section 7.7 of the Wiki: 
>  
> https://wiki.openssl.org/index.php/OpenSSL_3.0#Using_the_FIPS_module_in_SSL.2FTLS
>  
> 
>  
>  
> Based on if FIPS is on or off, I will use the replacement for SSL_CTX_new() 
> and call SSL_CTX_new_ex() either something like this: 
>  
> ctx = SSL_CTX_new_ex(non_fips_libctx, NULL, TLS_method()); 
>  
> or this: 
>  
> ctx = SSL_CTX_new_ex(fips_libctx, NULL, TLS_method()); 
>  
> Depending on if the users does not want FIPS, or wants FIPS, respectively.  
>  
> Based on that and what Section 7.7 tells me, I know I need: 
>  
> A non-default library context with the FIPS provider loaded (called 
> fips_libctx), and 
> A non-default library context with the default provider loaded (called 
> non_fips_libctx) 
>  
> I know that I don’t want all applications using OpenSSL to use the FIPS 
> module by default, so I’m just trying to configure mine correctly, using the 
> APIs (and possibly config files). I also obviously don’t want to make my 
> application use the FIPS module only.  
>  
> Given all of the above I’m confused on how to set up #1 and #2. It seems like 
> I need to use a combination of configuration files and programmatically 
> calling APIs in my application. In the Wiki and the fips_module man page 
> there is a section called “Programmatically loading the FIPS module 
> (nondefault library context)”. I’m pretty sure this is what I want. The code 
> example says it “assumes the existence of a config file called 
> openssl-fips.cnf that automatically loads and configures the FIPS and base 
> providers.”  
>  
> The .cnf files that I have after the (FIPS) install of OpenSSL 3.0 are in 
> /usr/local/ssl/: openssl.cnf and fipsmodule.cnf. 
>  
> I guess the first thing is I’m confused on if the “openssl-fips.cnf” file 
> referred to in the example is in addition to the two files above, or a 
> replacement for one of them, and also what the contents of it need to be.  
>  
> I had already made changes to the openssl.cnf file for FIPS (described in 
> earlier sections of the Wiki): 
>  
> # For FIPS 
> # Optionally include a file that is generated by the OpenSSL fipsinstall 
> # application. This file contains configuration data required by the OpenSSL 
> # fips provider. It contains a named section e.g. [fips_sect] which is 
> # referenced from the [provider_sect] below. 
> # Refer to the OpenSSL security policy for more information. 
> .include /usr/local/ssl/fipsmodule.cnfß uncommented 
>   
> [openssl_init] 
> providers = provider_sect 
>   
> # List of providers to load 
> [provider_sect] 
> default = default_sect 
> # The fips section name should match the section name inside the 
> # included fipsmodule.cnf. 
> fips = fips_sect ß uncommented 
>   
> # If no providers are activated explicitly, the default one is activated 
> implicitly. 
> # See man 7 OSSL_PROVIDER-default for more details. 
> # 
> # If you add a section explicitly activating any other provider(s), you most 
> # probably need to explicitly activate the default provider, otherwise it 
> # becomes unavailable in openssl.  As a consequence applications depending on 
> # OpenSSL may not work correctly which could lead to significant system 
> # problems including inability to remotely access the system. 
> [default_sect] 
> activate = 1 ß uncommented 
>  
> I did this to make sure the FIPS provider was available and make sure the 
> default provider was activated. 
>  
> I also changed the fipsmodule.cnf file to comment out the activate = 1 line: 
>  
> [fips_sect] 
> # activate = 1 
> conditional-errors = 1 
> security-checks = 1 
> module-mac = 
> E4:0D:C8:C3:1E:DB:2B:30:E6:F2:49:7B:F5:BD:10:5C:9A:2B:CC:C1:33:49:31:B5:C5:AF:50:AB:82:1E:AE:C9
>  
>  
> That was from the “Programmatically loading