Currently, both prod and non-prod client certs can access production endpoints via the external HTTP(S) Load Balancer (XLB), as there is no SAN-based filtering at the LB level.
Our goal:
To configure the Load Balancer or associated Apigee X resources (TrustConfigs, Server TLS Policies, Target HTTPS Proxies) to strictly reject mTLS client connections where the certificate SAN does not match the environment endpoint (e.g., block non-prod certs on prod URLs and vice versa).
Constraints:
We want to maintain a single private CA for simplicity and cost-efficiency.
The filtering should ideally happen as early as possible (at the LB or Server TLS Policy level) to avoid unnecessary Apigee processing and associated costs.
If not, what are best practices or alternative approaches?
Has anyone faced and solved this requirement with Apigee X or GCP Network Security? Any guidance, examples, or documentation pointers would be greatly appreciated.
I don’t know how to do it on the Load Balancer, but this can definitely be done in Apigee.
Once mTLS is negotiated, the LB passes down client cert info via x-apigee-tls-* headers, which Apigee turns into flow variables. You can get:
tls.client.raw.cert - the full client cert in PEM
tls.client.cert.fingerprint - SHA1 fingerprint
tls.client.s.dn - the subject DN (but note: SAN is not in the DN, only CN is)
So if you want to restrict access based on SAN, you’ve got a couple of options.
One is just to whitelist fingerprints (per environment) and store them in KVM. Then you can do the check in a PreProxyFlowHook and reject mismatches early. It’s simple, but managing fingerprints can be annoying.
Another option is to write a JavaCallout that parses the PEM (tls.client.raw.cert) and extracts the SAN field. That lets you check if the cert is meant for dev/test/prod via custom logic, based on DNS entries in SAN. Just keep in mind that SAN can contain multiple values, so your parsing logic needs to account for that.
Thanks a lot for your detailed response — it’s very helpful! In our case, we’re trying to enforce this check before the request even reaches Apigee, ideally at the XLB level. The reason is to avoid unnecessary Apigee processing and costs when invalid client certificates (e.g., non-prod certs on prod URLs) are presented. So, we’re really looking to implement this filtering as early as possible — directly on the Load Balancer or within the TLS negotiation process using TrustConfigs or ServerTlsPolicies. Do you (or anyone else) know the best forum or GCP product area where I should post this specific question around mTLS + SAN filtering at the Load Balancer level?