Support and test multiple TLS certificates per Gateway listener

[bowei]

What would you like to be added:

We should clarify the API Spec to clarify what happens when multiple TLS Certificates are specified on a Listener. For example, what happens when those certificates overlap or conflict? Once we clarify the spec, we'll also need a conformance test to verify the behavior.

Why this is needed:

Attaching multiple TLS certificates to a Gateway listener should have extended support.

[robscott]

This is one of the bullet points of #1104 (although that doesn't explicitly require multiple certs), adding a link from there as well.

[ksankeerth]

I’m interested in working on this conformance test. I went through the documentation. From my understanding, the conformance test for Gateway HTTPS listener references multiple TLS certificates should include the below aspects

1. The GatewayClass MUST use the longest matching SNI out of all available certificates for any TLS handshake.
2. The SNIs of all the certificates MUST match with the listener's hostname

Did I miss anything here? @robscott @bowei

[youngnick]

Sorry for the delay, @ksankeerth, that looks right to me.

[ksankeerth]

Thanks @youngnick. I'll send a PR to cover these tests. Let's get others' opinions after the PR

[ksankeerth]

Hi @youngnick,
I sent a PR with a conformance test. The test cases were written to check the longest SNI when multiple TLS certs are available. If possible, please review it.

[skriss]

My understanding was that multiple certificate refs per Listener was "custom" conformance, per:
https://github.com/kubernetes-sigs/gateway-api/blob/main/apis/v1beta1/gateway_types.go#L312-L314
https://github.com/kubernetes-sigs/gateway-api/blob/main/apis/v1beta1/gateway_types.go#L328-L330

Am I missing something here?

(Per @robscott's point in #1330 (comment), we do still need a test for a single TLS cert, though).

[rainest]

No, I think you're correct @skriss. It looks like the language is a bit confusing, where https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.Listener has

The GatewayClass MUST use the longest matching SNI out of all available certificates for any TLS handshake.
Support: Core

under the tls field, which I think meant to indicate that the tls field itself is core, and then also included some additional tips related to if. After, https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.GatewayTLSConfig, the type that goes in the tls field, indicates that multiple certificate support is expanded. The longest SNI bit should maybe reside in the GatewayTLSConfig docs instead of Listener, or the Listener doc should be amended to note that this only applies if you do implement the optional expanded feature (and presumably that should be "Gateway" instead of "GatewayClass").

The proposed change tests the longest SNI bit only (though I'm not sure there's anything more to test for multiple refs, and comments above seem to agree).

[ksankeerth]

@rainest Sorry for the confusion related to the proposed changes. I also looked at the same doc. The Longest Matching SNI was mentioned as support: core. The second proposed test seems unnecessary. As “Host Header” and “Hostname” should match, I thought the “SAN” or “CommonName” of certificates also match with “Hostname”. I think it’s not necessary for Support: core. Even in the PR, I didn’t include any tests for that. #1375

The proposed change tests the longest SNI bit only (though I'm not sure there's anything more to test for multiple refs, and comments above seem to agree).

[youngnick]

We discussed this one in a triage meeting, and although we have #1375 open, before we merge that one, we need another PR to move the multiple certs field to Extended support, and we can discuss there if we all agree (seems likely we do though).

@ksankeerth, any chance you are game to give that one a go?