Certificado SSTP no coincide: el nombre que debe presentar su servidor

SSTP cliente SSTP acepta el servidor solo cuando la validación TLS tiene éxito, y esa comprobación compara un nombre, una cadena y un propósito. El nombre procede del perfil de conexión, no de la dirección que por casualidad pueda hacer ping. Cuando uno de los tres no encaja, el cliente informa de un problema de certificado y nunca llega a la solicitud de inicio de sesión.

El nombre del perfil decide qué se comprueba

SSTP ejecuta TLS sobre TCP 443, así que el cliente se comporta como cualquier otro cliente TLS: toma el nombre de host del perfil, solicita ese nombre y compara el certificado con él. Si escribe una dirección IP en el perfil, la comparación pasa a ser una comparación de direcciones IP, que la mayoría de los certificados de servidor no satisfacen.

Por eso una prueba en el navegador puede salir bien mientras la VPN falla, porque el navegador usó un nombre distinto del perfil. La misma división aparece cuando el DNS split-horizon resuelve el nombre de host de la VPN a una dirección interna mientras el navegador llegó a una pública. Alinee primero el perfil con el nombre de host documentado y luego compare certificados. Cualquier otra cosa que cambie antes es adivinar.

Qué debe llevar el certificado del servidor

Los clientes modernos comparan con la extensión de nombre alternativo del sujeto, así que el nombre de host debe aparecer allí como entrada DNS. Un nombre común por sí solo no basta para las pilas de validación actuales, y un comodín cubre una etiqueta en lugar de cualquier subdominio que invente. Tres certificados ilustran el límite: el nombre correcto con el propósito equivocado valida la identidad y luego falla la comprobación de propósito, el nombre y el propósito correctos con un intermedio ausente fallan la cadena, y un nombre que solo aparece en el nombre común falla antes de que cualquiera de los otros dos importe.

El certificado también necesita el propósito de autenticación del servidor, el valor de uso de clave extendido que se nombra en la especificación SSTP de Microsoft, es decir serverAuth con identificador de objeto 1.3.6.1.5.5.7.3.1. El uso de clave y una cadena válida completan el conjunto. Un certificado que existe en el servidor, emitido para el nombre correcto pero solo para autenticación de cliente, sigue fallando.

Compruebe la cadena y el reloj antes de las credenciales

Los fallos de tiempo y de confianza producen el mismo resultado visible que una discrepancia de nombre, y ambos son más baratos de diagnosticar que un problema de contraseña. Compruebe el reloj del servidor y el del cliente, y luego lea la cadena tal como la ve el 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

El primer comando imprime el nombre, la ventana de validez y los nombres alternativos con los que comparará el cliente. El segundo informa de errores de verificación con la cadena tal como se presenta, y ahí es donde aparece un intermedio ausente. En Windows, la consulta del servicio de hora le dice si el reloj se está corrigiendo o simplemente se ha desviado.

Una CA interna añade una condición más: el cliente debe confiar en esa CA. Instale la raíz de la organización por su canal de distribución aprobado, no desde una página que ofrezca un certificado de sustitución, porque esa decisión es todo el modelo de confianza en miniatura.

La validación del servidor y la autenticación del usuario son etapas secuenciales con fallos distintos. Un error de certificado significa que el cliente nunca confió en el servidor, mientras que una contraseña rechazada significa que confió en él y que las credenciales eran incorrectas. Desactivar la validación de certificados para llegar a la solicitud de contraseña elimina la garantía en lugar de repararla. Para demostrar que el resto del camino funciona, pruebe el mismo nombre de host y puerto desde un cliente que ya confía en la cadena, y deje el perfil desplegado tal como está.

Corrija el nombre o el certificado y vuelva a probar

Tres condiciones deciden la reparación. Si el nombre del perfil es incorrecto, corrija el perfil o añada el nombre que falta al certificado. Si la cadena está incompleta, instale el intermedio en el servidor. Si el propósito es incorrecto, vuelva a emitir en lugar de parchear alrededor.

Tras el cambio, vuelva a conectarse con el cliente admitido y confirme que aparece la solicitud de inicio de sesión y luego que el túnel se levanta. Anote en el ticket el nombre de host utilizado, el emisor y la fecha de caducidad. Ese registro es lo que convierte la próxima renovación en una tarea programada en lugar de otra caída, y también muestra a la siguiente persona cuál de las tres condiciones estaba realmente rota.