grpc/grpc-java · error · ResourceInvalidException

crl in default_validation_context is not supported

Error message

crl in default_validation_context is not supported

What it means

gRPC xDS rejects a CertificateValidationContext whose default_validation_context carries a crl field. CRL-based revocation checking is not implemented by grpc-java's xDS transport security, so the cluster resource is invalid and rejected with ResourceInvalidException.

Source

Thrown at xds/src/main/java/io/grpc/xds/XdsClusterResource.java:524

        if (matchSubjectAltNamesCount > 0 && server) {
          throw new ResourceInvalidException(
              "match_subject_alt_names only allowed in upstream_tls_context");
        }
        if (certificateValidationContext.getVerifyCertificateSpkiCount() > 0) {
          throw new ResourceInvalidException(
              "verify_certificate_spki in default_validation_context is not supported");
        }
        if (certificateValidationContext.getVerifyCertificateHashCount() > 0) {
          throw new ResourceInvalidException(
              "verify_certificate_hash in default_validation_context is not supported");
        }
        if (certificateValidationContext.hasRequireSignedCertificateTimestamp()) {
          throw new ResourceInvalidException(
              "require_signed_certificate_timestamp in default_validation_context is not "
                  + "supported");
        }
        if (certificateValidationContext.hasCrl()) {
          throw new ResourceInvalidException("crl in default_validation_context is not supported");
        }
        if (certificateValidationContext.hasCustomValidatorConfig()) {
          throw new ResourceInvalidException(
              "custom_validator_config in default_validation_context is not supported");
        }
      }
    }
  }

  private static String getIdentityCertInstanceName(CommonTlsContext commonTlsContext) {
    if (commonTlsContext.hasTlsCertificateProviderInstance()) {
      return commonTlsContext.getTlsCertificateProviderInstance().getInstanceName();
    }
    // Fall back to deprecated field (field 11) for backward compatibility with Istio
    @SuppressWarnings("deprecation")
    String instanceName = commonTlsContext.hasTlsCertificateCertificateProviderInstance()
        ? commonTlsContext.getTlsCertificateCertificateProviderInstance().getInstanceName()
        : null;

View on GitHub (pinned to 64daddc1f3)

Solutions

Remove crl from default_validation_context
Handle revocation outside xDS (rotate trust_ca promptly on compromise)
Use short-lived workload certificates (e.g. SPIFFE/SDS) to reduce revocation need
Track grpc-java xDS roadmap for CRL support

Example fix

# before
validation_context:
  default_validation_context:
    crl: { filename: "/etc/crl.pem" }
# after
validation_context:
  default_validation_context: {}
  trust_ca: { ... }

Defensive patterns

Strategy: validation

Validate before calling

if (ctx.getDefaultValidationContext().hasCrl()) {
  throw new IllegalArgumentException("crl unsupported by grpc-java xDS");
}

Try / catch

try {
  cluster = XdsClusterResource.parse(resource);
} catch (ResourceInvalidException e) {
  logger.warn("Cluster rejected: {}", e.getMessage());
}

Prevention

Handle CRL/revocation outside the xDS data plane
Use short-lived certificates (SDS/SPIFFE) to minimize revocation needs
Rotate trust_ca quickly on compromise instead of relying on CRLs

When it happens

Trigger: A Cluster's upstream_tls_context -> common_tls_context -> validation_context.default_validation_context sets crl (a DataSource pointing to a CRL), reaching validateCommonTlsContext via validateUpstreamTlsContext.

Common situations: PKI setups with revocation requirements ported from Envoy; control planes always emitting crl alongside trust_ca; enterprise security baselines mandating CRL checking.

Related errors

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