I'm configuring Cilium Gateway API to expose Argo CD over HTTPS and want encryption on both hops: the client-to-gateway connection and the gateway-to-Argo CD Service connection. TLS passthrough works, but terminating TLS at the gateway and forwarding to Argo CD over HTTPS results in a browser error: `307 NS_ERROR_REDIRECT_LOOP`.
The Gateway listener terminates HTTPS on port 443, and the HTTPRoute forwards to the `argocd-server` Service on port 443. I also enabled a BackendTLSPolicy through the Argo CD Helm values and created a ConfigMap containing the CA certificate extracted from the Argo CD TLS secret. The Gateway is programmed and has a LoadBalancer IP, and Cilium BGP is advertising that address correctly.
However, the BackendTLSPolicy has no status or events. What is the correct configuration for keeping the gateway-to-Argo CD hop encrypted, and what could be causing the redirect loop?
3 Answers
The loop usually means Argo CD is still expecting HTTPS while the gateway is forwarding plain HTTP after terminating the client TLS connection. One quick workaround is to run Argo CD with `server.insecure` enabled and forward to its HTTP port, but that removes TLS between the gateway and the Argo CD pod. It is only appropriate if the in-cluster hop is protected separately, such as with Cilium WireGuard or IPsec encryption.
The gateway listener’s TLS termination and the backend TLS connection are separate. Terminating TLS at the listener is fine, but Argo CD must receive HTTPS from the gateway if `server.insecure` is disabled. Confirm that the BackendTLSPolicy is a real standalone resource with `targetRefs` and `validation`; fields such as `clientCertificateRef` belong to other Gateway API configurations and do not enable ordinary backend re-encryption. A policy that is being reconciled should normally report an ancestor status, so the missing status is an important clue that the resource is unsupported, malformed for the installed API version, or not attached.
For re-encryption, make sure BackendTLSPolicy is deployed as its own Gateway API resource in the Argo CD namespace. It should target the `argocd-server` Service and include a validation hostname plus a CA reference, for example:
`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`
Use `v1alpha3` instead if that is the version installed by your Gateway API release. Check with `kubectl api-resources | grep -i backendtls`. The HTTPRoute should continue to reference the Service on port 443. If the policy has no status, it may not be supported by the installed Cilium version, may use the wrong API version, or may not actually be attached to the Service.
Also verify that the backend certificate contains `argocd.myinternal.domain` in its SANs. Extracting a certificate from the Argo CD secret does not automatically make it valid for that hostname; hostname validation will fail if it is only a self-signed certificate with a different name.
That workaround fixes the redirect, but it does not provide application-level TLS from the gateway to Argo CD. For true end-to-end encryption, the backend must remain on port 443 and the gateway needs a functioning BackendTLSPolicy.