Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[Low] ate-api-server accepts client certificates chained to system roots when --pod-identity-ca-certs is unset

Abierto Apto para principiantes
  • ¿Algo no está bien?
#2,918 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@abhisheksharma2411 ya está trabajando en esto.

Desde el 20/10/2026.

  • #3023 de @abhisheksharma2411 — abierto

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
75/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
go
Área
backend, security

Línea de trabajo

Empieza en cmd/ateapi/main.go, en buildServerTLSConfig (líneas 631–643), y comprueba cómo configura los certificados de cliente la rama con caCertsPath vacío. Lee el comportamiento de autenticación de clientes TLS de Go descrito en el issue y luego ejecuta las pruebas pertinentes de ate-api-server. La tarea estará terminada cuando la configuración con la ruta vacía no autentique certificados de cliente a través de las raíces del sistema y las pruebas cubran ese comportamiento.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

area/security kind/bug

Summary

When --pod-identity-ca-certs is omitted (empty caCertsPath), cmd/ateapi/main.go:buildServerTLSConfig returns a tls.Config with ClientAuth: tls.VerifyClientCertIfGiven and ClientCAs: nil. Under Go's crypto/tls implementation, a nil ClientCAs causes client certificate verification to fall back to the host system root CAs, allowing any client certificate trusted by a system root containing a SPIFFE URI SAN to authenticate as an mTLS principal.

Details

In cmd/ateapi/main.go:631-643:

func buildServerTLSConfig(ctx context.Context, credBundlePath, caCertsPath string) (*tls.Config, error) {
	serverCert := credbundle.Loader(credBundlePath)
	const clientAuth = tls.VerifyClientCertIfGiven

	if caCertsPath == "" {
		return &tls.Config{
			GetCertificate: serverCert,
			ClientAuth:     clientAuth,
		}, nil
	}

When caCertsPath == "", ClientCAs is left nil. In Go's crypto/tls/handshake_server.go:

opts := x509.VerifyOptions{
    Roots: c.config.ClientCAs,
    CurrentTime: c.config.time(),
    Intermediates: x509.NewCertPool(),
    KeyUsages: []x509.ExtKeyUsage{x509.ExtKeyUsageClientAuth},
}

When opts.Roots is nil, x509.Certificate.Verify defaults to the host's system root CAs. If a client certificate verified by any system CA includes a URI SAN, apiauthn.UnaryServerInterceptor extracts the URI SAN via mtlsPeerIdentity and treats the caller as an authenticated mTLS principal without inspecting or requiring bearer token authentication.

Impact

Low: in standard deployments (manifests/ate-install/ate-api-server.yaml:180), --pod-identity-ca-certs is always provided. The fallback occurs only when --pod-identity-ca-certs is omitted. In standard deployments (manifests/ate-install/ate-api-server.yaml:180), --pod-identity-ca-certs is always provided, pointing to /run/podidentity.podcert.ate.dev/trust-bundle.pem. The fallback occurs only in non-standard or standalone deployments where --pod-identity-ca-certs is deliberately omitted. Furthermore, obtaining a publicly-trusted certificate containing a URI SAN (e.g., spiffe://...) with the clientAuth EKU is non-trivial under standard Web PKI CA baseline requirements. NetworkPolicies on ate-api-server also restrict ingress on port 443 to control plane pods or namespaces labeled ate.dev/api-access=true.

Suggested fix

When caCertsPath == "", explicitly disable client certificate verification by setting ClientAuth: tls.NoClientCert in the returned tls.Config:

	if caCertsPath == "" {
		return &tls.Config{
			GetCertificate: serverCert,
			ClientAuth:     tls.NoClientCert,
		}, nil
	}

Related

No existing duplicate issues or PRs found.

Lenguaje dominante
Go
Estrellas
5.9k
Forks
637
Merge medio
2 d 10 h
PR fusionados (30 d)
556

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de agent-substrate/substrate

Todos los issues de agent-substrate/substrate

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.