IOS redirect returns 421 with wildcard certificate

[Mafmax]

Describe the bug
There are 2 services: foo.example.com and bar.example.com under wildcard certificate *.example.com and Gateway with TLS termination:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: gateway
spec:
gatewayClassName: nginx
listeners:

• name: http
  port: 80
  protocol: HTTP
  hostname: *.example.com
  allowedRoutes:
  namespaces:
  from: All
• name: https
  port: 443
  protocol: HTTPS
  hostname: *.example.com
  allowedRoutes:
  namespaces:
  from: All
  tls:
  mode: Terminate
  certificateRefs:
  • kind: Secret
    name: {{ .Values.tlsTerminationSecret }}

For each service created two HTTPRoute manifests. The first for redirect to https and the second for http connection to service:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: https
spec:
parentRefs:

• name: gateway
  sectionName: https
  hostnames:
• foo.example.com
  rules:
• backendRefs:
  • name: foo
    port: 80

---

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: http
spec:
parentRefs:

• name: gateway
  sectionName: http
  hostnames:
• foo.example.com
  rules:
• filters:
  • type: RequestRedirect
    requestRedirect:
    scheme: https
    port: 443

NginxGatewayFabric automatically adds the configuration block to server:

if ($ssl_server_name != $host) {
    return 421;
}

While redirect from foo.example.com to bar.example.com, IOS browser tries to reuse TLS connection with $host = bar.example.com but $server_name = foo.example.com and returns 421 Mismatch Redirect.

To Reproduce
Steps to reproduce the behavior:

1. Create gateway resource as shown above
2. Create HTTPRoutes as shown above

Expected behavior
Nginx Gateway Fabric allows to disable block
if ($ssl_server_name != $host) {
return 421;
}

Your environment

• Version of the NGINX Gateway Fabric - 1.5.1
• Version of Kubernetes - 1.30.10
• Kubernetes platform Bare Metal

[nginx-bot]

Hi @Mafmax! Welcome to the project! 🎉

Thanks for opening this issue!
Be sure to check out our Contributing Guidelines and the Issue Lifecycle while you wait for someone on the team to take a look at this.

[sjberman]

This is related to an issue that came about from the Gateway API community which is explained here in GEP-3567. I'll reach out to see what the behavioral expectation should be for your case.

[sjberman]

You might be able to workaround this by disabling HTTP/2. This can be done in the NginxProxy CRD resource, see this guide for how to configure that resource.

[sjberman]

We'll explore the option of having a switch to disable this check and see where we can fit it in our priority list.

Potential acceptance criteria for this ticket:

• add a new field (maybe allowTLSConnectionReuse; I think it would live in the NginxProxy configuration) that can be used to disable enforcement of matching Host header and certificate server name.
• document the risks of allowing this (per GEP-3567), potentially have a diagram to show the network flow and why this operates the way it does
• Set the OverlappingTLSConfig condition for situations where TLS configuration within a Listener conflicts with TLS configuration in another Listener on the same port