RHEL 8 & RHEL 9 System-Wide Cryptographic Policies


1. What is System-Wide Crypto Policy?

RHEL centralizes cryptographic settings through system-wide cryptographic policies. Instead of configuring every application individually, supported applications (OpenSSL, GnuTLS, OpenSSH, Java, Libreswan, NSS, etc.) inherit a common policy. Please review Official Redhat docs for more details.

Benefits:

  • Consistent security posture
  • Easier compliance
  • Centralized administration
  • Reduced configuration drift

Check the active policy:

update-crypto-policies --show

2. Policy Levels

PolicyPurposeTypical Use
LEGACYMaximum compatibilityOld environments only
DEFAULTRed Hat recommendedProduction default
FUTUREStronger algorithms onlySecurity-focused environments
FIPSFIPS validated algorithmsRegulated environments

Change policy:

sudo update-crypto-policies --set DEFAULT

Reboot is recommended because long-running services may continue using previously loaded cryptographic settings until restarted.


3. Subpolicies

Examples:

update-crypto-policies --set DEFAULT:SHA1
update-crypto-policies --set DEFAULT:NO-SHA1

Common use cases:

  • SHA1 – temporary compatibility with legacy systems.
  • NO-SHA1 – explicitly disables SHA-1.
  • AD-SUPPORT – interoperability with older Active Directory environments.
  • OSPP – Common Criteria related hardening (use only when required).

4. Verification

Verify active policy

update-crypto-policies --show
cat /etc/crypto-policies/config

Verify generated backends

ls -1 /etc/crypto-policies/back-ends/

Typical files:

  • openssl.config
  • gnutls.config
  • java.config
  • openssh.config
  • libreswan.config

5. OpenSSL Testing

List available ciphers:

openssl ciphers -v

Test TLS handshake:

openssl s_client -connect example.com:443

Force TLS version:

openssl s_client -connect example.com:443 -tls1_2

Force a specific cipher (useful when troubleshooting):

openssl s_client -connect example.com:443 -cipher AES128-SHA

Expected result:

  • Success if the client policy and server support the cipher.
  • "handshake failure" or "no shared cipher" if blocked by policy or unsupported.

6. Create a Local TLS Test Server

Generate a temporary certificate:

openssl req -x509 -newkey rsa:4096 -nodes \
-keyout server.key \
-out server.crt \
-days 365

Start a local server:

openssl s_server \
-key server.key \
-cert server.crt \
-accept 8443

Connect:

openssl s_client -connect localhost:8443

7. SSH Validation

List supported algorithms:

ssh -Q cipher
ssh -Q kex
ssh -Q mac
ssh -Q key

Debug a connection:

ssh -vvv user@server

Server configuration:

sshd -T

8. Nmap Validation

Enumerate TLS ciphers:

nmap --script ssl-enum-ciphers -p443 server.example.com

Inspect certificate:

nmap --script ssl-cert -p443 server.example.com

Inspect SSH algorithms:

nmap --script ssh2-enum-algos -p22 server.example.com

Compare results before and after changing the crypto policy.


9. Real Production Scenario

Problem

A legacy application stops connecting after upgrading to RHEL 9.

Checklist

update-crypto-policies --show
openssl s_client -connect server:443
journalctl -xe
ssh -vvv server
nmap --script ssl-enum-ciphers -p443 server

Possible Root Cause

  • Peer only supports SHA-1 signatures or deprecated algorithms.

Temporary Mitigation

sudo update-crypto-policies --set DEFAULT:SHA1

Permanent Fix

Upgrade the peer or replace the certificate so compatibility exceptions can be removed.


10. Bypassing the System Policy

Prefer application-specific exceptions over weakening the entire system.

Appropriate cases:

  • Legacy appliances
  • Older Java runtimes
  • Unsupported embedded devices
  • Temporary migration windows

Avoid switching the entire system to LEGACY unless there is a documented business requirement.


11. Troubleshooting Flow

Handshake Failure
      |
      v
update-crypto-policies --show
      |
      v
openssl s_client
      |
      v
nmap ssl-enum-ciphers
      |
      v
Identify unsupported cipher/signature
      |
      +--> Temporary compatibility (e.g. DEFAULT:SHA1)
      |
      +--> Permanent remediation (upgrade peer/certificate)

12. Best Practices

  • Keep DEFAULT unless a justified exception exists.
  • Use FUTURE only after compatibility testing.
  • Use FIPS only when compliance requires it.
  • Prefer application-level exceptions over global policy changes.
  • Document every temporary compatibility change and remove it after remediation.

References



Did this page help you?