envoyproxy / envoyproxy/gateway
Support skipping SAN validation in BackendTLSPolicy for backends with certificates lacking Subject Alternative Names
- Dominant language
- Go
- Stars
- 3k
- Forks
- 864
- Avg merge
- 1d 22h
- Merged PRs (30d)
- 148
Description
## Description
When using `BackendTLSPolicy` for TLS re-encryption to upstream backends, Envoy Gateway enforces SAN (Subject Alternative Name) validation on backend certificates. If the backend certificate has no SANs, only a Common Name (CN), the connection fails with no way to override this behavior through the standard API.
This is a real-world issue for organizations that use internal or legacy PKI software that generates certificates without SANs. These certificates are valid and signed by a trusted CA, but Envoy Gateway rejects them due to the validation.
Currently, we are circumventing this issue with a patch for envoy like the following but this is not sustainable or scalable since we have to do this now for each and every route.
```yaml
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyPatchPolicy
metadata:
name: disable-san-verification
spec:
targetRef:
group: gateway.networking.k8s.io
kind: Gateway
name: default
type: JSONPatch
jsonPatches:
- type: "type.googleapis.com/envoy.config.cluster.v3.Cluster"
name: "httproute/default/tls-reencrypt/rule/0"
operation:
op: remove
path: "/transport_socket_matches/0/transport_socket/typed_config/common_tls_context/combined_validation_context/default_validation_context/match_typed_subject_alt_names"
```
This is fragile and unscalable, the patch path needs the specific route name, so **a separate patch is needed per route**. We are also skeptic that this might break on any internal XDS structure change.
**NOTE: We unfortunately can't use `Backend` since that doesn't work with our use case as the service is still internal. So changes introduced in https://github.com/envoyproxy/gateway/pull/6222 won't work**
## Desired State(what could work)
A field in `BackendTLSPolicy` (or an Envoy Gateway extension to it) that allows **skipping SAN validation while preserving CA certificate validation**. Something like:
```yaml
apiVersion: gateway.networking.k8s.io/v1
kind: BackendTLSPolicy
spec:
targetRefs:
- kind: Service
name: my-backend
validation:
caCertificateRefs:
- kind: ConfigMap
name: backend-ca
hostname: my-backend.example.com
# New field: skip SAN matching, still validate CA chain
skipSubjectAltNameValidation: true
```
Alternatively since these are Gateway API CRDs and i'm not sure how complicated it would be to request these there. Maybe we can add ways to disable TLS verification and SANs verification at a global level for the EG installation itself.
## Related Issues
- #4595 — Original issue (TLS backend cert validation types)
- #4381 — GEP-3155 / BackendTLS implementation
- #6253 — `insecure-skip-verify` for Backend resource (merged)
- #8380 — `tls.frontend` / `tls.backend` for Backend resource (merged)
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.