I'm configuring a Cilium Gateway API route for Argo CD and want HTTPS both from the client to the gateway and from the gateway to the Argo CD server. TLS passthrough works, but terminating TLS at the gateway and enabling backend TLS results in a browser error: `307 NS_ERROR_REDIRECT_LOOP`.
The Gateway listens on HTTPS and terminates TLS using `argocd-gateway-tls`. The HTTPRoute points to the `argocd-server` Service on port 443, and I attempted to configure a BackendTLSPolicy using a ConfigMap containing the Argo CD server certificate as the CA. The load balancer, BGP announcements, Gateway status, and routes all appear healthy.
However, the BackendTLSPolicy has no status or events. Could the gateway be sending plain HTTP to Argo CD after terminating the external TLS connection? What is the correct way to configure backend TLS, and what should I check regarding Argo CD's `server.insecure` setting, certificate hostname, Gateway API version, and Cilium support?
3 Answers
For end-to-end TLS, make sure a real `BackendTLSPolicy` resource is being created and attached to the `argocd-server` Service. It needs `targetRefs` for the Service and a `validation` section containing the CA ConfigMap plus the backend certificate hostname. The hostname must match a SAN on the certificate Argo CD presents.
For example, the policy should be structured roughly like this:
`apiVersion: gateway.networking.k8s.io/v1`
`kind: BackendTLSPolicy`
`metadata:`
` name: argocd-server-tls`
` namespace: argocd`
`spec:`
` targetRefs:`
` - group: ""`
` kind: Service`
` name: argocd-server`
` validation:`
` hostname: argocd.myinternal.domain`
` caCertificateRefs:`
` - group: ""`
` kind: ConfigMap`
` name: argocd-server-ca-cert`
The exact API version depends on the Gateway API release installed in the cluster; check which version your API server exposes. Also confirm that the HTTPRoute still targets Service port 443. If the policy has no status or events, it may not be recognized by the installed Cilium version, may use an unsupported API version, or may not actually be generated by the Helm values. Without an attached policy, the gateway will usually connect to Argo CD using plain HTTP, which triggers Argo CD’s HTTPS redirect and produces the loop.
The `server.insecure` approach does intentionally disable TLS between the gateway and Argo CD. If you want to avoid per-service backend TLS configuration, another option is to use Cilium’s node or pod network encryption, such as WireGuard or IPsec, while running Argo CD behind an HTTP upstream. That protects the internal hop more broadly, but it is different from Gateway API re-encryption and does not provide backend certificate validation at the gateway.
A redirect loop commonly means the gateway terminates HTTPS, but Argo CD still expects the upstream connection to be HTTPS and redirects the request again. One simple option is to run Argo CD with `server.insecure` enabled and send traffic from the gateway to the Service on port 80. That removes encryption on the gateway-to-pod hop, though it may be acceptable if the cluster network is protected separately.
Wouldn’t that make the gateway-to-pod connection unencrypted? I’m specifically trying to keep TLS enabled on that hop.
The external hostname and the certificate SAN are especially important. A default or self-signed Argo CD certificate often won’t validate for the public Gateway hostname, even when the CA ConfigMap is correct.