Adding:
config_diagnostics = 1
At the same level as the openssl_conf line should produce more output.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 4 Nov 2020, at 4:41 am, Thomas Dwyer III <tom...@tomiii.com> wrote:
>
> On Tue, Nov 3, 2020 at 7:13 AM Matt Caswell <m...@openssl.org
> <mailto:m...@openssl.org>> wrote:
>
>
> On 03/11/2020 00:55, Thomas Dwyer III wrote:
> > I'm having trouble getting RAND_status() to return 1 when my openssl.cnf
> > has both the default provider and the fips provider configured at the
> > same time:
> >
> > openssl_conf = openssl_init
> >
> > [openssl_init]
> > providers = provider_sect
> >
> > [provider_sect]
> > default = default_sect
> > fips = fips_sect
> >
> > [default_sect]
> > activate = 1
> >
> > .include /conf/openssl/fips.cnf
> >
> > If I remove either default or fips from [provider_sect] then
> > RAND_status() returns 1. If I leave them both specified there,
> > RAND_status() always returns 0. Is this the expected behavior or am I
> > doing something wrong? I understand that I must specify properties when
> > fetching algorithms in order to get deterministic behavior with multiple
> > providers loaded. Is there an analogous API for the PRNG that I'm
> > overlooking?
> >
> > Interestingly, setting activate=0 for either provider is not sufficient
> > to work around this issue.
>
> I tested this out and was able to replicate your behaviour.
>
> The reasons are a little complicated (see below) but the TL;DR summary
> is that there is an error in your config file. The ".include" line
> should specify a config file relative to OPENSSLDIR (or
> OPENSSL_CONF_INCLUDE if it is set). It cannot be an absolute path, and
> hence fips.cnf is not being found.
>
>
> This explanation does not match my observations. strace clearly shows my
> fips.cnf getting opened and read when my openssl.cnf has an absolute path.
> Likewise, strace shows stat64("fips.cnf", ...) failing (and thus no
> subsequent open() call) when I use a relative path. Furthermore, the
> documentation at https://www.openssl.org/docs/manmaster/man5/config.html
> <https://urldefense.com/v3/__https://www.openssl.org/docs/manmaster/man5/config.html__;!!GqivPVa7Brio!INBlyBEyGaYipDhT7pzBHbqNWwT_X9g1JEID9D5HZmFB-cmNRMWGUEoRqaZMNvs$>
> says this should be an absolute path.
>
> That said, see below..
>
>
>
> I've seen this error a few times now so I'm thinking that we should
> perhaps allow absolute paths. I'm not sure what the reason for
> disallowing them was.
>
> The reason it works if you comment out the "default" line is because
> that means the only provider left is the FIPS one. But the config line
> for that is faulty and therefore activating it fails. Ultimately we have
> not succesfully activated any provider. When you call RAND_status() it
> will attempt to fetch the RAND implementation and find that no providers
> have been activated. In this case we fallback and automatically activate
> the default provider. Hence you end up with RAND_status() still working.
>
> If you comment out the "fips" line then it works because it doesn't
> attempt to do anything with the fips provider, successfully activates
> the default provider, and hence RAND_status() works as expected.
>
> If you have both lines in the config file then it first successfully
> activates the default provider. It next attempts to activate the fips
> provider and fails. The way the config code works is that if any of the
> configured providers fail to activate then it backs out and deactivates
> all of them. At this point we're in a situation where a provider has
> been successfully activated and then deactivated again. The fallback
> activation of the default provider only kicks in if you've not attempted
> to activate any providers by the time you first need one. Therefore the
> default provider doesn't activate as a fallback either. Ultimately you
> end up with no active providers and RAND_status() fails.
>
> Ah ha! This explanation makes sense to me and indeed pointed me at the real
> problem. I had recompiled OpenSSL but I forgot to update the hmac in fips.cnf
> via fipsinstall. So yes, the fips provider was failing to activate because of
> that. As soon I fixed the hmac RAND_status() started working for me. So
> THANKS for that! :-)
>
>
> Tom.III
>
>
>
>
> We really should have a way of getting more verbose output in the event
> of config issues like this.
>
> Matt
