Running

openssl dgst -provider default -propquery fips=no -sign root.key -sha256 -out file.sig file.txt

fails with the exact same error message:

Could not open file or uri for loading private key from root.key
00DC3E2F857F0000:error:16000069:STORE routines:ossl_store_get0_loader_int:unregistered scheme:crypto/store/store_register.c:237:scheme=file
00DC3E2F857F0000:error:1608010C:STORE routines:inner_loader_fetch:unsupported:crypto/store/store_meth.c:357:No store loader found. For standard store loaders you need at least one of the default or base providers available. Did you forget to load them? Info: Global default library context, Scheme (file : 0), Properties (fips=no)

I believe this may be expected. If you pass "fips=no", you're explicitly asking for the non-fips implementation of an algorithm, not just any implementation regardless of whether it's fips-certified or not.

The issue here is fetching the store loader (basically the part that implements reading from a file), which also uses the algorithm fetching code and thus also respects the property queries provided. Both the base provider and the default provider implement the file store loader, but both of them define the file store loader with the "fips=yes" property:

- https://github.com/openssl/openssl/blob/openssl-3.0/providers/baseprov.c#L85-L92
- https://github.com/openssl/openssl/blob/openssl-3.0/providers/defltprov.c#L474-L481
- https://github.com/openssl/openssl/blob/openssl-3.0/providers/stores.inc

We could modify defltprov.c to not set fips=yes on the store implementation, but I think the issue here really is just that what you're trying to do cannot be done from the command line. You need the standard property query to load the store loaders, and the specifically pass "fips=no" as props argument of EVP_DigestSignInit_ex, which will then internally fetch an EVP_SIGNATURE algorithm as documented in the manpage:

> The pkey algorithm is used to fetch a EVP_SIGNATURE method implicitly, to be used for the actual signing. See "Implicit fetch" in provider(7) for more information about implicit fetches.

Btw, you can make this pass by changing the property query string to "-fips" (which I guess is not what you wanted because that doesn't tell you whether you're getting the FIPS or the non-FIPS implementation), or "?fips!=yes", which makes the query optional, but preferred, and the preference is to use anything that doesn't have "fips=yes".

The goal is to do operations that are not allowed by the fips provider, like signing with SHA-1 or DSA param generation, that doesn't work with `?fips!=yes` either:

$ openssl dsaparam -propquery '?fips!=yes' -out param.pem 2048
Error, DSA parameter generation context allocation failed
C0419DB3077F0000:error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:crypto/evp/evp_fetch.c:349:Global default library context, Algorithm (DSA : 103), Properties (<null>)

and `-fips` doesn't work for signing with sha-1 even if I switch the system to LEGACY policy (to allow SHA-1 signatures):

# openssl dgst -propquery '-fips' -sign root.key -sha1 -out file.sig file.txt
Error setting context
C0411E29967F0000:error:1C8000AE:Provider routines:rsa_setup_md:digest not allowed:providers/implementations/signature/rsa_sig.c:307:digest=SHA1

# openssl dgst -propquery '?fips!=yes' -sign root.key -sha1 -out file.sig file.txt
Error setting context
C0F10273467F0000:error:1C8000AE:Provider routines:rsa_setup_md:digest not allowed:providers/implementations/signature/rsa_sig.c:307:digest=SHA1

openssl's dgst module does not actually respect the passed property queries when signing and verifying, because it calls EVP_DigestVerifyInit/EVP_DigestSignInit, which do not accept property queries. This could would have to be re-written to use EVP_DigestVerifyInit_ex and EVP_DigestSignInit_ex, but those do not support engines, and I haven't yet figured out in which cases I can ignore the engines without breaking existing functionality.

That sounds like a question for upstream, but AFAIK, engines are deprecated so them getting broken by fixing a behaviour with providers is acceptable for upstream...

Same for dsaparam, it doesn't pass the required flags to EVP_PKEY_CTX_new_from_name():

diff --git a/apps/dsaparam.c b/apps/dsaparam.c
index 8025b8be67..b65de6e91c 100644
--- a/apps/dsaparam.c
+++ b/apps/dsaparam.c
@@ -147,7 +147,7 @@ int dsaparam_main(int argc, char **argv)
     if (out == NULL)
         goto end;

-    ctx = EVP_PKEY_CTX_new_from_name(NULL, "DSA", NULL);
+    ctx = EVP_PKEY_CTX_new_from_name(app_get0_libctx(), "DSA", app_get0_propq());
     if (ctx == NULL) {
         BIO_printf(bio_err,
                    "Error, DSA parameter generation context allocation failed\n");

I'll see what I can do to get those fixed upstream.

Note that it's not just those two that we care about, there's RSA key sizes, EC curves... most of tools in apps/ should be audited for property use...

Starting with DSA, more fixes to follow: https://github.com/openssl/openssl/pull/18576

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Low: openssl security and bug fix update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2023:2523