SSTP klient godtek først serveren når TLS-valideringa lukkast, og den kontrollen samanliknar eit namn, ei kjede og eit føremål. Namnet kjem frå tilkoplingsprofilen, ikkje frå adressa du tilfeldigvis kan pinga. Når éin av dei tre ikkje stemmer, rapporterer klienten eit sertifikatproblem og når aldri påloggingsforespurnaden.

Profilnamnet avgjer kva som vert kontrollert

SSTP køyrer TLS over TCP 443, så klienten oppfører seg som ein kvar annan TLS-klient: han tek vertsnamnet frå profilen, ber om det namnet og samanliknar sertifikatet med det. Skriv du ei IP-adresse i profilen, vert samanlikninga ei IP-adressesamanlikning, som dei fleste servertsertifikata ikkje oppfyller.

Derfor kan ein nettlesartest lukkast medan VPN feilar, fordi nettlesaren brukte eit anna namn enn profilen. Den same delinga viser seg når split-horizon-DNS løyser opp VPN-vertsnamnet til ei intern adresse medan nettlesaren nådde ei offentleg. Juster profilen mot det dokumenterte vertsnamnet først, og samanlikn deretter sertifikat. Alt anna du endrar før det, er gissing.

Kva servertsertifikatet må innehalde

Moderne klientar samanliknar med utvidinga for alternative subjektnamn, så vertsnamnet må stå der som ein DNS-oppføring. Eit vanleg namn åleine er ikkje nok for dagens valideringsstablar, og eit jokerteikn dekkjer éi etikett i staden for eit kva som helst underdomene du finn på. Tre sertifikat viser grensa: det riktige namnet med feil føremål validerer identiteten og feilar deretter føremålskontrollen, det riktige namnet og føremålet med eit manglande mellomsertifikat feilar på kjeda, og eit namn som berre står i det vanlege namnet, feilar før nokon av dei to andre tyder noko.

Sertifikatet treng òg føremålet serverautentisering, verdien for utvida nøkkelbruk som er nemnd i Microsofts SSTP-spesifikasjon, altså serverAuth med objektidentifikatoren 1.3.6.1.5.5.7.3.1. Nøkkelbruk og ei gyldig kjede fullfører settet. Eit sertifikat som finst på serveren, er utskrive for det riktige namnet, men berre for klientautentisering, feilar likevel.

Kontroller kjeda og klokka før påloggingsinformasjonen

Tids- og tillitsfeil gjev same synlege resultat som eit namneavvik, og begge er billegare å diagnostisera enn eit passordproblem. Kontroller klokka på serveren og klokka på klienten, og les deretter kjeda slik klienten ser henne:

# 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

Den første kommandoen skriv ut namnet, gyldigheitsvindauget og dei alternative namna klienten vil samanlikna mot. Den andre rapporterer verifiseringsfeil med kjeda slik ho vert presentert, og det er der eit manglande mellomsertifikat dukkar opp. På Windows fortel klokketenestespørjinga om klokka vert retta eller berre har dreve.

Ein intern CA legg til eitt vilkår: klienten må stola på den CA-en. Installer organisasjonsrota via den godkjende distribusjonskanalen hennar, ikkje frå ei side som tilbyr eit erstatningssertifikat, fordi den avgjerda er heile tillitsmodellen i miniatyr.

Servervalidering og brukarautentisering er sekvensielle steg med ulike feil. Ein sertifikatfeil betyr at klienten aldri stolte på serveren, medan eit avvist passord betyr at han stolte på serveren og at påloggingsinformasjonen var feil. Å slå av sertifikatvalidering for å nå passordforespurnaden fjernar garantien i staden for å reparera han. For å prova at resten av vegen verkar, test same vertsnamnet og same porten frå ein klient som allereie stolar på kjeda, og lat den utrulla profilen vera i fred.

Retta namnet eller sertifikatet, og test på nytt

Tre vilkår avgjer reparasjonen. Viss profilnamnet er feil, retta profilen eller legg det manglande namnet til sertifikatet. Viss kjeda er ufullstendig, installer mellomsertifikatet på serveren. Viss føremålet er feil, gjev ut på nytt i staden for å lappa rundt det.

Etter endringa koplar du til på nytt med den støtta klienten og stadfestar at påloggingsforespurnaden viser seg, og deretter at tunnelen kjem opp. Noter vertsnamnet som vart brukt, utskrivaren og utløpsdatoen i saka. Den registreringa er det som gjer neste fornying til ei planlagd oppgåve i staden for nok eit avbrot, og ho viser òg neste person kva av dei tre vilkåra som faktisk var brote.

Relaterte artiklar