x509: certificate relies on legacy Common Name field, use SANs instead

Dentro de las conexiones TLS (Go 1.20+), el texto lleva el prefijo «tls: failed to verify certificate: », y los clientes HTTP añaden «Get \"https://…\": ». Los programas escritos en Go (kubectl, Terraform, Docker, Prometheus, Vault CLI) imprimen el mismo texto.

Go crypto/x509 — HostnameError for a certificate without subjectAltName (Go 1.15+)

Qué significa

El certificado del servidor no tiene la extensión de nombre alternativo del sujeto (SAN), así que el nombre de host solo existe en el nombre común (CN) del sujeto. Go dejó de aceptar nombres de host tomados del nombre común en Go 1.15 (por completo en 1.17), siguiendo el RFC 6125 y las reglas del CA/Browser Forum, y lo dice explícitamente cuando el CN habría coincidido. La solución es un certificado con SAN; ya no queda ningún interruptor en el lado del cliente.

Por qué ocurre

• Certificado generado sin subjectAltName

  frecuente

  openssl req -x509 -subj "/CN=host" sin -addext subjectAltName, u openssl x509 -req al firmar una CSR sin -copy_extensions/-extfile, produce exactamente este tipo de certificado.

• Un perfil de CA interna anterior al requisito de SAN

  frecuente

  Las plantillas antiguas de Active Directory Certificate Services, los scripts heredados y las CA de dispositivos dedicados suelen emitir certificados que solo tienen CN.

• Certificados autogenerados de dispositivos y software antiguo

  ocasional

  Algunos dispositivos dedicados, bases de datos y middleware generan en el primer arranque certificados que solo tienen CN.

Cómo solucionarlo

1. 1.

   Confirmar que falta la extensión SAN

   Imprime el sujeto y el subjectAltName del certificado que se sirve.

   echo | openssl s_client -connect api.example.com:443 -servername api.example.com 2>/dev/null \
     | openssl x509 -noout -subject -ext subjectAltName
   # No "X509v3 Subject Alternative Name" in the output -> reissue the certificate

2. 2.

   Volver a emitir con subjectAltName

   Pon en subjectAltName todos los nombres DNS (y la dirección IP, si los clientes usan una). Al firmar CSR con openssl x509 -req, las extensiones de la CSR se descartan a menos que pases -copy_extensions copy o un -extfile.

   openssl req -new -key server.key -subj "/CN=api.example.com" \
     -addext "subjectAltName=DNS:api.example.com" -out server.csr
   # when signing with "openssl x509 -req", keep the extension:
   openssl x509 -req -in server.csr -CA ca.pem -CAkey ca.key -days 90 -copy_extensions copy -out server.pem

3. 3.

   No buscar una opción de Go

   La vía de escape temporal GODEBUG=x509ignoreCN=0 se eliminó en Go 1.17, así que volver a emitir el certificado es la única solución.

   GODEBUG=x509ignoreCN=0 only worked in Go 1.15–1.16 and was removed in Go 1.17;
   there is no switch left in current Go releases. The certificate must carry SANs.

← Explorar toda la base de datos de errores de firma