Introduction

For Kubernetes ingress TLS, you do not usually configure the intermediate certificate as a separate field in the Ingress resource. Instead, you build the correct certificate chain in the TLS secret, with the leaf certificate first and the intermediate certificate or certificates appended after it.

Core Sections

Build the full chain correctly

Most ingress controllers expect the certificate file in the secret to contain the full chain in this order:

1. server or leaf certificate
2. intermediate certificate one
3. additional intermediates if required

Do not put the private key into that file, and do not usually include the root certificate unless your issuer explicitly requires it.

A common command is:

cat tls.crt intermediate.crt > fullchain.crt

If there are multiple intermediates, append them in the proper order from the leaf upward.

Create the Kubernetes TLS secret

Use the full chain as the certificate input when creating the secret.

kubectl create secret tls my-tls-secret \
  --cert=fullchain.crt \
  --key=tls.key

That secret is what the Ingress references.

Reference the secret from the Ingress

1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: app-ingress
5spec:
6  tls:
7    - hosts:
8        - example.com
9      secretName: my-tls-secret
10  rules:
11    - host: example.com
12      http:
13        paths:
14          - path: /
15            pathType: Prefix
16            backend:
17              service:
18                name: app-service
19                port:
20                  number: 80

The Ingress itself points only to the secret. The chain lives inside the secret data.

Verify what the client actually receives

If browsers or clients still report an incomplete chain, inspect the served certificate from outside the cluster.

This check matters because many TLS problems are not visible from the Kubernetes YAML alone. A secret can exist and the Ingress can reference it correctly, but the served chain can still be incomplete if the bundled certificate data was assembled incorrectly.

openssl s_client -connect example.com:443 -servername example.com -showcerts

This lets you confirm whether the ingress controller is presenting the leaf plus intermediates as expected.

Controller-specific behavior still matters

The general rule above works for common controllers such as ingress-nginx, but some controllers or managed platforms have their own certificate-loading behavior. Even then, the full-chain secret pattern is still the normal baseline.

If you are terminating TLS somewhere before the ingress controller, such as at a cloud load balancer, make sure you are fixing the right termination point. Sometimes the Kubernetes secret is correct and the missing chain is actually at the external load balancer layer.

Renewals and automation

If certificates are managed by cert-manager or another automation tool, you usually should not hand-edit secrets. Instead, make sure the issuer produces the correct chain and that the controller writes the final secret in the expected format.

Manual fixes to generated secrets are often overwritten on the next renewal.

Common Pitfalls

• Trying to configure the intermediate certificate as a separate Ingress field instead of bundling it into the TLS secret certificate chain.
• Building the chain in the wrong order so clients receive an invalid or incomplete certificate chain.
• Including only the leaf certificate in the secret and assuming clients will discover the intermediate automatically.
• Debugging the Ingress YAML when TLS is actually terminated earlier by a cloud load balancer or another proxy layer.
• Manually editing secrets that are managed by automation such as cert-manager and then being surprised when the changes disappear.

Summary

• Put the intermediate certificate into the TLS secret by appending it to the leaf certificate in a full-chain file.
• Reference that TLS secret normally from the Ingress resource.
• The common order is leaf certificate first, then intermediate certificates.
• Verify the served chain externally with openssl s_client.
• If certificates are automated, fix the issuer or automation source rather than patching generated secrets by hand.