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 <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 <pa...@openssl.org>
> Sent: Monday, October 25, 2021 9:37 PM
> To: Jason Schultz <jetso...@hotmail.com>; openssl-users@openssl.org
> <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 <openssl-users-boun...@openssl.org>
>> <mailto:openssl-users-boun...@openssl.org> on behalf of Dr Paul Dale
>> <pa...@openssl.org> <mailto:pa...@openssl.org>
>> Sent: Sunday, October 24, 2021 11:12 PM
>> To: openssl-users@openssl.org <mailto:openssl-users@openssl.org>
>> <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 <openssl-users-boun...@openssl.org>
>>> <mailto:openssl-users-boun...@openssl.org> on behalf of Dr Paul Dale
>>> <pa...@openssl.org> <mailto:pa...@openssl.org>
>>> Sent: Sunday, October 24, 2021 12:28 AM
>>> To: openssl-users@openssl.org <mailto:openssl-users@openssl.org>
>>> <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");
