Certificado SSTP não corresponde: o nome que seu servidor deve apresentar

SSTP cliente SSTP só aceita o servidor depois que a validação TLS é bem-sucedida, e essa verificação compara um nome, uma cadeia e uma finalidade. O nome vem do perfil de conexão, não do endereço que por acaso você consegue pingar. Quando um dos três não confere, o cliente relata um problema de certificado e nunca chega à solicitação de login.

O nome do perfil decide o que é verificado

O SSTP executa TLS sobre TCP 443, então o cliente se comporta como qualquer outro cliente TLS: pega o nome de host do perfil, solicita esse nome e compara o certificado com ele. Se você digitar um endereço IP no perfil, a comparação passa a ser uma comparação de endereços IP, que a maioria dos certificados de servidor não satisfaz.

Por isso um teste no navegador pode dar certo enquanto a VPN falha, porque o navegador usou um nome diferente do perfil. A mesma divisão aparece quando o DNS split-horizon resolve o nome de host da VPN para um endereço interno enquanto o navegador chegou a um público. Alinhe primeiro o perfil ao nome de host documentado e depois compare os certificados. Qualquer outra coisa que você mudar antes disso é suposição.

O que o certificado do servidor deve conter

Os clientes modernos comparam com a extensão de nome alternativo do sujeito, então o nome de host precisa aparecer ali como entrada DNS. Um nome comum sozinho não basta para as pilhas de validação atuais, e um curinga cobre um rótulo, não qualquer subdomínio que você invente. Três certificados ilustram o limite: o nome certo com a finalidade errada valida a identidade e depois falha na verificação de finalidade, o nome e a finalidade certos com um intermediário ausente falham na cadeia, e um nome que só aparece no nome comum falha antes que qualquer um dos outros dois importe.

O certificado também precisa da finalidade autenticação do servidor, o valor de uso estendido de chave nomeado em a especificação SSTP da Microsoft, ou seja serverAuth com identificador de objeto 1.3.6.1.5.5.7.3.1. O uso de chave e uma cadeia válida completam o conjunto. Um certificado que existe no servidor, emitido para o nome certo mas apenas para autenticação de cliente, ainda falha.

Verifique a cadeia e o relógio antes das credenciais

As falhas de tempo e de confiança produzem o mesmo resultado visível de uma divergência de nome, e ambos custam menos para diagnosticar do que um problema de senha. Verifique o relógio do servidor e o do cliente e depois leia a cadeia como o cliente a vê:

# from the client, or any host that runs openssl
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -ext subjectAltName
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -verify_return_error </dev/null
# on the Windows server that holds the SSTP listener
w32tm /query /status

O primeiro comando imprime o nome, a janela de validade e os nomes alternativos com os quais o cliente comparará. O segundo relata erros de verificação com a cadeia conforme apresentada, e é aí que um intermediário ausente aparece. No Windows, a consulta ao serviço de hora diz se o relógio está sendo corrigido ou simplesmente derivou.

Uma CA interna acrescenta mais uma condição: o cliente precisa confiar nessa CA. Instale a raiz da organização pelo canal de distribuição aprovado, não a partir de uma página que ofereça um certificado substituto, porque essa decisão é todo o modelo de confiança em miniatura.

A validação do servidor e a autenticação do usuário são etapas sequenciais com falhas diferentes. Um erro de certificado significa que o cliente nunca confiou no servidor, enquanto uma senha rejeitada significa que ele confiou no servidor e que as credenciais estavam erradas. Desligar a validação de certificado para chegar à solicitação de senha remove a garantia em vez de repará-la. Para provar que o resto do caminho funciona, teste o mesmo nome de host e a mesma porta a partir de um cliente que já confia na cadeia, e deixe o perfil implantado como está.

Corrija o nome ou o certificado e teste novamente

Três condições decidem o reparo. Se o nome do perfil estiver errado, corrija o perfil ou acrescente o nome que falta ao certificado. Se a cadeia estiver incompleta, instale o intermediário no servidor. Se a finalidade estiver errada, emita novamente em vez de remendar em volta.

Depois da alteração, reconecte com o cliente suportado e confirme que a solicitação de login aparece e depois que o túnel sobe. Anote no chamado o nome de host usado, o emissor e a data de expiração. Esse registro é o que transforma a próxima renovação em uma tarefa agendada em vez de outra queda, e também mostra à próxima pessoa qual das três condições estava realmente quebrada.