SSTP-certificaat komt niet overeen: de naam die uw server moet tonen

SSTP client accepteert de server pas nadat de TLS-validatie slaagt, en die controle vergelijkt een naam, een keten en een doel. De naam komt uit het verbindingsprofiel, niet uit het adres dat u toevallig kunt pingen. Als een van de drie niet klopt, meldt de client een certificaatprobleem en bereikt nooit de inlogprompt.

De profielnaam bepaalt wat er wordt gecontroleerd

SSTP draait TLS over TCP 443, dus de client gedraagt zich als elke andere TLS-client: hij neemt de hostnaam uit het profiel, vraagt die naam aan en vergelijkt het certificaat ermee. Typt u een IP-adres in het profiel, dan wordt de vergelijking een IP-adresvergelijking, waaraan de meeste servercertificaten niet voldoen.

Een browsertest kan daarom slagen terwijl de VPN faalt, omdat de browser een andere naam gebruikte dan het profiel. Dezelfde splitsing ontstaat wanneer split-horizon-DNS de VPN-hostnaam naar een intern adres omzet terwijl de browser een openbaar adres bereikte. Lijn eerst het profiel uit op de gedocumenteerde hostnaam en vergelijk daarna certificaten. Al het andere dat u daarvoor wijzigt, is giswerk.

Wat het servercertificaat moet bevatten

Moderne clients vergelijken met de uitbreiding voor alternatieve subjectnamen, dus de hostnaam moet daar als DNS-item staan. Een common name alleen is niet genoeg voor de huidige validatiestacks, en een jokerteken dekt één label en niet elk subdomein dat u verzint. Drie certificaten tonen de grens: de juiste naam met het verkeerde doel valideert de identiteit en faalt daarna op de doelcontrole, de juiste naam en het juiste doel met een ontbrekend tussenliggend certificaat falen op de keten, en een naam die alleen in de common name staat, faalt voordat een van de andere twee ertoe doet.

Het certificaat heeft ook het doel serverauthenticatie nodig, de waarde voor uitgebreid sleutelgebruik die in de SSTP-specificatie van Microsoft wordt genoemd, namelijk serverAuth met objectidentificatie 1.3.6.1.5.5.7.3.1. Sleutelgebruik en een geldige keten maken de set compleet. Een certificaat dat op de server staat, voor de juiste naam is uitgegeven maar alleen voor clientauthenticatie, faalt alsnog.

Controleer keten en klok vóór de inloggegevens

Tijd- en vertrouwensfouten geven hetzelfde zichtbare resultaat als een naamafwijking, en beide zijn goedkoper te diagnosticeren dan een wachtwoordprobleem. Controleer de klok van de server en de klok van de client en lees daarna de keten zoals de client die ziet:

# 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

De eerste opdracht drukt de naam, het geldigheidsvenster en de alternatieve namen af waarmee de client zal vergelijken. De tweede meldt verificatiefouten met de keten zoals gepresenteerd, en daar duikt een ontbrekend tussenliggend certificaat op. Op Windows vertelt de query van de tijddienst of de klok wordt gecorrigeerd of gewoon is weggelopen.

Een interne CA voegt nog een voorwaarde toe: de client moet die CA vertrouwen. Installeer de organisatiewortel via het goedgekeurde distributiekanaal, niet vanaf een pagina die een vervangend certificaat aanbiedt, want die beslissing is het hele vertrouwensmodel in het klein.

Servervalidatie en gebruikersauthenticatie zijn opeenvolgende fasen met verschillende fouten. Een certificaatfout betekent dat de client de server nooit vertrouwde, terwijl een geweigerd wachtwoord betekent dat hij de server vertrouwde en de inloggegevens onjuist waren. Certificaatvalidatie uitschakelen om bij de wachtwoordprompt te komen haalt de garantie weg in plaats van hem te repareren. Om te bewijzen dat de rest van het pad werkt, test u dezelfde hostnaam en poort vanaf een client die de keten al vertrouwt, en laat u het uitgerolde profiel met rust.

Herstel de naam of het certificaat en test opnieuw

Drie voorwaarden bepalen de reparatie. Als de profielnaam fout is, herstel dan het profiel of voeg de ontbrekende naam toe aan het certificaat. Als de keten onvolledig is, installeer dan het tussenliggende certificaat op de server. Als het doel fout is, geef dan opnieuw uit in plaats van eromheen te lappen.

Maak na de wijziging opnieuw verbinding met de ondersteunde client en bevestig dat de inlogprompt verschijnt en daarna dat de tunnel opkomt. Noteer de gebruikte hostnaam, de uitgever en de vervaldatum in het ticket. Die registratie maakt de volgende verlenging tot een geplande taak in plaats van nog een storing, en laat de volgende persoon zien welke van de drie voorwaarden echt was geschonden.