The conformance test HTTPRouteHTTPSListener is currently failing because the controller unconditionally forces mutual TLS (mTLS) on all HTTPS listeners, requiring client certificates even when not specified in the Gateway resource. This conflicts with the test expectation, which asserts standard HTTPS behavior without client certificates.
Root Cause
In the translator function - buildDownstreamTLSContext contains a hardcoded setting to require client certificates
However, the test makes requests to the Gateway without providing a client certificate.
As a result, Envoy rejects the connection during the TLS handshake
A Potential Solution: Conditional mTLS Enforcement
Instead of forcing mTLS on all listeners, the controller could enforce it conditionally:
Explicit mTLS: The user explicitly configures CACertificateRefs in the Gateway resource. The controller enables mTLS.
Implied mTLS for Feature Support: The user binds an XAccessPolicy that relies on SPIFFE identities to the Gateway. The controller detects this and automatically enables mTLS on the associated listeners to support the policy, even if CACertificateRefs was not explicitly set in the Gateway resource.
Standard HTTPS: If neither an explicit CA reference is provided, nor an XAccessPolicy requiring SPIFFE is bound to the Gateway, the controller falls back to standard HTTPS (no client certificate required).
Another Solution
Skip the test due to our project specific security requirements.
The conformance test HTTPRouteHTTPSListener is currently failing because the controller unconditionally forces mutual TLS (mTLS) on all HTTPS listeners, requiring client certificates even when not specified in the Gateway resource. This conflicts with the test expectation, which asserts standard HTTPS behavior without client certificates.
Root Cause
In the translator function - buildDownstreamTLSContext contains a hardcoded setting to require client certificates
However, the test makes requests to the Gateway without providing a client certificate.
As a result, Envoy rejects the connection during the TLS handshake
A Potential Solution: Conditional mTLS Enforcement
Instead of forcing mTLS on all listeners, the controller could enforce it conditionally:
Explicit mTLS: The user explicitly configures CACertificateRefs in the Gateway resource. The controller enables mTLS.
Implied mTLS for Feature Support: The user binds an XAccessPolicy that relies on SPIFFE identities to the Gateway. The controller detects this and automatically enables mTLS on the associated listeners to support the policy, even if CACertificateRefs was not explicitly set in the Gateway resource.
Standard HTTPS: If neither an explicit CA reference is provided, nor an XAccessPolicy requiring SPIFFE is bound to the Gateway, the controller falls back to standard HTTPS (no client certificate required).
Another Solution
Skip the test due to our project specific security requirements.