Nomes alternativos do sujeito: como um servidor VPN é identificado

Seu cliente rejeita um certificado cuja cadeia é validada corretamente, e o erro diz que o nome não corresponde. Essa mensagem não é sobre quem assinou o certificado. Ela é sobre a extensão de nomes alternativos do sujeito, que carrega as identidades que o certificado pode representar, e sobre se a identidade que você configurou aparece ali na forma correta. A confiança responde quem o assinou, enquanto a verificação do nome responde a qual host ele pertence.

O que o cliente realmente compara

O cliente transforma sua configuração em uma identidade de referência: um nome de host, um endereço ou um identificador específico do protocolo. Depois procura essa identidade no certificado, aplicando as regras de correspondência do protocolo em uso. Apenas entradas do mesmo tipo contam, então uma entrada DNS não pode satisfazer um endereço, e a comparação ocorre quer alguém olhe o certificado ou não.

Quando a identidade de referência falta nessa extensão, a verificação falha mesmo que o nome comum antigo corresponda. Um certificado pode ser legitimamente emitido para uma empresa e ainda assim ser o errado para vpn.example.com se o nome nunca foi incluído. A falha é uma divergência de nome, embora o certificado seja autêntico.

Nomes DNS e endereços IP são entradas separadas

Um perfil que aponta para 203.0.113.10 enquanto o certificado lista apenas vpn.example.com é rejeitado, porque os pacotes chegam mas a identidade não corresponde. Nomes DNS e endereços literais são armazenados como tipos de entrada diferentes, e um nunca substitui o outro. Por isso um serviço pode ser acessível por endereço e ainda assim inutilizável por meio de um perfil que use esse endereço.

Curingas também obedecem às próprias regras: um curinga cobre um único rótulo, não todos os nomes sob um domínio. A comparação DNS não diferencia maiúsculas de minúsculas, enquanto outros tipos de identificador diferenciam, então um valor que parece idêntico na tela pode falhar numa comparação estrita. Verifique as regras de correspondência do tipo de identidade em uso em vez de comparar cadeias a olho. Adicionar um nome à extensão é uma decisão de emissão, não algo que uma configuração de cliente possa fornecer.

Inspecione o certificado que a conexão realmente usou

Leia o material apresentado pelo endpoint ativo, não um arquivo copiado de uma página de administração. Um balanceador de carga ou uma instância de substituição pode apresentar algo diferente do certificado enviado meses atrás, e essa diferença é invisível num console.

openssl s_client -connect vpn.example.com:443 -showcerts </dev/null | openssl x509 -noout -text

O bloco de nomes alternativos do sujeito, a cadeia do emissor e o período de validade pertencem a uma mesma leitura, porque uma divergência de nome e uma expiração produzem erros diferentes. Compare cada nome desse bloco com a identidade configurada no perfil, caractere por caractere, e anote de que tipo ele é. Repetir o comando contra a forma de endereço do endpoint mostra se o certificado cobre as duas identidades ou apenas uma. Uma exibição amigável do sujeito num console de gestão não é um resultado de validação e não diz nada sobre quais nomes a extensão contém.

O nome comum não é a fonte moderna da verdade

Navegadores e a maioria das bibliotecas TLS agora ignoram o nome comum para a correspondência de nomes de host e consultam a extensão. Alguns clientes VPN ainda comparam primeiro o nome comum ou recorrem a ele quando a extensão está ausente, e assim um certificado pode passar num navegador e falhar num cliente. A mesma verificação de nome pode passar numa plataforma e falhar noutra sem que o certificado mude em nada.

Descubra qual campo o seu cliente lê antes de decidir que o certificado está errado. Dois clientes no mesmo endpoint podem discordar, e a discordância é informação sobre o cliente, não sobre o certificado.

Corrija a emissão ou o perfil, não a verificação

Quando um perfil foi construído em torno de um alias, ou aponte-o para o nome de host documentado ou reemita o certificado para o alias e implante-o numa janela planejada. Silenciar o aviso não é uma terceira opção, porque a verificação é o único passo que liga um certificado assinado a este host específico. Removê-la significa que qualquer certificado da mesma autoridade pode substituir o servidor que você pretendia alcançar.

A renovação deve preservar os nomes e o propósito pretendidos em vez de apenas adiar a data de expiração. Uma renovação que perde um nome é uma nova interrupção programada para o próximo reinício, e geralmente chega sem aviso porque o certificado antigo ainda era válido quando a mudança foi feita.

Registre a identidade esperada, os nomes apresentados e a cadeia que os assinou. Esse registro transforma a próxima renovação numa comparação em vez de uma investigação. A definição da extensão está na RFC 5280 se precisar verificar uma emissão específica.