grpc/grpc-java · error · ResourceInvalidException

downstream-tls-context with ocsp_staple_policy value ${ocspS

Error message

downstream-tls-context with ocsp_staple_policy value ${ocspStaplePolicy.name()} is not supported

What it means

gRPC xDS supports only LENIENT_STAPLING (or unset) for the ocsp_staple_policy field of a downstream TLS context. Any other OCSP staple policy value (e.g. STRICT_STAPLING, PERMIT_NO_STAPLING) makes the Listener resource invalid, so XdsListenerResource.validateDownstreamTlsContext throws a ResourceInvalidException and the Listener is rejected (NACKed).

Source

Thrown at xds/src/main/java/io/grpc/xds/XdsListenerResource.java:314

  static DownstreamTlsContext validateDownstreamTlsContext(
      DownstreamTlsContext downstreamTlsContext, Set<String> certProviderInstances)
      throws ResourceInvalidException {
    if (downstreamTlsContext.hasCommonTlsContext()) {
      validateCommonTlsContext(downstreamTlsContext.getCommonTlsContext(), certProviderInstances,
          true);
    } else {
      throw new ResourceInvalidException(
          "common-tls-context is required in downstream-tls-context");
    }
    if (downstreamTlsContext.hasRequireSni()) {
      throw new ResourceInvalidException(
          "downstream-tls-context with require-sni is not supported");
    }
    DownstreamTlsContext.OcspStaplePolicy ocspStaplePolicy = downstreamTlsContext
        .getOcspStaplePolicy();
    if (ocspStaplePolicy != DownstreamTlsContext.OcspStaplePolicy.UNRECOGNIZED
        && ocspStaplePolicy != DownstreamTlsContext.OcspStaplePolicy.LENIENT_STAPLING) {
      throw new ResourceInvalidException(
          "downstream-tls-context with ocsp_staple_policy value " + ocspStaplePolicy.name()
              + " is not supported");
    }
    return downstreamTlsContext;
  }

  private static void validateFilterChainMatchForUniqueness(
      Set<FilterChainMatch> filterChainMatchSet,
      FilterChainMatch filterChainMatch) throws ResourceInvalidException {
    // Flattens complex FilterChainMatch into a list of simple FilterChainMatch'es.
    List<FilterChainMatch> crossProduct = getCrossProduct(filterChainMatch);
    for (FilterChainMatch cur : crossProduct) {
      if (!filterChainMatchSet.add(cur)) {
        throw new ResourceInvalidException("FilterChainMatch must be unique. "
            + "Found duplicate: " + cur);
      }
    }
  }

View on GitHub (pinned to 64daddc1f3)

Solutions

1. Set ocsp_staple_policy to LENIENT_STAPLING in the downstream_tls_context, or remove the field entirely so it defaults to unset.
2. If strict OCSP stapling is a hard requirement, do not use gRPC xDS for that listener; terminate TLS at Envoy instead of the gRPC client/server.
3. Check the control plane that generates the Listener resource and remove or adjust the ocsp_staple_policy override.

Example fix

// before (Envoy Listener v3 YAML)
downstream_tls_context:
  common_tls_context: ...
  ocsp_staple_policy: STRICT_STAPLING
// after
downstream_tls_context:
  common_tls_context: ...
  ocsp_staple_policy: LENIENT_STAPLING

// before submitting the Listener resource
if (hcm.hasDownstreamTlsContext()
    && hcm.getDownstreamTlsContext().getOcspStaplePolicy() != UNSET
    && hcm.getDownstreamTlsContext().getOcspStaplePolicy() != LENIENT_STAPLING) {
  throw new IllegalArgumentException("ocsp_staple_policy must be LENIENT_STAPLING or unset");
}

// xDS clients surface this via Listener error/nack status
listenerWatcher.onError(status); // inspect Status detail for "ocsp_staple_policy value ... is not supported"

When it happens

Trigger: An xDS Listener proto whose filter_chain's downstream_tls_context has ocsp_staple_policy set to STRICT_STAPLING or PERMIT_NO_STAPLING, encountered while parsing filter chains via parseFilterChain -> validateDownstreamTlsContext.

Common situations: Envoy config generated with OCSP stapling enforcement enabled (control planes that copy Envoy defaults), security-hardened templates requiring strict stapling, or hand-written bootstrap YAML that sets ocsp_staple_policy for compliance reasons.

Understand the failure class

• SSL/TLS and certificate errors — how TLS handshakes and certificate validation fail.

Related errors

• common-tls-context is required in upstream-tls-context
• unsupported ExtAuthz service type: only grpc_service is supp
• Invalid ring hash function: " + ringHash.getHashFunction()
• Custom LB config does not contain a JSON object
• Invalid header matcher config: [grpc-] prefixed header name

AI-assisted analysis of grpc/grpc-java@64daddc1f3 (2026-09-08). Data as JSON: /api/errors/88a0e31581f2938f. Report an issue: GitHub.