O certificado SSTP non coincide: o nome que debe presentar o seu servidor

SSTP cliente SSTP acepta o servidor só despois de que a validación TLS teña éxito, e esa comprobación compara un nome, unha cadea e un propósito. O nome procede do perfil de conexión, non do enderezo que por casualidade poida facer ping. Cando un dos tres non encaixa, o cliente informa dun problema de certificado e nunca chega á solicitude de inicio de sesión.

O nome do perfil decide que se comproba

SSTP executa TLS sobre TCP 443, así que o cliente compórtase como calquera outro cliente TLS: toma o nome de host do perfil, solicita ese nome e compara o certificado con el. Se escribe un enderezo IP no perfil, a comparación pasa a ser unha comparación de enderezos IP, que a maioría dos certificados de servidor non satisfán.

Por iso unha proba no navegador pode saír ben mentres a VPN falla, porque o navegador usou un nome distinto do perfil. A mesma división aparece cando o DNS split-horizon resolve o nome de host da VPN a un enderezo interno mentres o navegador chegou a un público. Aliñe primeiro o perfil co nome de host documentado e despois compare certificados. Calquera outra cousa que cambie antes é adiviñar.

Que debe levar o certificado do servidor

Os clientes modernos comparan coa extensión de nome alternativo do suxeito, así que o nome de host debe aparecer alí como entrada DNS. Un nome común por si só non basta para as pilas de validación actuais, e un comodín cobre unha etiqueta en lugar de calquera subdominio que invente. Tres certificados ilustran o límite: o nome correcto co propósito equivocado valida a identidade e despois falla a comprobación de propósito, o nome e o propósito correctos cun intermedio ausente fallan a cadea, e un nome que só aparece no nome común falla antes de que calquera dos outros dous importe.

O certificado tamén necesita o propósito de autenticación do servidor, o valor de uso de clave estendido que se nomea en a especificación SSTP de Microsoft, é dicir serverAuth con identificador de obxecto 1.3.6.1.5.5.7.3.1. O uso de clave e unha cadea válida completan o conxunto. Un certificado que existe no servidor, emitido para o nome correcto pero só para autenticación de cliente, segue fallando.

Comprobe a cadea e o reloxo antes das credenciais

Os fallos de tempo e de confianza producen o mesmo resultado visible que unha discrepancia de nome, e ambos son máis baratos de diagnosticar que un problema de contrasinal. Comprobe o reloxo do servidor e o do cliente, e logo lea a cadea tal como a ve o cliente:

# 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 xanela de validez e os nomes alternativos cos que comparará o cliente. O segundo informa de erros de verificación coa cadea tal como se presenta, e aí é onde aparece un intermedio ausente. En Windows, a consulta do servizo de hora dille se o reloxo se está corrixindo ou simplemente se desviou.

Unha CA interna engade unha condición máis: o cliente debe confiar nesa CA. Instale a raíz da organización polo seu canal de distribución aprobado, non desde unha páxina que ofreza un certificado de substitución, porque esa decisión é todo o modelo de confianza en miniatura.

A validación do servidor e a autenticación do usuario son etapas secuenciais con fallos distintos. Un erro de certificado significa que o cliente nunca confiou no servidor, mentres que un contrasinal rexeitado significa que confiou nel e que as credenciais eran incorrectas. Desactivar a validación de certificados para chegar á solicitude de contrasinal elimina a garantía en lugar de reparala. Para demostrar que o resto do camiño funciona, probe o mesmo nome de host e porto desde un cliente que xa confía na cadea, e deixe o perfil despregado tal como está.

Corrixa o nome ou o certificado e probe de novo

Tres condicións deciden a reparación. Se o nome do perfil é incorrecto, corrixa o perfil ou engada o nome que falta ao certificado. Se a cadea está incompleta, instale o intermedio no servidor. Se o propósito é incorrecto, volva emitir en lugar de parchear ao redor.

Despois do cambio, volva conectarse co cliente admitido e confirme que aparece a solicitude de inicio de sesión e logo que o túnel se levanta. Anote no ticket o nome de host utilizado, o emisor e a data de caducidade. Ese rexistro é o que converte a próxima renovación nunha tarefa programada en lugar doutra caída, e tamén mostra á seguinte persoa cal das tres condicións estaba realmente rota.