TLS certificate lookup fails for server aliases unless specified host is loaded at least once

[migueloller]

NGINX Ingress controller version: v0.26.1

Kubernetes version (use kubectl version): v1.12.10-gke.17

Environment:

• Cloud provider or hardware configuration: GKE

What happened:
I defined an ingress resource with a server alias with a regular expression, using the nginx.ingress.kubernetes.io/server-alias, and a certificate with a wildcard host that matches the alias. When sending a request that matches the alias but not the primary host, the fake self-signed certificate is used. When sending a request that matches the primary host, the configured certificate is used. Interestingly enough, subsequent request to hosts that match the alias will then use the configured certificate. After having requested the main host and "fixing" the issue, I can get back to the erroneous state by re-applying the ingress resource.

What you expected to happen:

I expected to receive the configured certificate for the ingress, without having to request the main host.

How to reproduce it (as minimally and precisely as possible):

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: site
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/server-alias: '~.+.example.com'
spec:
  tls:
    - hosts:
        - primary.example.com
      secretName: star-example-com-tls
  rules:
    - host: primary.example.com
      http:
        paths:
          - path: /
            backend:
              serviceName: app
              servicePort: 80

Visit foo.example.com or any other subdomain for example.com and notice the self-signed cert is returned, then visit primary.example.com and notice the wildcard provided cert is returned, then go back to foo.example.com or any other subdomain for example.com and see that now the provided cert is being used.

Anything else we need to know:
I was able to get around this issue by using a wildcard in the hosts. Most conversations online mention that this is not supported by Kubernetes but it seems to be working without any issues, like this:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: site
  annotations:
    kubernetes.io/ingress.class: nginx
spec:
  tls:
    - hosts:
        - '*.example.com'
      secretName: star-example-com-tls
  rules:
    - host: '*.example.com'
      http:
        paths:
          - path: /
            backend:
              serviceName: app
              servicePort: 80

[migueloller]

Note that the workaround only works for wildcard subdomains and not for any arbitrary regex so it's not a workaround for every case.

[aledbf]

Most conversations online mention that this is not supported by Kubernetes but it seems to be working without any issues, like this:

This is correct but there is no validation in Kubernetes that avoids the use of * in the host field

nginx.ingress.kubernetes.io/server-alias: '~.+.example.com'

We should be clear about this in the docs. There is no support in ingress for the host field with regular expressions.

[migueloller]

@aledbf, thanks for the prompt response!

Interestingly enough, I realized Kubernetes does choose to allow * in the host field where it is a valid DNS wildcard. For example, I realized a regular expression like that wouldn't work (.e.g, ~.+-foo.example.com) when I tried to add a host with the value *-foo.example.com. Kubernetes declined it as an invalid wildcard DNS entry. Kubernetes will accept *.example.com, though. This will satisfy bar-foo.example.com and that is good enough for my current use case.

So with all that being said, as long as the NGINX ingress controller supports it, it looks like using valid DNS wildcards is the way to go, i.e., *.example.com for both the ingress rule's host as well as the ingress TLS host. Nicely enough this mimics the certificate's DNS name.

We should be clear about this in the docs. There is no support in ingress for the host field with regular expressions.

It would be great to add this clarification. Would you think it would also be helpful to point out the wildcard alternative?

[migueloller]

This is correct but there is no validation in Kubernetes that avoids the use of * in the host field

I have a feeling most people believe that a wildcard isn't supported because * is used in YAML to do alias indicators. This means that you can't just provide *.example.com for the host, it must be '*.example.com' so that the YAML parser passes it to Kubernetes properly.

As long as the ingress controller supports wildcard hosts, it's 100% ok to declare one in the ingress resource. And because NGINX supports wildcards in the server_name then it works as expected.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.