The System Crypto Policy, Proven To Govern The Handshake

crypto-policy

One switch that every library on the host obeys. EL's crypto policies decide what OpenSSL, GnuTLS, NSS, OpenSSH, Java and Kerberos will negotiate, from one setting. The role sets it, refuses to believe it without reading it back, and proves the new policy reached a running daemon rather than only a file. The live test runs one handshake three times - under the configured policy, under FUTURE, and under the configured policy again - so the refusal in the middle is demonstrably the policy's doing and not the server's.

No download, and no version to pin. The crypto policies and their scripts are part of EL 10. What the role owns is which policy the host runs, and the proof that the host is really running it.

There is no file for this role to write. The policy is a system-wide switch, and setting it regenerates every back-end under /etc/crypto-policies/back-ends. So the role reads the current policy, sets it only when it differs, and reads it back - and the live test asserts the generated openssl back-end really carries the floor the policy implies.

The live test starts this host on the wrong policy on purpose. A role whose whole effect is one conditional task converges with changed=0 against a machine that already matches it, and a verify run after that reads the distribution's defaults while appearing to confirm the role. The lane refuses a first converge that changed nothing, and tests/pre-converge.yml answers the refusal by putting the host on LEGACY first. What the receipt certifies is therefore a policy this role moved, not a policy it agreed with.

A running process keeps the policy it read at start, and EL restarts exactly three of them. update-crypto-policies --set runs /usr/share/crypto-policies/reload-cmds.sh, which issues try-reload-or-restart for bind and try-restart for ipsec and sshd, skipping any of the three that is not already running. Nothing else is touched: httpd, postfix, dovecot, a JVM, a database and anything of your own go on negotiating under the policy they read when they started, while --show reports the new one. That is the gap crypto_policy_restart_services exists to close, and it is empty by default because sshd - the one everybody thinks of - is already covered.

Measured, because the tool's own note ("it is recommended to restart the system") suggests it does nothing of the kind: a plain --set moved sshd's activation forward by 9 seconds, --no-reload --set moved it by 0, and a plain --set again by 6. crypto_policy_reload_services: false is that flag, for a host where sshd dropping its sessions is your decision to schedule rather than a side effect of a policy change.

The live test asserts the new policy reached a running daemon: sshd is installed and started before the converge, and its activation must be no earlier than the moment the policy file was written. A name in the restart list that systemd does not know fails the run - it used to be swallowed, which meant the role could report success having reached no running process at all.

Two of the obvious hardening choices stop dnf working on Rocky 10. Both FUTURE and DEFAULT:OSPP raise OpenSSL's security level to 3, and the repository mirrors present RSA-2048 certificates that a level-3 client refuses, so package installs fail with Curl error (60) ... EE certificate key too weak. This role's own live test failed on exactly that before the default was changed. Measured on Rocky Linux 10 in this role's lane, one policy per row:

policy	dnf makecache	a TLS 1.2 peer
DEFAULT	works	accepted
DEFAULT:NO-PQ	works	accepted
DEFAULT:ECDHE-ONLY	works	refused, handshake failure
DEFAULT:OSPP	fails	accepted
FUTURE	fails	refused, protocol version

The dnf column is a fact about the certificates this host's repositories serve, not about the policy alone: a mirror with a 3072-bit key would be reachable under either. Check your own repositories, internal ones included, before choosing a level-3 policy - and note that --set succeeds in every row above, so nothing warns you at the moment you make the change.

DEFAULT:NO-SHA1 does not work on EL 10. It is the line every RHEL 9 hardening guide gives, and NO-SHA1.pmod is not shipped here: the command exits non-zero with Unknown policy, and the previous policy stays in force. The subpolicies Rocky 10 does ship are AD-SUPPORT, AD-SUPPORT-LEGACY, ECDHE-ONLY, NO-ENFORCE-EMS, NO-PQ, OSPP and TEST-PQ. The live test asserts that refusal, so if a later release adds the module this role goes red rather than going stale.

Setting the FIPS policy is not FIPS mode. update-crypto-policies --set FIPS selects the algorithm set; a host in FIPS mode needs fips-mode-setup --enable and a reboot, which this role does not do and does not claim.

License

Commercial - IaC Bazaar EULA. (c) IaC Bazaar.