aldengolab/tailscale-k8s-ingress-https

Tailscale Kubernetes Ingress HTTPS

Problem

When creating a Tailscale Ingress with a tls: stanza, the proxy pod starts and tailscale serve status shows https:// — but HTTPS connections either return tlsv1 alert internal error (raw IP, no SNI) or time out (correct hostname). The TLS secret is not created automatically on first deploy.

Context / Trigger Conditions

• Tailscale operator (v1.56+) with ingressClassName: tailscale available
• Kubernetes Ingress created with ingressClassName: tailscale and tls: stanza
• HTTPS is enabled in Tailscale admin console (DNS → Enable HTTPS)
• tailscale serve status shows https://<hostname>.ts.net (tailnet only)
• TLS secret specified in Ingress does not exist in the namespace
• Raw IP port 443: tlsv1 alert internal error; hostname port 443: timeout

Solution

1. Create the Ingress (replacing a LoadBalancer Service)

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: <service>
  namespace: <namespace>
  annotations:
    tailscale.com/hostname: <short-hostname>
spec:
  ingressClassName: tailscale
  defaultBackend:
    service:
      name: <existing-clusterip-service>
      port:
        number: 80
  tls:
    - hosts:
        - <short-hostname>      # just the short name, not the full FQDN
      secretName: <service>-tls

The backend stays plain HTTP — the Tailscale proxy terminates TLS.

2. Trigger initial cert provisioning

After the proxy pod (ts-<service>-<hash>-0) starts, exec in and run tailscale cert once:

# Find proxy pod
kubectl get pods -n tailscale | grep <service>

# Provision cert (use full FQDN)
kubectl exec -n tailscale <proxy-pod> -- \
  tailscale cert <hostname>.<tailnet>.ts.net

# Expected output:
# Wrote public cert to <hostname>.<tailnet>.ts.net.crt
# Wrote private key to <hostname>.<tailnet>.ts.net.key

HTTPS works immediately after this — no restart needed.

3. Verify

kubectl exec -n tailscale <proxy-pod> -- tailscale serve status
# https://<hostname>.ts.net (tailnet only)
# |-- / proxy http://<clusterip>:<port>/

curl -sI https://<hostname>.<tailnet>.ts.net
# HTTP/2 200

Verification

• curl -sI https://... returns HTTP/2 200
• TLS cert subject matches the hostname and is issued by Tailscale's CA
• Old LoadBalancer Service is removed (pruned by ArgoCD if prune:true)
• DNS resolves to new proxy pod IP (auto-propagates, typically < 1 min)

Notes

• (tailnet only) is expected — the service is only accessible to tailnet peers, not via public Funnel. Correct for internal services.
• DNS propagation: When replacing a LoadBalancer Service, MagicDNS may briefly resolve to the old device IP. Clears automatically once the old device is removed.
• Diagnostic pattern: No-SNI → fast tlsv1 alert internal error means the server is alive but no cert. Correct-SNI → timeout means the server is alive but waiting on cert provisioning. Both point to the same root cause.
• Cert auto-renewal: The proxy handles renewal automatically after initial provisioning. The tailscale cert exec is a one-time bootstrap only.
• Backend does not use TLS: Do not enable TLS on the backend (e.g., Harbor's expose.tls.enabled: false stays). The Tailscale proxy is the TLS terminator.

References

• https://tailscale.com/kb/1185/kubernetes — Tailscale Kubernetes operator docs
• https://tailscale.com/kb/1153/enabling-https — Enabling HTTPS certificates