grpc/grpc-java · error · ResourceInvalidException

require_signed_certificate_timestamp in default_validation_c

Error message

require_signed_certificate_timestamp in default_validation_context is not supported

What it means

gRPC xDS rejects a CertificateValidationContext whose default_validation_context sets require_signed_certificate_timestamp. Signed certificate timestamp (CT) verification is not implemented in grpc-java's xDS security layer, so the cluster resource is rejected with ResourceInvalidException.

Source

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

            .getDefaultValidationContext();
      }
      if (certificateValidationContext != null) {
        @SuppressWarnings("deprecation") // gRFC A29 predates match_typed_subject_alt_names
        int matchSubjectAltNamesCount = certificateValidationContext.getMatchSubjectAltNamesCount();
        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();
    }

View on GitHub (pinned to 64daddc1f3)

Solutions

  1. Remove require_signed_certificate_timestamp from default_validation_context
  2. Validate CT out-of-band (e.g. at cert issuance) instead of in-band via xDS
  3. Keep trust anchored with trust_ca and SAN matching
  4. Verify grpc-java release notes for CT support before re-adding

Example fix

# before
validation_context:
  default_validation_context:
    require_signed_certificate_timestamp: true
# after
validation_context:
  default_validation_context: {}
Defensive patterns

Strategy: validation

Validate before calling

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

Try / catch

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

Prevention

When it happens

Trigger: validateCommonTlsContext (via validateUpstreamTlsContext) sees CertificateValidationContext.require_signed_certificate_timestamp set inside default_validation_context of a cluster's upstream_tls_context.

Common situations: Certificate-transparency compliance configs from Envoy carried over to gRPC xDS; security hardening tooling that toggles CT on all TLS contexts; control planes emitting the field by default.

Understand the failure class

Related errors


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