x509: certificate is valid for example.com, not api.example.com

Os dois nomes são preenchidos a cada falha: primeiro os nomes que o certificado cobre, depois o nome que seu cliente pediu.

Go crypto/x509 — HostnameError from VerifyHostname / TLS dials

O que significa

A conexão TLS avançou o suficiente para ler o certificado, mas nenhum dos Subject Alternative Names (SANs) dele corresponde ao nome de host ao qual o cliente se conectou. O erro lista os dois lados, então a diferença aparece na hora: o certificado cobre X, você pediu Y. Repare que a verificação moderna usa apenas SANs — o campo legado Common Name é ignorado.

Por que acontece

• O nome em uso não está na lista de SANs

  comum

  Um certificado emitido para example.com não cobre api.example.com (e um curinga *.example.com cobre só um nível — nem o próprio example.com, nem a.b.example.com). Subdomínios novos exigem certificados reemitidos.

• Conexão por um alias interno

  comum

  Ao receber uma conexão pelo nome de um serviço do docker-compose ou por outro alias interno, o servidor apresenta o certificado da identidade que ele acha que tem — os SANs trazem nomes DNS públicos, não o seu alias, então a correspondência falha. Já a conexão a um endereço IP puro falha com uma mensagem semelhante: “x509: cannot validate certificate for 10.0.0.5 because it doesn't contain any IP SANs”.

• Certificado errado ou padrão sendo servido (SNI)

  ocasional

  Ingresses multi-tenant escolhem o certificado pelo SNI. Se o cliente omite ServerName, ou se o ingress não tem regra para o host, o cliente recebe o certificado padrão — muitas vezes um provisório como “Kubernetes Ingress Controller Fake Certificate”.

Como corrigir

1. 1.

   Reemitir com todos os nomes que você realmente usa

   Inclua todos os nomes de host como SANs na emissão; examine a lista de SANs atual para ver o que está coberto hoje.

   echo | openssl s_client -connect host:443 -servername api.example.com 2>/dev/null \
     | openssl x509 -noout -ext subjectAltName
   # request with SANs:
   openssl req -new -key key.pem -out req.csr \
     -subj "/CN=example.com" -addext "subjectAltName=DNS:example.com,DNS:api.example.com"

2. 2.

   Conectar pelo nome ou definir ServerName explicitamente

   Quando o endereço de rede precisa ser diferente do nome do certificado (VIP, port-forward, sidecar), mantenha a verificação honesta informando ao TLS qual identidade você espera.

   conn, err := tls.Dial("tcp", "10.0.0.5:443", &tls.Config{
       ServerName: "api.example.com",   // matched against SANs, sent as SNI
   })

← Ver toda a base de erros de assinatura