20.2. Changes to cryptographic components

ca-certificates truststore moved

The /etc/pki/tls/certs truststore is converted to a different format better optimized for OpenSSL. As a consequence, if you use the files in /etc/pki/tls/certs directly, switch to the /etc/pki/ca-trust/extracted directory, where the same data is stored. For example, software that accesses the trust bundle at /etc/pki/tls/certs/ca-bundle.crt should switch to using /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem instead.

fips-mode-setup is removed

The fips-mode-setup command is removed from RHEL. To enable the cryptographic module self-checks mandated by the Federal Information Processing Standard (FIPS) 140, enable FIPS mode during the system installation. See the Switching RHEL to FIPS mode chapter in the Security hardening document for more information.

/etc/system-fips removed

Support for indicating FIPS mode through the /etc/system-fips file has been removed from RHEL. To install RHEL in FIPS mode, add the fips=1 parameter to the kernel command line during the system installation. You can check whether RHEL operates in FIPS mode by displaying the /proc/sys/crypto/fips_enabled file.

compat-openssl11 is removed

The compatibility library for OpenSSL 1.1, compat-openssl11, has been removed from RHEL 10. OpenSSL 1.1 is no longer maintained upstream and applications that use the OpenSSL TLS toolkit should be migrated to version 3.x.

pkcs11-provider replaces openssl-pkcs11

As a part of the migration from OpenSSL engines to the Providers API, the pkcs11-provider package replaces the openssl-pkcs11 package (engine_pkcs11). The openssl-pkcs11 package is removed from RHEL 10.

DEFAULT cryptographic policy rejects TLS ciphers with RSA key exchange

TLS ciphers that use the RSA key exchange are no longer accepted in the DEFAULT system-wide cryptographic policy in RHEL 10. These ciphers do not provide perfect forward secrecy and are not considered as secure as ciphers that use other key exchanges, for example, the Elliptic-curve Diffie-Hellman (ECDH) key exchange.

The LEGACY cryptographic policy disallows SHA-1 signatures in TLS

The LEGACY system-wide cryptographic policy in RHEL 10 no longer allows creating or verifying signatures that use SHA-1 in TLS contexts. Therefore, libraries other than OpenSSL might no longer accept or create any signatures that use SHA-1 regardless of use case. OpenSSL continues to accept signatures that use SHA-1 when not used for TLS if the system is in LEGACY or this functionality is re-enabled with a custom subpolicy.

SHA1 subpolicy removed

The SHA1 subpolicy that allowed to use the SHA-1 algorithm for creating and verifying signatures in the DEFAULT system-wide cryptographic policy after entering the update-crypto-policies --set DEFAULT:SHA1 command is no longer available in RHEL 10.

OpenSSL no longer permits SHA-1 at SECLEVEL=2 in TLS

OpenSSL does not accept the SHA-1 algorithm at SECLEVEL=2 in TLS in RHEL 10. If your scenario requires using TLS 1.0 or 1.1, you must explicitly set SECLEVEL=0 and switch to the LEGACY system-wide cryptographic policy. In the LEGACY policy, applications that use SHA-1 in signatures outside of TLS will continue to work.

OpenSSL cipher suites no longer enable cipher suites with disabled hashes or MACs

Previously, applying custom cryptographic policies could leave certain TLS 1.3 cipher suites enabled even if their hashes or MACs were disabled, because the OpenSSL TLS 1.3-specific Ciphersuites option values were controlled only by the ciphers option of the cryptographic policy. With this update, crypto-policies takes more algorithms into account when deciding whether to enable a cipher suite. As a result, OpenSSL on systems with custom cryptographic policies might refuse to negotiate some of the previously enabled TLS 1.3 cipher suites in better accordance with the system configuration.

OpenSSL FIPS indicators are subject to change during the RHEL 10 lifetime

Because RHEL introduced OpenSSL FIPS indicators before the OpenSSL upstream did, and both designs differ, the indicators may change in a future minor version of RHEL 10. After the potential adoption of the upstream API, the RHEL 10.0 indicators might return an error message "unsupported" instead of a result. See the OpenSSL FIPS Indicators GitHub document for details.

OpenSSL 3.5 uses standard format for ML-KEM and ML-DSA

In RHEL 10.0, the oqsprovider library used a pre-standard format for the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) and the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) private keys. With the rebase to OpenSSL 3.5, you must convert the ML-KEM and ML-DSA keys to the standard format by using the following command:

Switching to LEGACY policy does not enable support for SHA-1 in TLS connections

You can control support for SHA-1 signatures either by the @SECLEVEL setting specified in the default cipher string or the rh-allow-sha1-signatures property. Support for SHA-1 in the TLS context is enabled by setting @SECLEVEL=0. However, this setting also allows other insecure algorithms.

Stricter SSH host key permissions have been restored

The necessary host key permissions have been changed from the previous less strict value of 0640 to 0600, which is also the value used upstream. The ssh_keys group, which previously owned all SSH keys, has also been removed. Therefore, the ssh-keysign utility uses the SUID bit instead of the SGID bit.

crypto-policies now set allow-rsa-pkcs1-encrypt = false for GnuTLS

In RHEL 10, the GnuTLS library blocks encryption and decryption with the RSA PKCS #1 v1.5 padding by default. Except for the LEGACY policy, the allow-rsa-pkcs1-encrypt = false option is specified in all system-wide cryptographic policies (DEFAULT, FUTURE, and FIPS).