Strong crypto defaults in RHEL 8 and deprecation of weak crypto algorithms

You can do something like

- name: get current crypto policy
   shell: update-crypto-policies --show
   register: current_crypto_policy
   changed_when: false

- name: set crypto policy
  shell: "update-crypto-policies --set {{ crypto_policy }}"
  when: current_crypto_policy.stdout != crypto_policy

By the way, did anyone noticed that the system wide crypto policy seem to overwrite a specific service configuration? I tried to disable sha1 based alogrithms in the ssh configuration by defining the Ciphers, MACs and KexAlgorithms specifically in the ssh config, but the ssh daemon still uses the default set defined by the system wide crypto policies.

Why is RedHat actively discouraging the use of the FUTURE crypto policy? FUTURE policy description: The policy is not supposed to be used for general purpose systems.

But how is it then possible that a CIS hardening standard 'dictates' that for Red Hat either FIPS or FUTURE must be used and at the same time Red Hat as a vendor interper FUTURE policy for not suitable for production usage? I may see a valid performance reason i.r.t. strong cryptographics for embedded systems with very low CPU power, but is this actually a real issue for general purpose servers? Is it really a valid point to disencourage SHA-256 over insecure SHA-1 and 3072 bits RSA keys over 2048 bit keys, for the reason of handling these cryptographic schemas will lower overall system performance? The current problem is that consultants of Red Hat refer to this technote as 'not suitable for production', while at the same time the customer is bound to strict regulatory, like the requirement for CIS hardening.

I think Red Hat must not write "not supposed to be used for general purpose" but should write something like "When using FUTURE policy be aware of some performance impact in certain scenarios and be aware of the impact on client systems as well." FUTURE policy is a non-default, so the fact that one chooses to implement the FUTURE policy is already a conscious choice, so one already has considered switching towards this policy. Implementing security hardening in companies is always difficult, because people need to adapt, and adaptation is one of the hardest tasks for companies (and most people). Therefor, writing "not supposed to be used" is definitely not really helping in such adaptation

In my humble opinion, current update-crypto-policies is ugly! (Sorry)

Let's say I have two ansible roles and two additional modules for crypto-policy. One is already in the default modules (for example AD-SUPPORT), the second is specific to our organization, configures the ssh daemon, and residues in separated file. Each role set one of these modules for absolutely different purposes and in absolutely different times. One role is for IdM, second is for ssh hardening. Should I say what problem I will facing? I can.

1. The sequence of roles and the combination of two (or more) modules with the current policy in one end policy of the server. But we only have --show and --set. We must to conjure.
2. Idempotency. No one of these settings is idempotent.
3. If we change the module file itself, the policy must be reloaded. That is, we need again to conjure with the --show and the --set.
4. If we have changed the policy, but we are not allowed to restart the server, we still have to restart the services.

This is my current example ansible block for working with crypto-policies:

- name: Get current policy
  command: 'update-crypto-policies --show' #command!!! long live bashsible!
  register: curcrypto
  changed_when: False
- name: Non skip if unsetted policy
  debug:
    msg: '{{curcrypto.stdout}}'
  when: polname not in curcrypto.stdout
  changed_when: True
  notify: sshd restart
- name: Set policy list
  set_fact:
    pollist: '{{curcrypto.stdout}}{%if polname not in curcrypto.stdout %}:{{polname}}{%endif%}'
- name: Policy copy
  copy:
    src: '{{polname}}.pmod'
    dest: /etc/crypto-policies/policies/modules/
    owner: root
    group: root
    mode: '0640'
  notify: sshd restart
- name: Set policy
  command: 'update-crypto-policies --set {{pollist}}' #bashsible again
  changed_when: False

and similar blocks must be inserted into any role that works with crypto-policies. I don't know how to make it easier.

This all is quite close to being very inconvenient to use. It seems to me, that it would be much better if the update-crypto-policy would not be so oaky as if out of the last century. For example, update-crypto-policy could have options --reload and --add. And --add may be idempotent. Itself. Without my dances.

Also, the need to restart the Unix server looks very funny. In the 21st century. Even Microsoft has already learned not to reboot its operating system for any reason. But we are going the other way. Let's reboot the consolidated database server...

Well, the internal content of policy modules is, of course, a separate story. Absolutely different designations in the module and regulated services with the absence of fine-tuning of algorithms in some cases - this, of course, is very convenient, thank you! And all OS operators must also be specialists in crypto systems, of course. Apparently this should be added to the rhcsa course! Because at present, even the Red Hat' technical support cannot adequately help when opening a case.

Having the above details in a table/matrix would be helpful.