Allow certificate SAN and listener hostname to be different

[yaelSchechter]

Description:
We would like to use a certificate that does not match the listener and HTTPRoute's hostnames.
Currently, this is not supported in Envoy Gateway, where the domain specified in the certificate’s dnsNames field is different from the SNI domain sent by the client (configured on the Gateway). This setup fails validation here:
https://github.com/envoyproxy/gateway/blame/ec94c9848d88d430624396f70ac6a0e8124d3420/internal/gatewayapi/tls.go#L90
This pattern is common in CDN use cases, where the CDN accepts certificates that are issued with the origin-server's "technical" domain name, while the client-facing host-header and SNI are being preserved.
For example, Akamai supports matching the certificate's CN/SAN to the origin-server name:

Akamai Documentation:

Match CN/SAN To
Specify the values ​Akamai​ edge servers should look for in your origin certificate's Common Name (CN) or Subject Alternate Name (SAN) fields. When a Subject Alternate Name field is present in the certificate, the Common Name field is ignored. These values are included by default:
{{Origin Hostname}}: The edge server scans either a CN or SAN for the value you've set as the Origin Server Hostname .
{{Forward Host Header}}: The edge server scans either a CN or SAN for the value you've set as the Forward Host Header.

[guydc]

This is true for other CDNs as well:

Cloudflare:

Your origin needs to be able to support an SSL certificate that is [...] Contains a Common Name (CN) or Subject Alternative Name (SAN) that matches the requested or target hostname.

Cloudfront:

The certificate returned from the origin must include one of the following domain names:

• The domain name in the origin’s Origin domain [...]

Azure CDN

For HTTPS connections, Azure Front Door expects that your origin presents a certificate from a valid certificate authority (CA) with a subject name matching the origin hostname.

According to the envoy certificate selection docs, this should be possible.

There are some nuances that have to do with "candidate certs" that match OCSP policy but are RSA while the client is ECDSA capable, but that is not the use case described here. In general, if there is no exact or wildcard match, the first certificate is selected.

If the client supports SNI, e.g. SNI is “test.example.com”, it looks for a cert that exactly matches to the SNI
[...]
If the client supports SNI, but no cert is selected from certs that exactly matches to SNI, it matches on wildcard server name.
[...]
If no cert is selected from certs that matches wildcard name [...] pick the first certificate for handshake.

[guydc]

Community meeting notes:
Try to solve this together with #5730 as proposed in this comment: #5730 (comment)

[jacobneiltaylor]

From my duplicate issue:

Description:
Currently, Envoy Gateway requires that certificates used as part of a Gateway declaration MUST match a listener's hostname. This is enforced in the validation routines of the transformer.

While this is a very reasonable default assumption, in some niche use cases this is a tad too restrictive.

In our use case, we want to provide the option for customers to use Cloudflare in front of our Gateway.
Cloudflare supports unique validation logic, in that it will accept origin certificates with either the Cloudflare fronted name or the origin name. However, it will always use the Cloudflare fronted name as the value for TLS SNI and the authority pseudoheader. It is easier in our environment for us to acquire a trusted certificate with the origin name than acquire a certificate with the CDN name.

I propose we add support for adding an Envoy Gateway-specific flag to the GatewayTLSConfig options structure that will allow us to flag we want to loosen the validation logic for a certificate.

I will attempt to open a PR implementing this behaviour, but I'd appreciate feedback on the idea in general and preferred naming/values for such a flag.

Relevant Links:

Envoy Gateway validation logic
Gateway API options structure

[arkodg]

hey @jacobneiltaylor sorry for the delay in reviewing your PR

we discussed this issue again in today's community meeting
thanks @guydc for digging through the RFC
there's no text in the RFC https://datatracker.ietf.org/doc/html/rfc6066#page-6 or in Gateway API spec https://gateway-api.sigs.k8s.io/reference/spec/#gatewayspec thats says SNI MUST/SHOULD match SAN

so we can avoid adding an API for this, and just comment out/remove the function from the validation function for now

I've added this to v1.5.0 milestone, since its a low risk change, If you have a cycle feel free to make this change else I can as well