Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RequireServerNameIndication flag not set on multi-site listeners (hostname/TLS) #426

robertprather opened this issue Jul 26, 2019 · 5 comments


Copy link

@robertprather robertprather commented Jul 26, 2019

Describe the bug
We are using Application Gateway (v1) Medium WAF SKU, AKS and Ingress Controller v0.7.1 deployed via helm chart.

We recently upgraded to use the multiple watched namespaces feature each namespaced deployment using k8s ingress definition according to the docs "Expose services over HTTPS" -> "With specified hostname".

When ingress controller updates the gateway, all looks OK - multi-site host listeners configured as expected with the correct TLS certificate.

When browsing to one of the sites by hostname I am routed via the wrong listener. Looking at the resource definition, RequireServerNameIndication = false on my multi-site listener and it should be true

(I believe this is because gateway processes requests to multi-site (hostname) listeners in an order I can't determine.)

To Reproduce
Steps to reproduce the behavior:
Configure Ingress controller to watch multiple namespaces (eg. watchNamespace: ).
Deploy pods to multiple namespaces using Ingress defintions with TLS/hostname (e.g. hostname1/cert1, hostname2/cert2).
After gateway update,

  • attempt to access one of the sites in a browser (e.g. hostname1) - site loads correctly.
  • attempt to access the other site in a browser (e.g. hostname2) - site loads incorrectly and presents incorrect cert from other site (e.g. expected cert2, received cert1).

This is not a useful workaround but does point to the root cause of the issue.
After the ingress controller has updated the gateway, use Azure CLI to update all https listeners as below.

az network application-gateway http-listener update -g RG --gateway-name AGW -n fl-hostname1-443 --set RequireServerNameIndication=true --force-string
az network application-gateway http-listener update -g RG --gateway-name AGW -n fl-hostname2-443 --set RequireServerNameIndication=true --force-string

Doing so resolves the issue and gateway routes correctly by SNI. This workaround is not compatible with ingress controller as the next update to the gateway reverts the requireServerNameIndication flag to false.

Ingress Controller details

  • Output of kubectl describe pod <ingress controller> . The pod name can be obtained by running helm list.
Name:               ingress-azure-xxxxx-aaa
Namespace:          default
Priority:           0
PriorityClassName:  <none>
Node:               aks-agentpool1-xxxxxx-0/
Start Time:         Thu, 25 Jul 2019 16:27:44 +1000
Labels:             aadpodidbinding=ingress-azure
Annotations:        <none>
Status:             Running
Controlled By:      ReplicaSet/ingress-azure-xxxxx
    Container ID:   docker://978b785fa628e7d0e19d24ef536a10c04d63c59f29f7a4adc7d0008cfb89e4eb
    Image ID:       docker-pullable://
    Port:           <none>
    Host Port:      <none>
    State:          Running
      Started:      Fri, 26 Jul 2019 08:03:54 +1000
    Last State:     Terminated
      Reason:       Error
      Exit Code:    255
      Started:      Thu, 25 Jul 2019 16:27:54 +1000
      Finished:     Fri, 26 Jul 2019 08:03:07 +1000
    Ready:          True
    Restart Count:  1
    Environment Variables from:
      ingress-azure  ConfigMap  Optional: false
    Environment:     <none>
      /var/run/secrets/ from ingress-azure-token-v95rp (ro)
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
    Type:        Secret (a volume populated by a Secret)
    SecretName:  ingress-azure-token-v95rp
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations: for 300s
        for 300s
Events:          <none>
  • Ingress definition - namespace 1
Name:             app-ingress1
Namespace:        ns1
Default backend:  default-http-backend:80 (<none>)
  app-hostname1-tls terminates hostname1
  Host                   Path  Backends
  ----                   ----  --------
hostname1        app:8080 (<none>)
Annotations:  true           true                        azure/application-gateway
Events:                                               <none>
  • Ingress definition - namespace 2
Name:             app-ingress1
Namespace:        ns2
Default backend:  default-http-backend:80 (<none>)
  app-hostname2-tls terminates hostname2
  Host                   Path  Backends
  ----                   ----  --------
hostname2        app:8080 (<none>)
Annotations:           true                        azure/application-gateway
Events:                                               <none>
  • Output of `kubectl logs .
  • Any Azure support tickets associated with this issue.
Copy link

@robertprather robertprather commented Aug 15, 2019

This small bug is a frustrating blocker for us, any comments from the team @akshaysngupta ?
Will you review a PR for it as I'd be keen to see this in...

Copy link

@krottiers krottiers commented Aug 20, 2019

@akshaysngupta I have a customer facing the same issue. Is there a timeline on a fix?

robertprather pushed a commit to robertprather/application-gateway-kubernetes-ingress that referenced this issue Sep 5, 2019
Copy link

@akshaysngupta akshaysngupta commented Feb 23, 2020

This was fixed in 0.9.0.
Note: AGIC doesn't support AppGW v1 SKU after version 0.9.0.

Copy link

@joelharkes joelharkes commented Mar 4, 2020

having this problem in v1?

Copy link

@joelharkes joelharkes commented Mar 4, 2020

somehow worked.
but than when i had a second not sub domain: it would always take ssl certificate of

adding a second host to ingress definition fixed it though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

No branches or pull requests

4 participants