Changes to cryptographic components

Review the most notable changes to cryptographic components between RHEL 9 and RHEL 10.

NO-HMAC-SHA1 disables SHA-1 for HMAC operations

Starting from RHEL 10.3, the crypto-policies package introduces the NO-HMAC-SHA1 subpolicy. Security scanners frequently flag SHA-1 use as a compliance issue, although SHA-1 collision vulnerabilities do not affect hash-based message authentication code (HMAC) security.

As a result, you can apply the NO-HMAC-SHA1 subpolicy to disable SHA-1 for HMAC operations and satisfy compliance scanner requirements.

crypto-policies no longer forces post-quantum cryptography for rpm-sequoia

Before RHEL 10.3, post-quantum cryptography (PQC) support for the rpm-sequoia package was hard-coded to remain enabled, regardless of the active system cryptographic policy. This workaround prevented verification failures on dual-signed RPM packages when PQC was disabled in the policy.

Starting from RHEL 10.3, the crypto-policies component removes the hard-coded override. As a result, rpm-sequoia respects the active system cryptographic policy as configured.

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.

This change also reduces the exposure to side-channel attacks because the RSA key exchange uses PKCS #1 v1.5 encryption padding, which can cause vulnerability to timing side-channel attacks.

If you need the RSA key exchange for interoperability with legacy systems, you can re-enable it by using the LEGACY system-wide cryptographic policy or by applying a custom subpolicy.

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 startup certificate self-check removed
The RHEL 10.3 update changes how OpenSSL validates certificates. The internal check of a service's own certificate chain at startup is no longer performed, as it is the peer's responsibility to verify the chain during the handshake. Ensure that peer systems, clients or servers, are correctly configured to perform standard certificate chain validation to maintain security.
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:

# openssl pkcs8 -in <old_private_key> -nocrypt -topk8 -out <standard_private_key>

Replace <old_private_key> with the path to the non-standard private key, and <standard_private_key> with the path where the standard key will be saved.

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.

You can override the SECLEVEL setting by specifying the rh-allow-sha1-signatures property in the evp_properties section. By default and when unspecified in the configuration file, evp_properties is set to no. The system-wide cryptographic policies set the property to yes after you switch to the LEGACY policy.

Therefore, to enable support for SHA-1 in contexts outside TLS, you can switch the system to the LEGACY cryptographic policy. To enable SHA-1 in TLS, you must switch the system to LEGACY and use a cipher string that sets @SECLEVEL=0 either by defining a custom cryptographic policy or setting this for your application in OpenSSL.

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).
Non-post-quantum KEX removed from the FUTURE policy

The FUTURE system-wide cryptographic policy no longer allows traditional, non-post-quantum, key exchange (KEX) methods. With this update, you can use only hybrid Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) key exchange algorithms.

This aligns with the target use of the FUTURE policy in controlled, isolated deployments and significantly impacts interoperability with the public internet. For example, when you switch RHEL 10 to the FUTURE policy, you cannot connect to the cdn.redhat.com network. Also, Java clients cannot connect to TLS servers running in FUTURE.

Note that upcoming RHEL releases might further restrict signature algorithms in certificates and signatures to allow only post-quantum cryptography (PQC) in the FUTURE policy.

libssh supports hybrid key exchange with ML-KEM and crypto-policies enable mlkem768x25519-sha256 by default

Starting from RHEL 10.2, the libssh library introduces support for post-quantum traditional (PQ/T) hybrid key exchange methods based on the quantum-resistant Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) standard and traditional Elliptic-curve Diffie–Hellman (ECDH) key exchange schemes. The mlkem768x25519-sha256 algorithm is the preferred key exchange method for SSH connections unless you change the configuration.

Also, the system-wide cryptographic policies enable the mlkem768x25519-sha256 key exchange algorithms for the libssh library in all predefined policies. As a result, mlkem768x25519-sha256 is enabled by default and negotiated with the highest priority, protecting SSH connections with a combination of traditional and post-quantum cryptography (PQC).