-
Bug
-
Resolution: Done-Errata
-
Major
-
4.16
Description of problem:
Due to RHEL9 incorporating OpenSSL 3.0, HaProxy will refuse to start if provided with a cert using SHA1-based signature algorithm. RHEL9 is being introduced in 4.16. This means customers updating from 4.15 to 4.16 with a SHA1 cert will find their router in a failure state. My Notes from experimenting with various ways of using a cert in ingress: - Routes with SHA1 spec.tls.certificate WILL prevent HaProxy from reloading/starting - It is NOT limited to FIPs, I broke a non-FIPs cluster with this - Routes with SHA1 spec.tls.caCertificate will NOT prevent HaProxy starting, but route is rejected, due to extended route validation failure: - lastTransitionTime: "2024-01-04T20:18:01Z" message: 'spec.tls.certificate: Invalid value: "redacted certificate data": error verifying certificate: x509: certificate signed by unknown authority (possibly because of "x509: cannot verify signature: insecure algorithm SHA1-RSA (temporarily override with GODEBUG=x509sha1=1)" while trying to verify candidate authority certificate "www.exampleca.com")' - Routes with SHA1 spec.tls.destinationCACertificate will NOT prevent HaProxy from starting. It actually seems to work as expected - IngressController with SHA1 spec.defaultCertificate WILL prevent HaProxy from starting. - IngressController with SHA1 spec.clientTLS.clientCA will NOT prevent HaProxy from starting.
Version-Release number of selected component (if applicable):
4.16
How reproducible:
100%
Steps to Reproduce:
1. Create a Ingress Controller with spec.defaultCertificate or a Route with spec.tls.certificate as a SHA1 cert 2. Roll out the router
Actual results:
Router fails to start
Expected results:
Router should start
Additional info:
We've previously documented via story in RHEL9 epic: https://issues.redhat.com/browse/NE-1449 The initial fix for this issue was merged as [https://github.com/openshift/router/pull/555]. This issue is currently causing some issues, notably causing the openshift/cluster-ingress-operator repository's {{TestRouteAdmissionPolicy}} E2E test to fail intermittently, which causes the e2e-azure, e2e-gcp-operator, and e2e-aws-operator CI jobs to fail intermittently. Note: In the solution, we only intend to reject **routes** with SHA1 cert on spec.tls.certificate. Ingress Controller with SHA1 cert on spec.defaultCertificate will NOT be rejected.
- blocks
-
NE-1441 Bump openshift-router image to RHEL9
- Closed
-
OCPBUGS-28928 [Backport 4.15] Router fails to start/reload with SHA1 cert due to OpenSSL 3.0 in RHEL9
- Closed
-
OCPBUGS-1689 Modifying a namespace or route label to opt-out of a router shard doesn't update the route admitted status
- Closed
- duplicates
-
NE-1449 Set upgradeable=false in 4.15 if router cert is SHA1
- Closed
- is caused by
-
NE-1441 Bump openshift-router image to RHEL9
- Closed
- is cloned by
-
OCPBUGS-28928 [Backport 4.15] Router fails to start/reload with SHA1 cert due to OpenSSL 3.0 in RHEL9
- Closed
- is related to
-
OCPBUGS-45290 Routes with SHA1 CA certificate break HAProxy reloading
- POST
-
OCPBUGS-42480 Upgrade to 4.16 is blocked because root certificate has weak SHA1 signature algorithm
- Closed
- relates to
-
NE-1477 Update CI origin test to use SHA256 certificates
- Closed
- links to
-
RHEA-2024:0041 OpenShift Container Platform 4.16.z bug fix update