grpc/grpc-go · error

security configuration on the client-side does not contain r

Error message

security configuration on the client-side does not contain root certificate provider instance name

What it means

Returned by securityConfigFromCommonTLSContext (unmarshal_cds.go:417-418) for a client-side security config when the root certificate provider instance name is empty AND UseSystemRootCerts is false. Clients must validate the server cert, so a security block without either a root provider or system roots is rejected. The client branch (server==false) enforces this after field parsing.

Source

Thrown at internal/xds/xdsclient/xdsresource/unmarshal_cds.go:418

	sc, err1 := securityConfigFromCommonTLSContextUsingNewFields(common, server)
	if sc == nil || sc.Equal(&SecurityConfig{}) {
		var err error
		sc, err = securityConfigFromCommonTLSContextWithDeprecatedFields(common, server)
		if err != nil {
			// Retain the validation error from using the new fields.
			return nil, errors.Join(err1, fmt.Errorf("failed to parse config using deprecated fields: %v", err))
		}
	}
	if sc != nil {
		// sc == nil is a valid case where the control plane has not sent us any
		// security configuration. xDS creds will use fallback creds.
		if server {
			if sc.IdentityInstanceName == "" {
				return nil, errors.New("security configuration on the server-side does not contain identity certificate provider instance name")
			}
		} else {
			if !sc.UseSystemRootCerts && sc.RootInstanceName == "" {
				return nil, errors.New("security configuration on the client-side does not contain root certificate provider instance name")
			}
		}
	}
	return sc, nil
}

func securityConfigFromCommonTLSContextWithDeprecatedFields(common *v3tlspb.CommonTlsContext, server bool) (*SecurityConfig, error) {
	// The `CommonTlsContext` contains a
	// `tls_certificate_certificate_provider_instance` field of type
	// `CertificateProviderInstance`, which contains the provider instance name
	// and the certificate name to fetch identity certs.
	sc := &SecurityConfig{}
	if identity := common.GetTlsCertificateCertificateProviderInstance(); identity != nil {
		sc.IdentityInstanceName = identity.GetInstanceName()
		sc.IdentityCertName = identity.GetCertificateName()
	}

	// The `CommonTlsContext` contains a `validation_context_type` field which

View on GitHub (pinned to 03255a9237)

Solutions

  1. Add a validation_context with a certificate_provider_instance.instance_name (root cert provider) to the client CommonTlsContext.
  2. If you want the OS trust store, enable the system-roots option (so UseSystemRootCerts becomes true) instead of leaving the root context empty.
  3. Verify the referenced root cert provider is registered in bootstrap.

Example fix

// before
//   common_tls_context: { tls_certificate_certificate_provider_instance: {...} }  // no validation
// after
//   common_tls_context: {
//     tls_certificate_certificate_provider_instance: {...},
//     validation_context: { certificate_provider_instance: { instance_name: "default", certificate_name: "ca" } }
//   }
Defensive patterns

Strategy: validation

Validate before calling

func clientSecurityHasRoots(sc *SecurityConfig) bool {
    return sc != nil && (sc.UseSystemRootCerts || sc.RootInstanceName != "")
}

Prevention

When it happens

Trigger: A client-side CommonTlsContext (UpstreamTlsContext) yields a non-nil SecurityConfig with RootInstanceName=="" and UseSystemRootCerts false. Reached when no validation_context certificate-provider-instance and no system-roots opt-in are configured.

Common situations: Control plane sets an identity cert but omits the validation/root context; intending to use system roots but not enabling the UseSystemRootCerts flag; a bootstrap missing the root cert provider.

Understand the failure class

Related errors


AI-assisted analysis of grpc/grpc-go@03255a9237 (2026-08-07). Data as JSON: /api/errors/09c16fa7f5f294ab. Report an issue: GitHub.