<div dir="ltr">Thank you all for your detailed and quick responses 😊.  It has helped to understand fips in a more clear way.<div><br></div><div>one more question I have is -  we opted to load providers programmatically so that we don't need to maintain the openssl.cnf file and it's path separately. But when fips provider comes into picture , from my findings it looks like fipsmodule.cnf is needed and it is to be used through openssl.cnf only(by adding .include <fipsmodule.cnf path> and a few more changes).</div><div>1. Do we have any way to load fips provider without using configuration files(openssl.cnf,fipsmodule.cnf)? </div><div>2.  may be using only 1 of them but not both ?</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 30 Jun 2023 at 13:47, Matt Caswell <<a href="mailto:matt@openssl.org">matt@openssl.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 30/06/2023 08:58, Zhongyan Wang wrote:<br>
> How to specify the path of openssl.cnf and so-called fipsmodule.cnf <br>
> programmatically when load FIPS Provider?<br>
<br>
You can use `OSSL_LIB_CTX_load_config` to load a specified config file.<br>
<br>
It is recommended that you provide an absolute path to fipsmodule.cnf in <br>
openssl.cnf. If a relative path is provided then the <br>
OPENSSL_CONF_INCLUDE environment variable is assumed to contain a <br>
directory which is prepended to the include path.<br>
<br>
If OPENSSL_CONF_INCLUDE does not exist then you can add this line to <br>
openssl.cnf to specify the include directory:<br>
<br>
.pragma includedir:/path/to/a/directory<br>
<br>
If the result is still relative then it is assumed to be relative to the <br>
current working directory of the process.<br>
<br>
Matt<br>
<br>
> <br>
> Our product has a build-in openssl bin and library, but doesn’t have any <br>
> openssl configure file due to history reason.<br>
> <br>
> I will add execute “make fipsinstall” during the product installation to <br>
> generate the fipsmodule.cnf.<br>
> <br>
> Since customer can install product to anywhere and “make fipsinstall” <br>
> can also install fipsmodule.cnf to anywhere and openssl library won’t <br>
> know the location.<br>
> <br>
> So I can’t successfully load FIPS provider because it doesn’t know where <br>
> is the fipsmodule.cnf. Per my test, it seems to find fipsmodule.cnf in <br>
> pre-fix path configure in compile.<br>
> <br>
> My key point is: is there a method to let openssl know where to <br>
> load/check fipsmodule.cnf?<br>
> <br>
> *From:* openssl-users <<a href="mailto:openssl-users-bounces@openssl.org" target="_blank">openssl-users-bounces@openssl.org</a>> *On Behalf Of <br>
> *<a href="mailto:pauli@openssl.org" target="_blank">pauli@openssl.org</a><br>
> *Sent:* Friday, June 30, 2023 15:16<br>
> *To:* <a href="mailto:openssl-users@openssl.org" target="_blank">openssl-users@openssl.org</a><br>
> *Subject:* Re: questions on fips provider<br>
> <br>
> *EXTERNAL EMAIL*<br>
> <br>
> <br>
> <br>
> Answers below....<br>
> <br>
>     1) Is there a way to static link FIPS? I see at many places that<br>
>     fips cannot be statically linked but would like to know if we<br>
>     have any other ways to do that.<br>
> <br>
> <br>
> No.  This was a design goal/limitation from the start.  Statically <br>
> linking the FIPS provider would have been a major source of pain.  We <br>
> managed it for 1.0.2 with some inspirational assembly coding but that <br>
> approach wouldn't have worked for 3.0.<br>
> <br>
> <br>
>     2) If it is dynamic linking then does FIPS has any integrity check<br>
>     to make sure <a href="http://fips.so/fips.dll" rel="noreferrer" target="_blank">fips.so/fips.dll</a> <<a href="http://fips.so/fips.dll" rel="noreferrer" target="_blank">http://fips.so/fips.dll</a>> is the right<br>
>     one? and not some thing tampered by some body(as per my findings we<br>
>     have some check in configuration file as mentioned in the below<br>
>     attached snapshot 3rd line)<br>
> <br>
> <br>
> Yes it does do an integrity check on load.  This was the main reason to <br>
> limit the FIPS provider to being a loadable module.  The approach taken <br>
> in the 1.0.2 FOM wasn't viable with the re-architecture.<br>
> <br>
> <br>
>     3) can both legacy and fips providers be loaded and used?<br>
> <br>
> <br>
> Technically yes, but you'll not be FIPS compliant unless you are <br>
> *extremely* careful.<br>
> Which means talking to your FIPS labs and getting official resolutions <br>
> on the specifics.<br>
> The OpenSSL developers are ***not*** FIPS experts.  Only a FIPS lab can <br>
> definitively answer questions like this.<br>
> <br>
> <br>
>     4) Is it possible If i have built openssl with no-module configure<br>
>     option (to statically link legacy provider) and also wanted to use <br>
>     openssl-3.0.8 built fips module here? If yes then in what way can it<br>
>     be done?<br>
> <br>
> <br>
> Honestly not sure here.  You *must* load the FIPS provider dynamically <br>
> to be compliant.<br>
> If that's possible with the no-moduleoption, you should be okay.  I <br>
> suspect it isn't.  Try it and see.<br>
> <br>
> If you don't get a definitive result, this means talking to your FIPS <br>
> labs and getting official resolutions on the specifics.<br>
> The OpenSSL developers are ***not*** FIPS experts.  Only a FIPS lab can <br>
> definitively answer questions like this.<br>
> <br>
> <br>
>     5) Is it possible to load multiple providers like default, leacy and<br>
>     also fips programmatically using  OSSL_PROVIDER_load function ?<br>
> <br>
> <br>
> Absolutely it is possible.  However, meeting FIPS requirements <br>
> afterwards could be problematic.<br>
> This means talking to your FIPS labs and getting official resolutions on <br>
> the specifics.<br>
> The OpenSSL developers are ***not*** FIPS experts.  Only a FIPS lab can <br>
> definitively answer questions like this.<br>
> <br>
> Having several library contexts with each having different providers <br>
> loaded might be a way to circumvent the strict interpretation of the <br>
> requirements.  This means talking to your FIPS labs and getting official <br>
> resolutions on the specifics.<br>
> The OpenSSL developers are ***not*** FIPS experts.  Only a FIPS lab can <br>
> definitively answer questions like this.<br>
> <br>
> <br>
>     6) When multiple providers like for ex:  FIPS and default provider<br>
>     are enabled and when an encryption function is called, then<br>
>     algorithm from which provider is picked(from my findings it can use<br>
>     any of the loaded provider implementations )? assumption that we<br>
>     have *not* used property query string during algorithm fetches to<br>
>     specify which implementation to be used.<br>
> <br>
> <br>
> The OpenSSL project *deliberately* makes *no guarantee* about which <br>
> provider is used in such cases.  It is deterministic currently, but <br>
> there is no guarantee that we'll not change the order of resolution or <br>
> making it randomly non-deterministic in any future releases.  Honestly, <br>
> expect that *we will* make changes to the resolution order in the <br>
> future.  Such a change is not considered breaking and doesn't have to <br>
> adhere to our stable release policy.<br>
> <br>
> Our best recommendation is to not mix providers in library contexts.  <br>
> Seek resolution from you FIPS lab.<br>
> <br>
> <br>
> Dr Paul Dale<br>
> <br>
> ================================<br>
> Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA <br>
> 02451 ■ Main Office Toll Free Number: +1 855.577.4323<br>
> Contact Customer Support: <br>
> <a href="https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport" rel="noreferrer" target="_blank">https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport</a><br>
> Unsubscribe from Marketing Messages/Manage Your Subscription Preferences <br>
> - <a href="http://www.rocketsoftware.com/manage-your-email-preferences" rel="noreferrer" target="_blank">http://www.rocketsoftware.com/manage-your-email-preferences</a><br>
> Privacy Policy - <a href="http://www.rocketsoftware.com/company/legal/privacy-policy" rel="noreferrer" target="_blank">http://www.rocketsoftware.com/company/legal/privacy-policy</a><br>
> ================================<br>
> <br>
> This communication and any attachments may contain confidential <br>
> information of Rocket Software, Inc. All unauthorized use, disclosure or <br>
> distribution is prohibited. If you are not the intended recipient, <br>
> please notify Rocket Software immediately and destroy all copies of this <br>
> communication. Thank you.<br>
> <br>
</blockquote></div>