SSTP klient accepterer først serveren, når TLS-valideringen er lykkedes, og den kontrol sammenligner et navn, en kæde og et formål. Navnet kommer fra forbindelsesprofilen, ikke fra den adresse, du tilfældigvis kan pinge. Når en af de tre ikke stemmer, rapporterer klienten et certifikatproblem og når aldrig loginprompten.

Profilnavnet afgør, hvad der kontrolleres

SSTP kører TLS over TCP 443, så klienten opfører sig som enhver anden TLS-klient: den tager værtsnavnet fra profilen, anmoder om det navn og sammenligner certifikatet med det. Skriver du en IP-adresse i profilen, bliver sammenligningen en IP-adressesammenligning, som de fleste servercertifikater ikke opfylder.

Derfor kan en browsertest lykkes, mens VPN fejler, fordi browseren brugte et andet navn end profilen. Den samme opdeling viser sig, når split-horizon-DNS opløser VPN-værtsnavnet til en intern adresse, mens browseren nåede en offentlig. Afstem profilen med det dokumenterede værtsnavn først, og sammenlign derefter certifikater. Alt andet, du ændrer før det, er gætværk.

Hvad servercertifikatet skal indeholde

Moderne klienter matcher mod udvidelsen med alternative subjektnavne, så værtsnavnet skal stå der som en DNS-post. Et fælles navn alene er ikke nok til nutidens valideringsstakke, og et jokertegn dækker én etiket i stedet for ethvert underdomæne, du finder på. Tre certifikater viser grænsen: det rigtige navn med det forkerte formål validerer identiteten og fejler derefter formålskontrollen, det rigtige navn og formål med en manglende mellemliggende certifikat fejler kæden, og et navn, der kun står i det fælles navn, fejler, før nogen af de to andre betyder noget.

Certifikatet skal også have formålet servergodkendelse, værdien for udvidet nøglebrug, der er nævnt i Microsofts SSTP-specifikation, altså serverAuth med objektidentifikator 1.3.6.1.5.5.7.3.1. Nøglebrug og en gyldig kæde fuldender sættet. Et certifikat, der findes på serveren, er udstedt til det rigtige navn, men kun til klientgodkendelse, fejler stadig.

Kontrollér kæden og uret før loginoplysninger

Tids- og tillidsfejl giver samme synlige resultat som et navnemismatch, og begge er billigere at diagnosticere end et adgangskodeproblem. Kontrollér serverens ur og klientens ur, og læs derefter kæden, som klienten ser den:

# 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 kommando udskriver navnet, gyldighedsvinduet og de alternative navne, som klienten vil sammenligne med. Den anden rapporterer verifikationsfejl med kæden som præsenteret, og det er der, en manglende mellemliggende certifikat dukker op. På Windows fortæller tidskvasispørgslen, om uret bliver rettet, eller blot er løbet.

En intern CA tilføjer endnu en betingelse: klienten skal stole på den CA. Installér organisationsroden via dens godkendte distributionskanal, ikke fra en side, der tilbyder et erstatningscertifikat, fordi den beslutning er hele tillidsmodellen i miniature.

Servervalidering og brugerautentificering er sekventielle trin med forskellige fejl. En certifikatfejl betyder, at klienten aldrig stolede på serveren, mens en afvist adgangskode betyder, at den stolede på serveren, og at oplysningerne var forkerte. At slå certifikatvalidering fra for at nå adgangskodeprompten fjerner garantien i stedet for at reparere den. For at bevise, at resten af vejen virker, skal du teste det samme værtsnavn og den samme port fra en klient, der allerede stoler på kæden, og lade den udrullede profil være i fred.

Ret navnet eller certifikatet, og test igen

Tre betingelser afgør reparationen. Hvis profilnavnet er forkert, ret profilens navn eller føj det manglende navn til certifikatet. Hvis kæden er ufuldstændig, så installér den mellemliggende certifikat på serveren. Hvis formålet er forkert, så genudsted i stedet for at lappe rundt om det.

Efter ændringen skal du genoprette forbindelsen med den understøttede klient og bekræfte, at loginprompten vises, og derefter at tunnelen kommer op. Notér det brugte værtsnavn, udstederen og udløbsdatoen i sagen. Den registrering er det, der gør den næste fornyelse til en planlagt opgave i stedet for endnu en afbrydelse, og den viser også den næste person, hvilken af de tre betingelser der faktisk var brudt.

Relaterede artikler