Certificat SSTP nepotrivit: numele pe care serverul tău trebuie să îl prezinte

SSTP client SSTP acceptă serverul doar după ce validarea TLS reușește, iar acea verificare compară un nume, un lanț și un scop. Numele vine din profilul de conexiune, nu din adresa pe care din întâmplare o poți pinga. Când unul dintre cele trei nu se potrivește, clientul raportează o problemă de certificat și nu ajunge niciodată la promptul de autentificare.

Numele din profil decide ce se verifică

SSTP rulează TLS peste TCP 443, așa că clientul se comportă ca orice alt client TLS: ia numele de gazdă din profil, cere acel nume și compară certificatul cu el. Dacă introduci o adresă IP în profil, comparația devine o comparație de adrese IP, pe care majoritatea certificatelor de server nu o satisfac.

De aceea un test în browser poate reuși în timp ce VPN-ul eșuează, pentru că browserul a folosit un nume diferit de cel din profil. Aceeași divizare apare când DNS split-horizon rezolvă numele de gazdă al VPN-ului la o adresă internă, în timp ce browserul a ajuns la una publică. Aliniază mai întâi profilul la numele de gazdă documentat, apoi compară certificatele. Orice altceva schimbi înainte de asta este presupunere.

Ce trebuie să conțină certificatul serverului

Clienții moderni compară cu extensia numelor alternative ale subiectului, deci numele de gazdă trebuie să apară acolo ca intrare DNS. Doar numele comun nu este suficient pentru stivele de validare actuale, iar un metacaracter acoperă o etichetă, nu orice subdomeniu pe care îl inventezi. Trei certificate arată limita: numele corect cu scopul greșit validează identitatea și apoi eșuează la verificarea scopului, numele și scopul corecte cu un intermediar lipsă eșuează pe lanț, iar un nume care apare doar în numele comun eșuează înainte ca vreunul dintre celelalte două să conteze.

Certificatul are nevoie și de scopul autentificarea serverului, valoarea de utilizare extinsă a cheii numită în specificația SSTP a Microsoft, adică serverAuth cu identificatorul de obiect 1.3.6.1.5.5.7.3.1. Utilizarea cheii și un lanț valid completează setul. Un certificat care există pe server, emis pentru numele corect, dar doar pentru autentificarea clientului, eșuează în continuare.

Verifică lanțul și ceasul înainte de datele de autentificare

Defecțiunile de timp și de încredere produc același rezultat vizibil ca o nepotrivire de nume, iar ambele sunt mai ieftin de diagnosticat decât o problemă de parolă. Verifică ceasul serverului și ceasul clientului, apoi citește lanțul așa cum îl vede clientul:

# 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

Prima comandă tipărește numele, fereastra de valabilitate și numele alternative cu care clientul va compara. A doua raportează erori de verificare împreună cu lanțul așa cum este prezentat, și acolo apare un intermediar lipsă. Pe Windows, interogarea serviciului de timp îți spune dacă ceasul este corectat sau doar a derivat.

O CA internă adaugă încă o condiție: clientul trebuie să aibă încredere în acea CA. Instalează rădăcina organizației prin canalul de distribuție aprobat, nu de pe o pagină care oferă un certificat de înlocuire, pentru că acea decizie este întregul model de încredere în miniatură.

Validarea serverului și autentificarea utilizatorului sunt etape succesive cu defecțiuni diferite. O eroare de certificat înseamnă că clientul nu a avut niciodată încredere în server, în timp ce o parolă respinsă înseamnă că a avut încredere în server și credențialele erau greșite. Dezactivarea validării certificatului ca să ajungi la promptul de parolă elimină garanția în loc să o repare. Pentru a demonstra că restul traseului funcționează, testează același nume de gazdă și același port de la un client care are deja încredere în lanț, și lasă profilul implementat așa cum este.

Repară numele sau certificatul și testează din nou

Trei condiții decid reparația. Dacă numele din profil este greșit, repară profilul sau adaugă numele lipsă la certificat. Dacă lanțul este incomplet, instalează intermediarul pe server. Dacă scopul este greșit, reemite în loc să peticesti în jurul lui.

După modificare, reconectează-te cu clientul acceptat și confirmă că apare promptul de autentificare și apoi că tunelul urcă. Notează în tichet numele de gazdă folosit, emitentul și data expirării. Acea înregistrare face din următoarea reînnoire o sarcină planificată în loc de o altă cădere și îi arată următoarei persoane care dintre cele trei condiții era cu adevărat încălcată.