Introduction

A single Kubernetes Ingress can route several host names, and cert-manager can request Let's Encrypt certificates for them. The key idea is that the Ingress rules section controls HTTP routing, while the tls section declares which hosts should be covered by which TLS secret.

The Basic Pieces

To make this work cleanly, you usually need:

• an Ingress controller already running
• DNS records for each host pointing to that controller
• cert-manager installed
• an Issuer or ClusterIssuer configured for Let's Encrypt

Once those are in place, the multi-host setup is mostly standard Kubernetes YAML.

Create a Let's Encrypt Issuer

A common pattern is a cluster-wide issuer.

1apiVersion: cert-manager.io/v1
2kind: ClusterIssuer
3metadata:
4  name: letsencrypt-prod
5spec:
6  acme:
7    email: [email protected]
8    server: https://acme-v02.api.letsencrypt.org/directory
9    privateKeySecretRef:
10      name: letsencrypt-prod-account-key
11    solvers:
12      - http01:
13          ingress:
14            class: nginx

This tells cert-manager how to solve ACME challenges and where to store the account key.

One Ingress With Multiple Hosts

Now define an Ingress that serves multiple hosts and asks cert-manager for certificates.

1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: app-ingress
5  annotations:
6    cert-manager.io/cluster-issuer: letsencrypt-prod
7spec:
8  ingressClassName: nginx
9  tls:
10    - hosts:
11        - app.example.com
12        - api.example.com
13      secretName: shared-app-tls
14  rules:
15    - host: app.example.com
16      http:
17        paths:
18          - path: /
19            pathType: Prefix
20            backend:
21              service:
22                name: web-service
23                port:
24                  number: 80
25    - host: api.example.com
26      http:
27        paths:
28          - path: /
29            pathType: Prefix
30            backend:
31              service:
32                name: api-service
33                port:
34                  number: 8080

In this example, one certificate secret named shared-app-tls covers both hosts. cert-manager requests a certificate whose SAN list includes app.example.com and api.example.com.

One Secret Versus Multiple Secrets

You have two valid patterns:

• one TLS secret containing a certificate that covers several hosts
• separate TLS secrets, one per host or per host group

A shared certificate is simpler when the hosts belong together operationally. Separate secrets can be cleaner when ownership, renewal policy, or blast radius should be split.

For separate secrets, you would define multiple tls entries instead of one shared block.

DNS and Challenge Validation Matter

The YAML alone is not enough. Each host name in the Ingress must resolve to the ingress controller. If api.example.com does not point at the controller, Let's Encrypt validation will fail even if the Ingress manifest looks correct.

That is why multi-host certificate setup is usually broken by one of these, not by the rules syntax itself:

• missing DNS records
• wrong ingress class
• cert-manager not installed or not healthy
• ACME challenge path blocked by another rule or proxy layer

When to Use Multiple Ingress Objects

One multi-host Ingress is convenient when the hosts share the same lifecycle and controller. If the hosts belong to different teams, environments, or security boundaries, separate Ingress objects may be clearer even though one resource could technically hold all the rules.

So the question is not only "can one Ingress hold several hosts," but also "should these hosts be managed together."

Common Pitfalls

The most common mistake is defining multiple hosts in rules but forgetting to include all of them under tls.hosts, which leaves some hosts routed but not covered by the certificate.

Another mistake is assuming a valid Ingress manifest guarantees certificate issuance. DNS and ACME challenge reachability must also be correct.

A third pitfall is mixing up one shared certificate secret with one secret per host and then being surprised by the resulting certificate contents.

Summary

• A single Ingress can route multiple hosts.
• cert-manager uses the tls.hosts list and issuer annotation to request Let's Encrypt certificates.
• One TLS secret can cover several hosts, or you can split them into separate secrets.
• DNS for every host must point to the ingress controller or validation will fail.
• Choose one Ingress or multiple Ingresses based on ownership and operational clarity, not just on YAML convenience.