NET::ERR_CERT_COMMON_NAME_INVALID

O que este erro significa e como reconhecê-lo

• O Chrome ou Edge exibe “Sua conexão não é particular” com NET::ERR_CERT_COMMON_NAME_INVALID.
• Os detalhes do certificado mostram um Common Name ou Subject Alternative Name referente a um hostname diferente.
• O domínio raiz funciona, mas um subdomínio específico falha.
• O erro começa após adicionar um subdomínio, alterar o DNS, migrar a hospedagem ou ativar uma CDN ou um load balancer.
• Um servidor compartilhado ou uma CDN apresenta um certificado padrão, de placeholder ou não relacionado.
• Alguns usuários ou redes veem o erro, enquanto outros não, geralmente indicando caminhos diferentes de IPv4, IPv6, DNS ou roteamento de edge.

Causas principais, por probabilidade

1. O certificado não inclui o hostname solicitado. O hostname que falha pode estar ausente da lista de SANs do certificado. Um wildcard pode cobrir alguns subdomínios, mas seu escopo deve corresponder ao nome solicitado.
2. O servidor está servindo o certificado padrão. A hospedagem compartilhada pode não ter o certificado atribuído ao domínio, ou a seleção de SNI e de virtual host HTTPS pode estar incorreta.
3. Uma CDN ou um load balancer tem o certificado de edge incorreto. O hostname pode não estar configurado no serviço, ou a solicitação pode chegar a um listener padrão ou a uma configuração de edge padrão.
4. O DNS aponta para o endpoint incorreto. Um registro A, AAAA ou CNAME incorreto pode enviar a solicitação para um servidor que apresenta o certificado de outro site. Um registro AAAA incorreto pode afetar usuários de IPv6 mesmo quando o IPv4 funciona.
5. Uma migração ou alteração de domínio deixou os serviços fora de sincronia. O DNS, a CDN, o servidor de origem e o certificado podem estar configurados para hostnames ou endpoints diferentes.

Como corrigir

1. Identifique o hostname exato e a incompatibilidade do certificado

Verifique o hostname completo na barra de endereço, incluindo todos os subdomínios. Abra os detalhes do certificado no navegador e inspecione o Common Name e os Subject Alternative Names (SANs). O hostname solicitado deve aparecer na lista de SANs ou corresponder a um padrão wildcard aplicável.

Para uma verificação pela linha de comando, defina a variável com o hostname que você está testando:

HOSTNAME='[your hostname]'
openssl s_client -connect "$HOSTNAME:443" -servername "$HOSTNAME" </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

A opção -servername envia o hostname por SNI, o que é importante em infraestruturas HTTPS compartilhadas. Execute os comandos de diagnóstico antes de fazer alterações de configuração.

2. Adicione o hostname ao certificado

Se o certificado cobre o domínio raiz, mas não o subdomínio que falha, emita novamente ou substitua-o por um certificado que inclua o hostname necessário como SAN. Um certificado wildcard pode cobrir vários subdomínios de um nível, mas confirme separadamente a cobertura do domínio raiz e de quaisquer subdomínios mais profundos.

Se estiver usando o Certbot, confirme primeiro que você tem autorização para solicitar e implantar um certificado para o domínio, que o webroot está correto e que o método de validação é adequado ao servidor. Inclua todos os nomes necessários na solicitação de emissão:

DOMAIN='[your bare domain]'
SUBDOMAIN='[your subdomain]'
certbot certonly --webroot -w '[your webroot]' -d "$DOMAIN" -d "$SUBDOMAIN"

Isso obtém um certificado, mas não o instala nem o ativa por si só. Use o método de emissão e o webroot apropriados ao servidor; depois, instale o certificado no endpoint que termina o HTTPS e atribua-o ao hostname correto.

3. Verifique a hospedagem compartilhada e a configuração do servidor de origem

No painel de controle da hospedagem, confirme que um certificado está instalado e atribuído ao domínio ou subdomínio exato. Em um servidor compartilhado, peça ao provedor para verificar a seleção de certificados baseada em SNI e a configuração do virtual host HTTPS.

Recarregue ou reinicie o servidor web somente depois de confirmar que os arquivos do certificado, as permissões e a configuração estão corretos. Um reload ou reinício pode interromper o serviço; portanto, siga o procedimento de alteração do provedor e obtenha a autorização necessária antes de aplicá-lo.

4. Verifique a cobertura do certificado na CDN e no load balancer

Confirme que o hostname exato está configurado na CDN ou no load balancer e incluído no certificado de edge. Confirme também que o hostname é roteado para a origem pretendida.

Se a CDN termina o HTTPS, o certificado da origem, sozinho, não resolve uma incompatibilidade no navegador. O certificado servido pelo endpoint público de edge deve cobrir o hostname. Se a CDN encaminha o HTTPS sem terminá-lo, inspecione o certificado na origem.

5. Verifique o DNS para IPv4 e IPv6

Compare os registros A, AAAA e CNAME do hostname com o endpoint ou destino fornecido pelo provedor de hospedagem ou CDN. Verifique se a rede com falha usa IPv4 ou IPv6 e se ambos os caminhos chegam ao serviço pretendido.

Corrija registros obsoletos ou não intencionais somente depois de confirmar o endpoint pretendido e o procedimento adequado para a alteração de DNS. Verifique o resultado a partir da rede afetada, pois respostas de DNS armazenadas em cache podem persistir até o TTL expirar.

6. Teste novamente o mesmo hostname HTTPS

Depois de alterar a atribuição do certificado, o roteamento ou o DNS, teste a URL exata que falhou. Inspecione novamente o certificado retornado e confirme sua lista de SANs, emissor e datas de validade. Teste a partir da rede afetada e também do ambiente de hospedagem, CDN ou servidor para distinguir diferenças de propagação ou resolver de uma configuração incorreta ativa.

Prevenção e como verificar a correção

• Inclua a cobertura do certificado sempre que adicionar um subdomínio, alterar o DNS, migrar a hospedagem ou adicionar uma CDN.
• Use cobertura por SAN ou um wildcard com escopo adequado somente depois de verificar o domínio raiz, os subdomínios de um nível e os nomes mais profundos realmente usados pelo serviço.
• Mantenha alinhados os registros DNS, os hostnames da CDN, os listeners do load balancer, os virtual hosts da origem e as atribuições de certificados.
• Teste os caminhos A e AAAA após alterações de DNS.
• Inspecione o certificado servido pelo endpoint público em vez de depender apenas da ausência de um aviso no navegador.
• Registre qual serviço termina o HTTPS para que as alterações de certificado sejam feitas na camada correta.
• Mantenha procedimentos de renovação e implantação de certificados que incluam todos os hostnames necessários.

Perguntas frequentes