Uploaded image for project: 'OpenShift Bugs'
  1. OpenShift Bugs
  2. OCPBUGS-28928

Router fails to start/reload with SHA1 cert due to OpenSSL 3.0 in RHEL9

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • 4.16
    • Networking / router
    • Moderate
    • No
    • Rejected
    • False
    • Hide

      None

      Show
      None
    • Hide
      *Cause*: The next OpenShift version (4.16) does not support SHA1 certificates on routes.
      *Consequence*: Upgrades from 4.15 to 4.16 will cause routes with SHA1 certificates to be rejected.
      *Fix*: This fix adds a new UnservableInFutureVersions status condition to routes that contain a SHA1 cert. Additionally, it adds an admin-gate to block upgrades if this new status is present on any route.
      *Result*: If cluster admins have routes using SHA1 certificates in version 4.15, they must either upgrade these certificates to a supported algorithm or provide an admin-ack for the created admin-gate. This admin-ack allows them to proceed with the upgrade without resolving the SHA1 certificate issues, though the routes will be rejected.
      Show
      *Cause*: The next OpenShift version (4.16) does not support SHA1 certificates on routes. *Consequence*: Upgrades from 4.15 to 4.16 will cause routes with SHA1 certificates to be rejected. *Fix*: This fix adds a new UnservableInFutureVersions status condition to routes that contain a SHA1 cert. Additionally, it adds an admin-gate to block upgrades if this new status is present on any route. *Result*: If cluster admins have routes using SHA1 certificates in version 4.15, they must either upgrade these certificates to a supported algorithm or provide an admin-ack for the created admin-gate. This admin-ack allows them to proceed with the upgrade without resolving the SHA1 certificate issues, though the routes will be rejected.
    • Enhancement
    • In Progress

      Backport for 4.15 - Manually Cloned from https://issues.redhat.com/browse/OCPBUGS-26498 

      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

            gspence@redhat.com Grant Spence
            gspence@redhat.com Grant Spence
            Shudi Li Shudi Li
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: