6 tests failing with Error Message: 'Certificate is untrusted' when compiling on RHEL 9 #4541
Comments
|
Thanks for the issue! That is a very interesting set of failures. I don't think we test on any RHEL in our CI 🤔 not sure how we would add that. |
|
While not the exact AMI you're using, we've had success with unit tests on AL2023, which is similar to FC34/35, with Openssl 3.0.x. I was unable to repro this error on FC35, using the steps provided. One thing that might help is changing your build target to |
The issue only occurs on RHEL 9, so I'm not exactly sure why you refer to F34/F35 in this context? Because F34 was the base for CentOS 9 Stream which is the base for RHEL 9? I'm no expert in the s2n-tls code base but also saw the case statement you mentioned (https://github.com/aws/s2n-tls/blob/main/tls/s2n_x509_validator.c#L721). My first thought was, if the tests run against the system wide trusted certs, maybe the tests certs are signed by ca that's not trusted anymore or use a hash that's unsupported in current RHEL 9 releases. Or because of compliance requirements openssl is compiled with different flags, therefore more strict as on other OS versions and fails. I can test the changed build flag and report the results back. |
|
I did a build with I had another idea but it's also not the problem or at least not the part of Reflecting on the fact that Red Hat has set SHA1 on path to deprecation and started with it in RHEL 9: In Fedora the patch to disable SHA1 in the openssl package still allows SHA1 by default: But in CentOS 9 Stream and therefore RHEL 9 the patch is changed to disable SHA1 by default: This patch leaves To test my theory I removed the feature by applying this patch: But this didn't change anything, the same tests failing and claiming the cert is untrusted: So maybe it is related to the |
|
Using the build type RelwithDebInfo will build s2n-tls with debug symbols. This allows you to use gdb with s2n-tls and pause the tests in a specific location. In particular, it would be interesting to see what the actual value of The note about SHA1 in RHEL 9 is intriguing. However, the feature flag you mentioned isn't actually used to turn on/off SHA1 support, which is why removing it does nothing. |
|
Your guess about the issue being a SHA1 signature algorithm is a good one. The failing tests use a certificate which uses sha1WithRSAEncryption as its signature algorithm. This diff changes the s2n_config_test to use a certificate with a sha256 signature algorithm instead of one with the sha1 signature algorithm. If it passes on RHEL 9, then that further supports the theory that its a sha1 problem. |
Thanks @maddeleine, I applied the patch and did a new build. So I would say we getting closer and it seems indeed relation to the Still failing: Details |
|
To resolve this it might make sense for us to just update the default certificate chain to one that doesn't use SHA1. |
Problem:
I try to compile
s2n-tlson different Fedora and Red Hat Enterprise Linux versions with shared libraries against OpenSSL.On RHEL 9, six tests failing with the Error Message:
Certificate is untrustedAll tests passing on RHEL 8, Fedora 39, Fedora 40 and Fedora Rawhide (x86_64, aarch64).
The result / error is identical when I drop build option
-DBUILD_SHARED_LIBS=ON.I'm looking for guidance how to further troubleshoot and solve the issue.
Steps to reproduce on a fresh RHEL 9.3 instance with AMI
RHEL-9.3.0_HVM-20240117-x86_64-49-Hourly2-GP3:Additional packages installed:
cmake,gcc,git,openssl-develVersions:
cmake-3.26.5,gcc-11.4.1,openssl-3.0.7Build steps:
Relevant logs of failing tests with stacktrace output enabled.
The text was updated successfully, but these errors were encountered: