Skip to content
You are viewing the documentation for Solo Enterprise for Istio, formerly known as Gloo Mesh (OSS APIs).

For the complete documentation index, see llms.txt. Markdown versions of all docs pages are available by appending .md to any docs URL.

SPIFFE trust domain chain verification

Enterprise
Page as Markdown
Enable strict mode to require that the mTLS certificate chain attests the peer’s SPIFFE trust domain.
This setting blocks trust domain spoofing when multiple intermediate authorities share a common root of trust.
About SPIFFE trust domain chain verification

Note
This feature requires your mesh to be installed with the Solo distribution of Istio and an Enterprise-level license for Solo Enterprise for Istio. Contact your account representative to obtain a valid license.
By default, ztunnel validates only that a peer certificate is rooted in a trust anchor from the mesh trust bundle. When multiple intermediate authorities share a common root, a workload in one trust domain could present a certificate that chains to the shared root but claims a different trust domain. Without chain verification, ztunnel accepts such a certificate as valid for the declared trust domain.
With VALIDATE_SPIFFE_TRUST_DOMAIN_NAMES=STRICT, ztunnel adds an additional check during the mTLS handshake. For each connection, ztunnel walks the verified certificate chain from the direct parent to the trust anchor, and requires at least one ancestor certificate to carry a Subject Alternative Name (SAN) that matches the trust domain declared in the leaf SPIFFE URI. The check applies to both inbound and outbound connections.
SAN matching rules

An ancestor SAN matches the leaf trust domain using the following rules.
DNS SANs:
SAN formExampleMatches trust domain
Exactexample.orgexample.org only
Leading-dot suffix.example.orgtd.example.org, a.b.example.org, and any subdomain
Single-label wildcard*.example.orgtd.example.org but not a.b.example.org
URI SANs:
  • A SPIFFE URI SAN (for example, spiffe://example.org or spiffe://example.org/ns/istio-system/sa/istiod) matches when the URI authority component equals the trust domain. Matching is case-insensitive.
  • Non-SPIFFE URI SANs, such as CRL distribution point URLs, are skipped rather than rejected.
  • A malformed SPIFFE URI (for example, spiffe:// with no authority) in any chain certificate causes the connection to be rejected immediately, even when a later certificate in the chain would have matched.
Before you begin

Configure a plugged-in CA whose intermediate certificates carry DNS SANs or URI SANs that cover the mesh trust domain. STRICT mode walks the verified certificate chain and rejects connections when no ancestor certificate has a matching SAN. The default Istio self-signed CA does not add trust domain SANs to its issued certificates. Enabling STRICT mode with a self-signed CA causes ztunnel to reject all connections.
Enable trust domain chain verification

  1. Enable STRICT mode on the ztunnel.
    helm upgrade ztunnel oci://us-docker.pkg.dev/soloio-img/istio-helm/ztunnel \
  --version 1.30.3-solo \
  --namespace istio-system \
  --reuse-values \
  --set env.VALIDATE_SPIFFE_TRUST_DOMAIN_NAMES=STRICT
  2. Verify that the ztunnel DaemonSet is running.
    kubectl -n istio-system rollout status daemonset/ztunnel
  3. Confirm that existing connections between workloads still succeed. A connection failure at this stage indicates that your CA intermediates do not carry SANs that match the mesh trust domain. Reconfigure your CA to issue intermediate certificates with DNS SANs or SPIFFE URI SANs that cover the trust domain, then re-enable STRICT mode.
Query workload identity from applicationsOverview