I applied the FUTURE policy because I’d like to take advantage of stronger crypto. However now, unfortunately, I can update, since dnf seems to rely on curl and curl does not like weak crypto.
Dependencies resolved.
================================================================================
Package Architecture Version Repository Size
================================================================================
Installing:
unbound x86_64 1.16.2-2.el9 appstream 962 k
Installing dependencies:
unbound-libs x86_64 1.16.2-2.el9 appstream 547 k
Transaction Summary
================================================================================
Install 2 Packages
Total download size: 1.5 M
Installed size: 4.8 M
Is this ok [y/N]: y
Downloading Packages:
[ === ] --- B/s | 0 B --:-- ETA
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Error downloading packages:
Curl error (60): SSL peer certificate or SSH remote key was not OK for https://mirrors.rockylinux.org/mirrorlist?arch=x86_64&repo=AppStream-9 [SSL certificate problem: EE certificate key too weak]
What is the proper way to fix this issue without just reverting to the DEFAULT policy with weaker crypto?
Well, there is no proper way without knowing, what you want to accomplishing. As the policy name implies, FUTURE means that not all peers are prepared for such requirements. The DEFAULT policy is already curated. You can define yourself a policy or relaxing the FUTURE or restricting the DEFAULT policy.
Since dnf automatically queries mirrors.rockylinux.org I expect it to work regardless of which policy I use and have an up to date certificate supporting modern standards. This is not some random peer I try to connect to afterall, but the default and central place the OS receives updates from. A quick search suggest that there is no direct way in Rocky to even select specific mirrors which might support the standard, this is why I am asking here.
Your suggestion to just use the weaker security standard sounds like this bad advice I often here to just deactivate SELinux. It is there for a reason and I’d like to use it.
Well, I invited you to understand the implications of your doing. Saying that something is weaker shows your misconception. Think about it, that would mean that this or upstream distribution are shipped with a weak default configuration. Security is always a balance between usability and information safety, and that is delegated by your requirements, but do not expected that the world around you, are already on such level (FUTURE policy), because that does not addresses (peers) formulated need, the requirements are already addressed by the secure “DEFAULT” policy for example (mirrors.r.o has already a Class A config) . This might change in the future, and you can test this already now. Please also read the content of the resources you yourself have provided above. BTW, nobody suggested a weaker standard, please read my last sentence above carefully.
The difficulty in evaluating this at any point in time is the standard against which it’s judged. I doubt that the web service which hosts the signed packages will resist future analysis of the captured traffic by the A.I.-controlled quantum decryptor, however for now at least one or two of the mirrors gets an A from SSl Labs, which is good for a general web service which handles sensitive traffic.
The operators of the mirrors could do the work to score higher on such tests with bigger and/or better keys, limiting signature algorithms to stronger ones, creating CAA records, etc. while still remaining compatible with all intended clients. Whether or not this represents a good investment is a judgement call for the project, especially since the data being served does not rely on the transport for integrity and is all public [Citation needed].
Given how easy I think the job would be, I’m in favour of someone else doing the work.