El certificat SSTP no coincideix: el nom que ha de presentar el servidor

SSTP client SSTP accepta el servidor només després que la validació TLS tingui èxit, i aquesta comprovació compara un nom, una cadena i un propòsit. El nom prové del perfil de connexió, no de l'adreça que per casualitat podeu fer ping. Quan un dels tres no encaixa, el client informa d'un problema de certificat i no arriba mai a la sol·licitud d'inici de sessió.

El nom del perfil decideix què es comprova

SSTP executa TLS sobre TCP 443, així que el client es comporta com qualsevol altre client TLS: agafa el nom d'amfitrió del perfil, sol·licita aquest nom i compara el certificat amb ell. Si escriviu una adreça IP al perfil, la comparació es converteix en una comparació d'adreces IP, que la majoria de certificats de servidor no satisfan.

Per tant, una prova al navegador pot tenir èxit mentre la VPN falla, perquè el navegador ha fet servir un nom diferent del del perfil. La mateixa divisió apareix quan el DNS split-horizon resol el nom d'amfitrió de la VPN a una adreça interna mentre el navegador n'ha assolit una de pública. Alineeu primer el perfil amb el nom d'amfitrió documentat i després compareu certificats. Qualsevol altra cosa que canvieu abans és endevinar.

Què ha de portar el certificat del servidor

Els clients moderns comparen amb l'extensió de nom alternatiu del subjecte, així que el nom d'amfitrió hi ha de constar com a entrada DNS. Un nom comú sol no n'hi ha prou per a les piles de validació actuals, i un comodí cobreix una etiqueta, no qualsevol subdomini que inventeu. Tres certificats il·lustren el límit: el nom correcte amb el propòsit equivocat valida la identitat i després falla la comprovació de propòsit, el nom i el propòsit correctes amb un intermediari absent fallen la cadena, i un nom que només apareix al nom comú falla abans que cap dels dos altres importi.

El certificat també necessita el propòsit d'autenticació del servidor, el valor d'ús de clau estès que s'esmenta a l'especificació SSTP de Microsoft, és a dir serverAuth amb identificador d'objecte 1.3.6.1.5.5.7.3.1. L'ús de clau i una cadena vàlida completen el conjunt. Un certificat que existeix al servidor, emès per al nom correcte però només per a l'autenticació del client, també falla.

Comproveu la cadena i el rellotge abans de les credencials

Les fallades de temps i de confiança produeixen el mateix resultat visible que una discrepància de nom, i tots dos són més barats de diagnosticar que un problema de contrasenya. Comproveu el rellotge del servidor i el del client, i llegiu després la cadena tal com la veu el client:

# 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

La primera ordre imprimeix el nom, la finestra de validesa i els noms alternatius amb què compararà el client. La segona informa d'errors de verificació amb la cadena tal com es presenta, i és aquí on apareix un intermediari absent. A Windows, la consulta del servei de temps us diu si el rellotge s'està corregint o simplement s'ha desviat.

Una CA interna afegeix una condició més: el client ha de confiar en aquesta CA. Instal·leu l'arrel de l'organització pel seu canal de distribució aprovat, no des d'una pàgina que ofereixi un certificat de substitució, perquè aquesta decisió és tot el model de confiança en miniatura.

La validació del servidor i l'autenticació de l'usuari són etapes seqüencials amb fallades diferents. Un error de certificat vol dir que el client no ha confiat mai en el servidor, mentre que una contrasenya rebutjada vol dir que hi ha confiat i que les credencials eren incorrectes. Desactivar la validació de certificats per arribar a la sol·licitud de contrasenya elimina la garantia en lloc de reparar-la. Per demostrar que la resta del camí funciona, proveu el mateix nom d'amfitrió i port des d'un client que ja confia en la cadena, i deixeu el perfil desplegat tal com és.

Corregiu el nom o el certificat i torneu a provar

Tres condicions decideixen la reparació. Si el nom del perfil és incorrecte, corregiu el perfil o afegiu el nom que falta al certificat. Si la cadena és incompleta, instal·leu l'intermediari al servidor. Si el propòsit és incorrecte, reemeteu en lloc de pedaçar-hi al voltant.

Després del canvi, torneu a connectar-vos amb el client admès i confirmeu que apareix la sol·licitud d'inici de sessió i després que el túnel s'aixeca. Anoteu al tiquet el nom d'amfitrió utilitzat, l'emissor i la data de caducitat. Aquest registre és el que converteix la propera renovació en una tasca programada en lloc d'una altra caiguda, i també mostra a la següent persona quina de les tres condicions s'havia trencat realment.