Description of problem: When the following parameters are passed into rabbit, the server fails to load the crypto libraries. RabbitAdditionalErlArgs: "'+sbwt none +sbwtdcpu none +sbwtdio none -crypto fips_mode true'" It looks like the erlang code tries to enable FIPS mode by make a call to openssl, which fails. Version-Release number of selected component (if applicable): How reproducible: 1. spun up a centos9 vm, enable fips reboot 2. enable erlang fips mode Actual results: Expected results: Additional info:
Based on conversation with John Eckersber
Based on conversation with John, current plan is: <eck> ade_lee: so here's my first formulation of a plan... <eck> system fips status is at /proc/sys/crypto/fips_enabled <eck> and then erlang basically has two main fips functions, (1) info_fips which returns one of not_supported | not_enabled | enabled (2) enable_fips_mode which returns either true or false to indicate success <eck> so we patch those and only base them on the system status <eck> so if /proc/sys/crypto/fips_enable = 0, then info_fips always returns not_supported and enable_fips_mode always returns false <eck> if 1, then info_fips always returns enabled and enable_fips_mode always returns true <eck> then we remove the parts of the erlang crypto code where it calls into openssl to manipulate it directly
(In reply to Ade Lee from comment #2) > Based on conversation with John, current plan is: > > <eck> ade_lee: so here's my first formulation of a plan... > <eck> system fips status is at /proc/sys/crypto/fips_enabled > <eck> and then erlang basically has two main fips functions, (1) info_fips > which returns one of not_supported | not_enabled | enabled (2) > enable_fips_mode which returns either true or false to indicate success > <eck> so we patch those and only base them on the system status > <eck> so if /proc/sys/crypto/fips_enable = 0, then info_fips always returns > not_supported and enable_fips_mode always returns false > <eck> if 1, then info_fips always returns enabled and enable_fips_mode > always returns true > <eck> then we remove the parts of the erlang crypto code where it calls into > openssl to manipulate it directly I misunderstood what the issue was originally, and this plan is not valid. The real issue is this commit: https://github.com/erlang/otp/commit/6bb9c51e900fe8fb5a88bd2498f6e5a92f94ed8d Which explicitly sets FIPS as not support with openssl 3.0. There is also this commit as well: https://github.com/erlang/otp/commit/f5b23150c3fe93631824641fdf3e50ca592c5088 Which explicitly warns that the openssl 3.0 support is not production-ready yet. It's not clear to me exactly what the issue is, but I will try to understand better why it is not considered production-ready yet.
erlang-24.3.4.2-2.el9osttrunk - https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=2091673 This reverts https://github.com/erlang/otp/commit/6bb9c51e900fe8fb5a88bd2498f6e5a92f94ed8d mentioned above.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Release of components for Red Hat OpenStack Platform 17.0 (Wallaby)), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2022:6543