SSTP-sertifikat stemmer ikke: navnet serveren din må vise

SSTP klient godtar først serveren når TLS-valideringen lykkes, og den kontrollen sammenligner et navn, en kjede og et formål. Navnet kommer fra tilkoblingsprofilen, ikke fra adressen du tilfeldigvis kan ping. Når én av de tre ikke stemmer, rapporterer klienten et sertifikatproblem og når aldri påloggingsforespørselen.

Profilnavnet avgjør hva som kontrolleres

SSTP kjører TLS over TCP 443, så klienten oppfører seg som enhver annen TLS-klient: den tar vertsnavnet fra profilen, ber om det navnet og sammenligner sertifikatet med det. Skriver du en IP-adresse i profilen, blir sammenligningen en IP-adressesammenligning, som de fleste servertsertifikater ikke oppfyller.

Derfor kan en nettlesertest lykkes mens VPN feiler, fordi nettleseren brukte et annet navn enn profilen. Den samme delingen vises når split-horizon-DNS løser opp VPN-vertsnavnet til en intern adresse mens nettleseren nådde en offentlig. Juster profilen mot det dokumenterte vertsnavnet først, og sammenlign deretter sertifikater. Alt annet du endrer før det, er gjetting.

Hva servertsertifikatet må inneholde

Moderne klienter sammenligner mot utvidelsen for alternative subjektnavn, så vertsnavnet må stå der som en DNS-oppføring. Et vanlig navn alene er ikke nok for dagens valideringsstakker, og et jokertegn dekker én etikett i stedet for enhver underdomene du finner på. Tre sertifikater viser grensen: det riktige navnet med feil formål validerer identiteten og feiler deretter formålskontrollen, det riktige navnet og formålet med et manglende mellomsertifikat feiler på kjeden, og et navn som bare står i det vanlige navnet, feiler før noen av de to andre betyr noe.

Sertifikatet trenger også formålet serverautentisering, verdien for utvidet nøkkelbruk som er nevnt i Microsofts SSTP-spesifikasjon, altså serverAuth med objektidentifikatoren 1.3.6.1.5.5.7.3.1. Nøkkelbruk og en gyldig kjede fullfører settet. Et sertifikat som finnes på serveren, er utstedt for det riktige navnet, men bare for klientautentisering, feiler likevel.

Kontroller kjeden og klokken før påloggingsinformasjonen

Tids- og tillitsfeil gir samme synlige resultat som et navneavvik, og begge er billigere å diagnostisere enn et passordproblem. Kontroller klokken på serveren og klokken på klienten, og les deretter kjeden slik 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 kommandoen skriver ut navnet, gyldighetsvinduet og de alternative navnene klienten vil sammenligne mot. Den andre rapporterer verifiseringsfeil med kjeden slik den presenteres, og det er der et manglende mellomsertifikat dukker opp. På Windows forteller klokketjenestespørringen om klokken blir korrigert eller bare har drevet.

En intern CA legger til én betingelse: klienten må stole på den CA-en. Installer organisasjonsroten via dens godkjente distribusjonskanal, ikke fra en side som tilbyr et erstatningssertifikat, fordi den beslutningen er hele tillitsmodellen i miniatyr.

Servervalidering og brukerautentisering er sekvensielle stadier med ulike feil. En sertifikatfeil betyr at klienten aldri stolte på serveren, mens et avvist passord betyr at den stolte på serveren og at påloggingsinformasjonen var feil. Å slå av sertifikatvalidering for å nå passordforespørselen fjerner garantien i stedet for å reparere den. For å bevise at resten av veien virker, test det samme vertsnavnet og den samme porten fra en klient som allerede stoler på kjeden, og la den utrullede profilen være i fred.

Rett navnet eller sertifikatet, og test på nytt

Tre betingelser avgjør reparasjonen. Hvis profilnavnet er feil, rett profilen eller legg det manglende navnet til sertifikatet. Hvis kjeden er ufullstendig, installer mellomsertifikatet på serveren. Hvis formålet er feil, utsted på nytt i stedet for å lappe rundt det.

Etter endringen kobler du til på nytt med den støttede klienten og bekrefter at påloggingsforespørselen vises, og deretter at tunnelen kommer opp. Noter vertsnavnet som ble brukt, utstederen og utløpsdatoen i saken. Den registreringen er det som gjør neste fornyelse til en planlagt oppgave i stedet for nok et avbrudd, og den viser også neste person hvilken av de tre betingelsene som faktisk var brutt.