kubernetes: Ingress does not support several TLS certificates

Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see http://kubernetes.io/docs/troubleshooting/.): no.

What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): ingress tls.

Is this a BUG REPORT or FEATURE REQUEST? (choose one): FEATURE REQUEST

Kubernetes version (use kubectl version): 1.4

Environment:

Cloud provider or hardware configuration: GKE
OS (e.g. from /etc/os-release):
Kernel (e.g. uname -a):
Install tools:
Others:

What happened: Currently Ingress resources can only have one TLS certificate configured:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test
spec:
  tls:
    - secretName: testsecret
  rules:
  - host: foo.bar.com
    http:
      paths:
      - backend:
          serviceName: s1
          servicePort: 80
  - host: bar.foo.com
    http:
      paths:
      - backend:
          serviceName: s2
          servicePort: 80

What you expected to happen: Would it make sense to have a TLS certificate per route rule. Something like this:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test
spec:
  rules:
  - host: foo.bar.com
    tls:
      - secretName: testsecret
    http:
      paths:
      - backend:
          serviceName: s1
          servicePort: 80
  - host: bar.foo.com
    tls:
      - secretName: testsecret
    http:
      paths:
      - backend:
          serviceName: s2
          servicePort: 80

I am not aware of the design decisions behind the current implementation so this might not make sense at all. The reason I propose this is because I see Ingress’es as public IP addresses. You might want to have several public IPs pointing to your cluster but also only one IP and then have several hosts point to that IP.

Initially submitted at https://github.com/kubernetes/contrib/issues/2058, but per request of @aledbf, submitting here.

About this issue

Original URL
State: closed
Created 8 years ago
Reactions: 2
Comments: 23 (8 by maintainers)

Most upvoted comments

Multiple TLS certs are now working for me as of k8s ver. 1.10.2-gke.1 in GCP! It works by adding multiple hosts in the tls section like in my previous example.

+11

pkdetlefsen on May 30, 2018

Is this something that might get supported eventually? It would be a big plus to be able to put all your services, hosted on different domains using multiple certificates, behind a single Google Cloud Load Balancer using an Ingress.

Currently I can work around the issue by managing the additional certs manually, as it looks like the GCLB does support multiple certs and SNI. For now I will probably move towards using a SAN cert for most of the domains to avoid managing them manually, but that’s not possible for all of them in my case unfortunately.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    kubernetes.io/ingress.class: "gce"
spec:
  tls:
  - hosts: # First cert are managed automatically
    - my.domain.com
    - domain.com
    secretName: domain-tls
  - hosts: # Additional certs have to be added manually to the load balancer
    - other-domain.com
    secretName: other-domain-tls
  rules: ...
  backend: ...

pkdetlefsen on Jan 5, 2018

@ged15 can you reopen this ticket? This is still an issue

miquelbar on Jul 28, 2017

@ianatha GCE ingress added multiple cert support in 1.1.0, that will be shipped in kubernetes 1.11.

anderspetersson on May 1, 2018

/remove-lifecycle stale

pkdetlefsen on Jan 5, 2018

Cloudproviders don’t really support muxing multiple certs onto a single lb, so your current options are:

Create 2 ingresses with 2 certs (works everywhere)
Create 1 ingress with a wildcard or san (works everywhere)
Create 1 ingress with a list of certs with different hostnames, one per host (depends on backend implementation, cloud provider will simply pick the first cert and assume it’s a san throwing a warning event)

In theory a backend can parse the hostnames out of the list of certs and use the right one with the right Host header.

We don’t put the cert in with the HTTP rules because encryption is handled at Layer 5. So:

We’d need to repeat the same structs in a bunch of places for non-http protocols (dtls, just tcp + ssl etc)
Keeping the certs in a separate section also makes centralized validation and renewal easier, i.e I can write a letsencrypt controller that doesn’t even care about the rules

Non-http ingress is being discussed here: https://github.com/kubernetes/kubernetes/issues/23291 More explicity ingress sharing is being discussed here: https://github.com/kubernetes/kubernetes/issues/30151

bprashanth on Nov 26, 2016