How do you terminate TLS for a hostname at a Kubernetes Ingress, and what exactly must the referenced Secret contain?

## The Ingress side ```yaml spec: tls: - hosts: ["shop.example.com"] secretName: shop-tls ``` `spec.tls` is a list, and each entry pairs a set of hostnames with one Secret. Its only job is telling the controller which certificate to present for which SNI name; it does not create routing. Routing still comes from `spec.rules`, and a host must appear in the rules to be served at all. Conversely, a host listed only in `rules` and not in `tls` is served over plain HTTP. Most controllers add an automatic HTTP→HTTPS redirect for hosts covered by `tls`, but that is controller behaviour (and usually annotation-tunable), not something the Ingress spec mandates. ## The Secret The Secret must be `type: kubernetes.io/tls`. That type is enforced by the API server to contain exactly two data keys: - `tls.crt` — PEM certificate data. - `tls.key` — the PEM private key, unencrypted (no passphrase; controllers do not prompt). Two details cause most production incidents: **1. Chain order and completeness.** `tls.crt` should hold the leaf certificate first, followed by any intermediate CA certificates, in order. The root is not needed and is normally omitted. If you ship only the leaf, some clients still succeed — browsers often cache intermediates or fetch them via AIA — while curl, Java clients and mobile apps fail with "unable to get local issuer certificate". That asymmetry is exactly why the bug reaches production: the developer's browser test passes. Verify with `openssl s_client -connect host:443 -servername host` and count the certificates in the returned chain. **2. Namespace locality.** The Secret must be in the same namespace as the Ingress. There is no cross-namespace reference mechanism for Ingress TLS, so a shared wildcard certificate must be copied (or synced by a tool) into every namespace that needs it. This is a genuine operational wart and one of the things the Gateway API's ReferenceGrant addresses. Create one directly with `kubectl create secret tls`, which takes the cert and key files and sets the type and keys correctly. ## SNI and multiple certificates One Ingress may carry several `tls` entries, and multiple Ingress objects served by the same controller each bring their own. At handshake time the client sends the hostname in the TLS SNI extension and the controller picks the matching certificate. If nothing matches, controllers serve a **default certificate** — often a self-signed "fake certificate". Seeing that self-signed cert in a browser is a strong signal that SNI matched nothing: the host is missing from `spec.tls`, the Secret is absent or misnamed, the Secret is in the wrong namespace, or the certificate's SAN does not cover the requested name. Note that hostnames matter twice, and independently: in `spec.tls[].hosts` for certificate selection, and in the certificate's own Subject Alternative Name list. A wildcard certificate for `*.example.com` covers `shop.example.com` but not `example.com` itself and not `a.b.example.com`. Common Name is ignored by modern clients — only SANs count. ## Rotation Controllers watch the Secret, so updating its contents reprograms the data plane within seconds without restarting anything. cert-manager relies on this: it obtains and renews certificates (ACME/Let's Encrypt or an internal CA) and writes them back into the same `kubernetes.io/tls` Secret. With the `cert-manager.io/cluster-issuer` annotation on an Ingress, cert-manager can create the Secret from the `spec.tls` entry automatically, including solving the ACME HTTP-01 challenge through the very Ingress being configured. A caveat worth stating in an interview: renewal writes the Secret, but if your controller caches aggressively or the Secret name changes, you can serve a stale certificate. Monitor actual expiry **as observed on the wire** at the edge, not just the Secret's contents. ## Passthrough and mTLS Some deployments must not terminate TLS at the edge — the backend needs the original session, for example for client-certificate authentication end to end. The Ingress spec has no field for that; controllers expose it via annotations such as NGINX's `ssl-passthrough`, which operates on SNI at the TCP level and bypasses HTTP routing entirely, so path rules stop applying for that host. Client-certificate (mTLS) verification at the edge is likewise annotation-driven and controller-specific. Both are reminders that Ingress standardises only basic termination; anything richer is outside the spec. ## Debug order Check the Secret exists in the Ingress's namespace with the right type and keys; check `spec.tls[].hosts` contains the hostname; check the certificate SAN covers it; check chain completeness with `openssl s_client`; check controller events and logs for a load failure. In that order, most TLS incidents resolve in a few minutes.