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.

4.16

100%    

    1. Create a Ingress Controller with spec.defaultCertificate or a Route with spec.tls.certificate as a SHA1 cert
    2. Roll out the router   

    Router fails to start

    Router should start

    We've previously documented via story in RHEL9 epic: https://issues.redhat.com/browse/NE-1449