SSTP-certifikatet stämmer inte: namnet din server måste visa

Klienten jämför profilens värdnamn med certifikatet och kontrollerar sedan kedjan och syftet. Reparera profilen eller certifikatet, aldrig valideringen.

SSTP klient accepterar servern först när TLS-valideringen lyckas, och den kontrollen jämför ett namn, en kedja och ett syfte. Namnet kommer från anslutningsprofilen, inte från adressen du råkar kunna pinga. När en av de tre inte stämmer rapporterar klienten ett certifikatproblem och når aldrig inloggningsprompten.

Profilnamnet avgör vad som kontrolleras

SSTP kör TLS över TCP 443, så klienten beter sig som vilken annan TLS-klient som helst: den tar värdnamnet från profilen, begär det namnet och jämför certifikatet med det. Skriver du en IP-adress i profilen blir jämförelsen en IP-adressjämförelse, som de flesta servercertifikat inte uppfyller.

Därför kan ett browsertest lyckas medan VPN misslyckas, eftersom webbläsaren använde ett annat namn än profilen. Samma delning visas när split-horizon-DNS löser VPN-värdnamnet till en intern adress medan webbläsaren nådde en publik. Justera profilen mot det dokumenterade värdnamnet först och jämför sedan certifikat. Allt annat du ändrar före det är gissningar.

Vad servercertifikatet måste innehålla

Moderna klienter jämför med tillägget för alternativa subjektnamn, så värdnamnet måste stå där som en DNS-post. Ett vanligt namn räcker inte för dagens valideringsstackar, och ett jokertecken täcker en etikett och inte vilken subdomän du hittar på. Tre certifikat visar gränsen: rätt namn med fel syfte validerar identiteten och misslyckas sedan i syfteskontrollen, rätt namn och syfte med ett saknat mellancertifikat misslyckas på kedjan, och ett namn som bara finns i det vanliga namnet misslyckas innan någon av de andra två spelar roll.

Certifikatet behöver också syftet serverautentisering, värdet för utökad nyckelanvändning som nämns i Microsofts SSTP-specifikation, det vill säga serverAuth med objektidentifieraren 1.3.6.1.5.5.7.3.1. Nyckelanvändning och en giltig kedja fullbordar uppsättningen. Ett certifikat som finns på servern, är utfärdat för rätt namn men bara för klientautentisering, misslyckas ändå.

Kontrollera kedjan och klockan före inloggningsuppgifterna

Tids- och förtroendefel ger samma synliga resultat som en namnavvikelse, och båda är billigare att diagnostisera än ett lösenordsproblem. Kontrollera serverns klocka och klientens klocka och läs sedan kedjan 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

Det första kommandot skriver ut namnet, giltighetsfönstret och de alternativa namn som klienten kommer att jämföra mot. Det andra rapporterar verifieringsfel med kedjan så som den presenteras, och det är där ett saknat mellancertifikat dyker upp. På Windows berättar klocktjänstens fråga om klockan rättas eller bara har drivit.

En intern CA lägger till ett villkor: klienten måste lita på den CA:n. Installera organisationsroten via dess godkända distributionskanal, inte från en sida som erbjuder ett ersättningscertifikat, eftersom det beslutet är hela förtroendemodellen i miniatyr.

Servervalidering och användarautentisering är sekventiella steg med olika fel. Ett certifikatfel betyder att klienten aldrig litade på servern, medan ett avvisat lösenord betyder att den litade på servern och att uppgifterna var fel. Att stänga av certifikatvalideringen för att nå lösenordsprompten tar bort garantin i stället för att reparera den. För att bevisa att resten av vägen fungerar, testa samma värdnamn och port från en klient som redan litar på kedjan, och låt den utrullade profilen vara.

Rätta namnet eller certifikatet och testa igen

Tre villkor avgör reparationen. Om profilnamnet är fel, rätta profilen eller lägg till det saknade namnet i certifikatet. Om kedjan är ofullständig, installera mellancertifikatet på servern. Om syftet är fel, utfärda på nytt i stället för att lappa runt det.

Efter ändringen ansluter du igen med den klient som stöds och bekräftar att inloggningsprompten visas och sedan att tunneln kommer upp. Anteckna värdnamnet som användes, utfärdaren och utgångsdatumet i ärendet. Den anteckningen gör nästa förnyelse till en planerad uppgift i stället för ännu ett avbrott, och den visar också nästa person vilket av de tre villkoren som faktiskt var brutet.

Relaterade artiklar