Re: s_client SECLEVEL different in config file vs command line?

On Tue, Sep 23, 2025 at 04:07:59PM -0500, Ian Pilcher wrote:

> > You're also overriding the default crypto policy,
> 
> And that's the key.  /usr/share/crypto-policies/DEFAULT/opensslcnf.txt
> specifically disables SHA-1 signatures.
> 
>   [evp_properties]
>   rh-allow-sha1-signatures = no
> 
> So by not including that file (through its /etc/crypto-policies
> symlink), I've allowed them.  (This wouldn't work on RHEL or
> derivatives, where 'rh-allow-sha1-signatures = yes' is required to
> enable them.)

Your configuration can do that too, of course.

> Annoyingly, it seems to be completely impossible to override this
> setting from the command line, so a complete custom OpenSSL
> configuration is required for every one-off test of an old server.

Setting the "OPENSSL_CONF" environment variant to a file that uses
a more liberal policy works from the command-line:

    OPENSSL_CONF=/some/where/file.cnf cmd1 args ...
    OPENSSL_CONF=/some/other/file.cnf cmd2 args ...

FWIW, the openssl-s_client(1) command also supports a "-ssl_config"
option, which can override *most* of the RedHat tweaks via configuration
files of the form:

    /etc/pki/tls/openssl.cnf:
        # top-level outside any [section] (a.k.a. default section)
        ...
        openssl_conf = openssl_init
        ...
        [openssl_init]
        ...
        ssl_conf = ssl_module
        ...

        # Redhat magic
        [ssl_module]
        system_default = crypto_policy
        relaxed = [relaxed_ssl]

        [ crypto_policy ]
        .include = /etc/crypto-policies/back-ends/opensslcnf.config

        # Ignore typically impractical attack vectors by overriding
        # "crypto_policy" section settings in the above included file.
        [relaxed_ssl]
        # Note, s_client "-tls1*" and "-min_protocol" options override
        # this, last one wins.
        TLS.MinProtocol = TLSv1
        ...

    $ openssl s_client -ssl_config relaxed ...

but, sadly, that cannot lift the SHA1 signature taboo, which happens at
a higher layer, because the above ".include" file also introduces
two additional sections:

    [openssl_init]
    alg_section = evp_properties

    [evp_properties]
    rh-allow-sha1-signatures = no

and the "alg_section" (i.e. "evp_properties") section is separate from
the "ssl_conf" (i.e. "crypto_policy") section, so you'd need to override
the application name ("openssl_init" by default) to avoid that.

So, indeed for s_server and s_client, if you want SHA1 support, you
need to resort to the "OPENSSL_CONF" environment variable.

Applications that take advantage of explicit non-default initialisation
can choose a different set of settings, see:

    OPENSSL_INIT_new(3)
    OPENSSL_INIT_set_config_file_flags(3)
    OPENSSL_INIT_set_config_filename(3)
    OPENSSL_INIT_set_config_appname(3)
    OPENSSL_init_ssl(3)
    SSL_CTX_config(3)

The last of these augments, but does not disable, the SSL_CTX
initialisation specified in "system_default", so any settings there that
you don't like need explicit overrides.  The order of processing is:

    - "system_default" section settings as part of SSL_CTX_new()
    - any other application settings before any call to SSL_CTX_config(3)
    - SSL_CTX_config(3) section settings
    - any other settings after any call to SSL_CTX_config(3)

The processing of "-tls*" and "-min_protocol" in openssl-s_client(1)
is part of the last step above.

-- 
    Viktor.  🇺🇦 Слава Україні!

-- 
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/aNN3dza11Okxbx0o%40chardros.imrryr.org.