Uploaded image for project: 'OpenShift Service Mesh'
  1. OpenShift Service Mesh
  2. OSSM-5979

Fix TestTrustDomainValidation from security/ca_custom_root

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Blocker Blocker
    • None
    • None
    • Customer Impact, Maistra
    • None
    • False
    • None
    • False

      Ted's comment:

      I was trying to understand where the actual text being checked for ("tls: unknown certificate" / "tls: handshake failure") had come from, because I don't recognise it as something that we had to accommodate or change in the envoy test code, nor something that I can see anywhere in the Envoy or OpenSSL source code.

      Is that text possibly being generated by some test code, from an SSL alert code sent on the wire by envoy? If so, that makes more sense.
      In 2.4 all certificate processing was delegated to OpenSSL, so it will have been OpenSSL producing the certificate_unknown(46) alert.

      However, in 2.5 we took upstream envoy's custom certificate processing callback code. In many ways, this is good because our certificate selection process now matches upstream. However, one downside to using this callback is the fact that it can only return either success or failure result back to OpenSSL. In the case where the callback returns a failure result, OpenSSL then fails the handshake with the handshake_failure(40) alert that you are seeing.

      The test was adjusted to OpenSSL error: https://github.com/maistra/istio/blob/maistra-2.5/tests/integration/security/ca_custom_root/trust_domain_validation_test.go#L154.

            jewertow@redhat.com Jacek Ewertowski
            jewertow@redhat.com Jacek Ewertowski
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: