System-wide cryptographic policies in RHEL

Updated -

Red Hat Insights can detect this issue

Proactively detect and remediate issues impacting your systems.
View matching systems and remediation

NOTE: For detailed and up-to-date information about crypto-policies see the following product documentation:

The software ecosystems today, whether open or closed source, are characterized by diversity. The database applications typically come from a different team than the one developed the HTTP or SSH services, and so on. Each team chooses their own libraries, languages, utilities and cryptographic providers for their solution. That diversity gives an immense strength due to focused application-specific communities and teams but it often makes it challenging to enforce a consistent cryptographic policy on a system. Security researchers from several universities and organizations have put together the ‘Applied Crypto Hardening’ guide, a 110-page guide of theory and instructions to configure a system with vetted cryptographic settings. They go through web server applications (apache, nginx), OpenSSH server, TLS use in mail servers, etc. It is a massive, commendable effort of making sense of our security software ecosystem.

What this effort additionally unveils, is that a heterogeneous environment requires significant effort to correctly configure, and also that deep cryptographic knowledge is often required to sensibly configure new components in such a system. At the same time, what is described in today’s best practices guides will be considered insecure settings at some future date, further unveiling the hidden cost of the need to keep the system’s configuration up-to-date. Today, that cost is carried by IT departments, which irrespective of the automation or configuration management, have to ensure that the cryptographic configuration on all of their supported services is reasonable and follows the industry’s standard practices as defined by the respective body (e.g., PCI-DSS, DISA, STIG, NIST).

Can we assume such an expertise among users or IT departments? Not lightly. On the contrary, we believe that assuming that the people setting up software or systems are experts on their field but not on details over cryptographic algorithms, will result to safer systems. Nevertheless, it is imperative that systems are operating under the right cryptographic settings, to reduce risk from existing and future attacks. Furthermore, we need settings that do not harm interoperability, while at the same time are conservative, conform to widely accepted standards, and eliminate legacy protocols and algorithms which are likely to become a liability.

In short, we have a configuration problem which we cannot assume the end-user or IT departments are responsible to address. Before going further on describing our solution, let’s present the risks of such misconfiguration in a more specific way.

How substantial is the risk of an inconsistent or outdated cryptographic policy?

As software gets continuously enhanced with new features, legacy features often remain enabled, creating a continuously expanding attack surface. There are multiple reasons for that, but the main is that in order to provide backwards compatibility, the application configuration is often the primary mechanism for reducing an application’s attack surface. That configuration is available to the end-user or system administrator. In practice, as previously mentioned, delegating such decisions to the end-users or system administrator is not very effective. Even when the required skill set is available for such a task, going to each and every application to customize its configuration based on recent cryptographic advances is a Sisyphean one, and in practice it is often a neglected task.

Subsequently, that lack of attention, increases the risk of an adversary taking advantage of an expanded attack surface. In fact, we have recently seen impactful attacks like POODLE (2014), FREAK (2015) or DROWN (2016) which took advantage of deprecated protocols and options, e.g., SSL2.0 and SSL3.0, some to attack unrelated sessions on the same server which seemingly used a modern and secure protocol. Their impact, although hard to evaluate precisely, was a blow on the perceived trustworthiness of modern systems, and served as an alarm towards the need for up-to-date and consistent cryptographic policy in system services.

How does Red Hat Enterprise Linux provides a consistent cryptographic policy?

The good news is that, if you use RHEL 8 or newer, you can prevent these attacks using the system-wide cryptographic policies. This set of policies is applied consistently to running services and is kept up-to-date as part of the software updates, to stay on par with cryptographic advances.

Additionally, the selected as default policy is a conservative policy, which eliminates a whole class of threats by disabling legacy communications protocols such as TLS 1.1 and earlier versions. At the same time, we provide the option to adjust settings to local requirements, e.g., make the selected policy stricter, or more lax, for compatibility with older systems, or meeting payment industry’s requirements such as PCI-DSS (see also cryptographic policy customization).

What do the existing cryptographic policies cover?

Crypto-policies is a component in Red Hat Enterprise Linux which configures the core cryptographic subsystems, covering TLS, IPSec, DNSSec, and Kerberos protocols; i.e., our supported secure communications protocols on the base operating system. It provides a small set of policies which the administrator can select, with the default being a conservative policy offering secure settings for today’s threat models. Once an application runs in RHEL it will follow the default or selected policy and refuse to fall back to refuse to fall back to algorithms and protocols not within the policy, unless the user has explicitly requested the application to do so. That is, the policy applies to the default behavior of applications when running with the system-provided configuration, but can be overridden by the user if required so on an application-specific basis.


Which are the provided policies?

Four policies are provided under the names “LEGACY”, “DEFAULT”, “FUTURE” and “FIPS”. The detailed settings available on each policy are summarized in this linked article and the update-crypto-policies manual page.

How do you use cryptographic policies?

The system’s policy can be set and queried with the update-crypto-policies application, as demonstrated below. We will use the update-crypto-policies tool to switch the running system from the default policy, to the more strict FUTURE one. A more detailed summary of the tool’s options can be found in the update-crypto-policies manual page.

$ update-crypto-policies --show

# update-crypto-policies --set FUTURE
Setting system policy to FUTURE

Any services or applications started after this policy change will switch to the new policies.

Example with client applications

The example above switches the system to a mode where the still widespread used SHA-1 is disallowed. The following examples show the outcome of an attempt to connect to a server which contains a certificate signed with SHA-1, while the system is in the FUTURE mode which prohibits that algorithm.

# update-crypto-policies --set FUTURE
# yum install -y wget curl

$ wget
--2018-10-12 05:27:40--
Resolving (
Connecting to (||:443... connected.
ERROR: The certificate of ‘’ is not trusted.
ERROR: The certificate of ‘’ was signed using an insecure algorithm.

$ curl
curl: (60) SSL certificate problem: EE certificate key too weak
More details here:

Example with server applications

On the examples above both applications refused to connect to that server. Let’s now see how would this affect servers running on RHEL 8. On the following example we will set up an Apache Web server and try to connect to it using the gnutls-cli TLS debug tool. Initially the connection will be using the default settings with TLS 1.3 being the advertised version, and then we will instruct the tool to switch to the TLS 1.1 protocol which is not allowed by the server’s DEFAULT policy.

# update-crypto-policies --set DEFAULT
# yum module install -y httpd
# yum install -y gnutls-utils
# systemctl start httpd

$ gnutls-cli localhost --insecure </dev/null
- Description: (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
- Ephemeral EC Diffie-Hellman parameters
 - Using curve: SECP256R1
 - Curve size: 256 bits
- Version: TLS1.3
- Server Signature: RSA-PSS-RSAE-SHA256
- Cipher: AES-256-GCM
- Options:
- Handshake was completed

The initial connection attempt was a success. Let’s now try connecting with TLS 1.1 being the only version advertised by the client.

$ gnutls-cli localhost --insecure --priority "NORMAL:-VERS-ALL:+VERS-TLS1.1" </dev/null
*** Fatal error: A TLS fatal alert has been received.
*** Received alert [70]: Error in protocol version
*** handshake has failed: A TLS fatal alert has been received.

Hence we see that a client which is restricted to an option forbidden by the server’s DEFAULT policy is notified via a TLS alert message, and the connection is closed.


With the examples above, we can see that both client and server applications respect the system-wide cryptographic policies, and that not only increases the security bar of default installations in Red Hat Enterprise Linux systems, but more importantly offloads the administrator from the task of figuring the right settings for cryptographic algorithms and protocols.


"At the same time, we provide the option to adjust settings to local requirements..."

How about an example? This took way longer to figure out than it should have done:

cp /usr/share/crypto-policies/policies/NO-SHA1.pmod /etc/crypto-policies/policies/modules/PCI-DSS.pmod
cat >> /etc/crypto-policies/policies/modules/PCI-DSS.pmod << EOF
mac = -HMAC-SHA1
ssh_cipher = -AES-256-CBC -AES-128-CBC
update-crypto-policies --set DEFAULT:PCI-DSS

Thanks for the comment. This article predated the customization so the adjustment referred to the ability to switch between the predefined levels. As we have the customization now it makes sense as you mention to refer to it. I've updated the text to refer to the right article explaining it.

Nikos, Thank you for updating the KB. I now understand that "Blog" in the Customer Portal search is not the same thing as "the Red Hat Blog". Will the CP search be integrated with the new blog? Or could the linked blog post be turned into a KB article?

thank you John - this exactly. Took me a while to find such an example about removing some specific HMAC items, and I finally found this comment of yours. Cheers! (any customisation links Nikos could be improved with the inclusion of links to detailed documentation, not an overview or blog post. There should be a man page detailing how to construct a pmod in all its glory.)

How do I disable one specific kex algorithm, like diffie-hellman-group-exchange-sha1 ?

And why are you using yum commands ?

Hello Daniel,

The RHEL 8 Security hardening title contains the "Customizing system-wide cryptographic policies with policy modifiers" section [1] that should answer your first question.

On RHEL, we still use the YUM package management tool and the "yum" command [2]. You can type "dnf ..." to perform the same tasks.



The crypto-policy documentation does not help.

Specifically, how do I disable diffie-hellman-group-exchange-sha1 ?

I would like to know the solution too. It would be really helpful if a full list of crypto policy properties is available.

This solution works. The explanation could be clearer. See my comments in this article.

It is unclear why one would choose to bypass the crypto policies rather than modify them.

Thanks for the reply.

I hope that it can be done under crypto policies. As the policies are applied system-wide, it would be nice to define the rules centrally that can be applied not only for ssh, but also for other services such as web server.

It would be wonderful if a list of all crypto policy properties is available.

Instead of disabling the diffie-hellman-group-exchange-sha1, I disabled the SHA1 hashing entirely. What I did was to add the following line to the policy modifier module: hash = -SHA1

After I ran the update-crypto-policies command, diffie-hellman-group-exchange-sha1 was disabled. The down side is that other algorithms using SHA1 are disabled too. Luckily I don't need SHA1 in my case.

This "new" system wide crypto policy stuff needs a lot more documentation detail.

I was looking for a fix to a Nessus finding:

Plugin 153953: SSH Weak Key Exchange Algorithms Enabled

Plugin Output: 
The following weak key exchange algorithms are enabled : 

The remote SSH server is configured to allow weak key exchange algorithms.

The remote SSH server is configured to allow key exchange algorithms which are considered weak.

This is based on the IETF draft document Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH) draft-ietf-curdle-ssh-kex-sha2-20. Section 4 lists guidance on key exchange algorithms that SHOULD NOT and MUST NOT be enabled. This includes:

Note that this plugin only checks for the options of the SSH server, and it does not check for vulnerable software versions.

Contact the vendor or consult product documentation to disable the weak algorithms.

Everything listed the following link helped me resolve everything except: diffie-hellman-group-exchange-sha1

Turns out diffie-hellman-group-exchange-sha1 is located on the client side... And after running ssh -vvv to locate the problem, it turns out the line in /etc/ssh/ssh_config has the following that needs to be commented out:

Include /etc/ssh/ssh_config.d/*.conf

/etc/ssh/ssh_config.d/05-redhat.conf contains another rabbit hole: Include /etc/crypto-policies/back-ends/openssh.config

Which of course if you look there you will see diffie-hellman-group-exchange-sha1...

Hope that helps