grpc/grpc-java · error · ResourceInvalidException

custom_validator_config in default_validation_context is not

Error message

custom_validator_config in default_validation_context is not supported

What it means

gRPC xDS rejects a CertificateValidationContext whose default_validation_context sets custom_validator_config. Pluggable custom certificate validators are not supported by grpc-java's xDS transport security, so any cluster resource carrying one is rejected with ResourceInvalidException.

Source

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

        }
        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;
    return instanceName;
  }

View on GitHub (pinned to 64daddc1f3)

Solutions

Remove custom_validator_config from default_validation_context
Use the built-in validation: trust_ca plus match_subject_alt_names
Implement any bespoke validation at the application/transport layer instead
Confirm grpc-java xDS supported CertificateValidationContext fields before generating config

Example fix

# before
validation_context:
  default_validation_context:
    custom_validator_config:
      name: envoy.tls.cert_validator.custom
# after
validation_context:
  default_validation_context: {}

Defensive patterns

Strategy: validation

Validate before calling

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

Try / catch

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

Prevention

Avoid Envoy typed_extension validators in grpc-java xDS configs
Use built-in trust_ca + SAN validation
Implement custom checks in application code instead

When it happens

Trigger: validateCommonTlsContext (reached via validateUpstreamTlsContext) encounters CertificateValidationContext.custom_validator_config (a typed extension config) inside default_validation_context of a cluster's upstream_tls_context.

Common situations: Envoy configs using custom validator extensions (e.g. Envoi-specific validators); frameworks injecting custom_validator_config into all TLS contexts; users expecting grpc-java extension parity with Envoy.

Related errors

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