OpenSSL: Activating Legacy Provider System-Wide

OpenSSL 3.0 Removes Algorithms

With the release of version 3.0, various symmetric ciphers, hashing algorithms and key derivation functions were removed from OpenSSL's standard scope, that are generally considered obsolete, outdated or insecure, and are no longer commonly used nowadays. Affected are the symmetric ciphers of the algorithms Blowfish, RC4, RC2, DES, CAST, IDEA, SEED, as well as the RC5 algorithm, which has so far only been compiled in on request, the hashing algorithms RIPEMD160, MD4, MD2, MDC2 and Whirlpool, as well as the key derivation function PBKDF1.

But in everyday life there are always situations in which these deprecated algorithms are still required, as can be seen in error messages like this one:

$ openssl enc -pbkdf2 -des-cbc -pass 'pass:test1234' </dev/null; echo
Error setting cipher DES-CBC
80020D0BB57F0000:error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:crypto/evp/evp_fetch.c:355:Global default library context, Algorithm (DES-CBC : 15), Properties ()
Salted__� 7�aM�

OpenSSL 3.0 Introduces Providers

However, the affected algorithms are not completely gone, in OpenSSL 3.0 and newer they have simply been moved from the default provider, which is active by default, to the new legacy provider.

The loaded and active providers can be inspected by openssl list --providers:

$ openssl list -providers
Providers:
  default
    name: OpenSSL Default Provider
    version: 3.2.1
    status: active

Some current software is aware of the provider concept introduced with OpenSSL 3.0 and provides options to enable the legacy provider right away. For example, Node.js allows the legacy provider to be activated since version 17 by issuing the --openssl-legacy-provider command line parameter, and also the OpenSSL subcommands which regularly come into contact with legacy algorithms also provide corresponding parameters with (e.g. openssl pkcs12 -legacy).

Unfortunately, most software that uses these outdated algorithms tends to be aged, too, or at least is poorly maintained. And so, such configuration options are rather rare especially in these cases.

System-Wide Activation of the Legacy Provider

If a software cannot be persuaded to use the legacy provider via parameter or configuration, and the possibility of code adjustment is somewhere in between overwhelming and not worth the effort, the only option left is to activate the legacy provider system-wide.
Of course the system administrator must be aware that this step may have a negative impact on system and data security, and further checks such as the ciphersuites for both incoming and outgoing TLS connections, which are often configured per application or service and therefore differ from the system's settings, are advisable.

Variant 1: Systems with crypto-policies

Among the Linux distributions, Fedora since version 21, RHEL and RHEL-based distributions since version 8, Ubuntu since version 20.04 LTS, Debian presently at least in sid/unstable, openSUSE Tumbleweed since 20201216, SLE and openSUSE Leap since version 15.4, and also many other distributions allow a system-wide configuration of the cryptography of all important system components using Fedora crypto-policies.

Originally, crypto-policies serves to reconfigure the system to one of the supplied or subsequently installed crypto policy profiles, a function that is particularly important for companies for the roll-out of a uniform company-wide configuration or implementation of regulatory requirements.
However, crypto-policies also allows custom configuration snippets to be merged with the selected policy profile, which is what we want to take advantage of here.

First, we write a new configuration snippet to merge with the OpenSSL configuration to /etc/crypto-policies/local.d/opensslcnf-enable_legacy_provider.config, and then run update-crypto-policies --set as root without specifying a policy profile (so the current profile is kept).

$ sudo cp /dev/stdin /etc/crypto-policies/local.d/opensslcnf-enable_legacy_provider.config <<__EOF
[provider_sect]
legacy = legacy_sect

[legacy_sect]
activate = 1
__EOF

$ sudo update-crypto-policies --set

Variant 2: Systems without crypto-policies

If configuration using crypto policies is not possible or not preferable, the OpenSSL configuration file openssl.cnf can be adapted directly.

On Linux systems, depending on the distribution, this file is usually located in either /etc/pki/tls/ or /etc/ssl/, on macOS it can be found in /System/Library/OpenSSL (and, if applicable, that of a MacPorts installation in /usr/local/etc/openssl/).
If in doubt, openssl version -a | grep ^OPENSSLDIR: should help to locate it.

On Windows systems, locating openssl.cnf is quite more complicated, as almost all applications package their own copy of OpenSSL.

In order to activate the legacy provider, the TOML section [provider_sect] has to be supplemented with the line legacy = legacy_sect, then create a new section [legacy_sect] and in this set activate = 1 .
The lines to be added here may already be included but commented-out, so that they can be activated simply by removing the leading # characters.

The relevant sections should now look something like this:

...
[provider_sect]
default = default_sect
legacy = legacy_sect

[default_sect]
activate = 1

[legacy_sect]
activate = 1
...

Verifying Success

Once the configuration has been completed, the legacy provider should be listed and marked as active, and the outdated algorithms should be available again:

$ openssl list -providers
Providers:
  default
    name: OpenSSL Default Provider
    version: 3.2.1
    status: active
  legacy
    name: OpenSSL Legacy Provider
    version: 3.2.1
    status: active

$ openssl enc -pbkdf2 -des-cbc -pass 'pass:test1234' </dev/null; echo
Salted__`%�h��s��c3�>Z�

All processes that were started with the old OpenSSL configuration must be restarted in order to adopt the new settings – so to be on the safe side, a reboot is recommended.