s_client SECLEVEL different in config file vs command line?

I am trying to set up an Apache reverse proxy that will allow me to use
modern browsers to manage my old "smart" switches.  These old switches
only support TLS 1.0 using the DHE-RSA-AES256-SHA cipher, which uses
SHA-1 digests.  I'll ultimately need to create an Apache configuration,
but I'm working with openssl s_client right now, because baby steps.

I've noticed a behavior that I don't understand when setting the cipher
and SECLEVEL.  In short, setting "CipherString = DHE-RSA-AES256-
SHA@SECLEVEL=0" in my configuration allows s_client to connect to one of
the old switches, but specifying "-cipher DHE-RSA-AES256-SHA@SECLEVEL=0"
on the command line does not have the same effect.

Here is the configuration file that I've created (INSECURE.cnf):

> HOME = .
> openssl_conf = openssl_init
> config_diagnostics = 1
> 
> [openssl_init]
> providers = provider_sect
> ssl_conf = ssl_module
> 
> [provider_sect]
> default = default_sect
> 
> [default_sect]
> activate = 1
> 
> [ssl_module]
> system_default = crypto_policy
> 
> [crypto_policy]
> CipherString = DHE-RSA-AES256-SHA@SECLEVEL=0
> Options = UnsafeLegacyServerConnect

Using this file, s_client connects successfully.

> $ OPENSSL_CONF=./INSECURE.cnf openssl s_client -connect switch1.penurio.us:443
> Connecting to 172.31.4.1
> CONNECTED(00000003)
...
> ---
> SSL handshake has read 3026 bytes and written 489 bytes
> Verification: OK
> ---
> New, SSLv3, Cipher is DHE-RSA-AES256-SHA
> Server public key is 2048 bit
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> SSL-Session:
>     Protocol  : TLSv1
>     Cipher    : DHE-RSA-AES256-SHA
>     Session-ID: 
>     Session-ID-ctx: 
>     Master-Key: 6A299C2D5036546F6A64375F01E3F3F5CCDEA0FE3C1FA681C14647AC0DAA5BB0CD587346A62F3C1095F3CC8DAA69CC2D
>     PSK identity: None
>     PSK identity hint: None
>     SRP username: None
>     Start Time: 1758380946
>     Timeout   : 7200 (sec)
>     Verify return code: 0 (ok)
>     Extended master secret: no
> ---
> closed

But specifying the cipher and security level on the command line (along
with -tls1 and -legacy_renegotiation) doesn't work.

> $ openssl s_client -connect switch1.penurio.us:443 -legacy_renegotiation -cipher DHE-RSA-AES256-SHA@SECLEVEL=0 -tls1
> Connecting to 172.31.4.1
> CONNECTED(00000003)
> depth=1 O=PENURIO.US, CN=Certificate Authority
> verify return:1
> depth=0 O=PENURIO.US, CN=switch1.penurio.us
> verify return:1
> 40A75F54177F0000:error:03000098:digital envelope routines:do_sigver_init:invalid digest:crypto/evp/m_sigver.c:342:
> 40A75F54177F0000:error:0A080006:SSL routines:tls_process_key_exchange:EVP lib:ssl/statem/statem_clnt.c:2521:

I'm still getting an "invalid digest" error, presumably due to the SHA-1
digest algorithm.

Can anyone explain why these two methods of specifying the cipher are
behaving differently?  (And what would I need to put on the command line
to allow SHA-1 digests?)

TIA!

(This is all done with OpenSSL 3.2.4 on Fedora 42.)

-- 
========================================================================
If your user interface is intuitive in retrospect ... it isn't intuitive
========================================================================

-- 
You received this message because you are subscribed to the Google Groups "openssl-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openssl-users+unsubscribe-MCmKBN63+Bmbup2nOX2J7Q@public.gmane.org
To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/061e7c60-0c31-4bc8-b495-240260cf8b9b%40gmail.com.