SSTP-sertifikaat stem nie ooreen: die naam wat jou bediener moet voorhou
Die kliënt vergelyk die profiel se gasheernaam met die sertifikaat en kontroleer dan die ketting en die doel. Maak die profiel of die sertifikaat reg, nooit die validering nie.
SSTP kliënt aanvaar die bediener eers nadat TLS-validering geslaag het, en daardie kontrole vergelyk ’n naam, ’n ketting en ’n doel. Die naam kom uit die verbindingsprofiel, nie uit die adres wat jy toevallig kan ping nie. Wanneer een van die drie nie klop nie, meld die kliënt ’n sertifikaatprobleem en bereik nooit die aanmeldingsprompt nie.
Die profielnaam bepaal wat gekontroleer word
SSTP loop TLS oor TCP 443, dus gedra die kliënt hom soos enige ander TLS-kliënt: hy neem die gasheernaam uit die profiel, vra daardie naam aan en vergelyk die sertifikaat daarmee. Tik ’n IP-adres in die profiel en die vergelyking word ’n IP-adresvergelyking, waaraan die meeste bediener-sertifikate nie voldoen nie.
’n Blaaier-toets kan dus slaag terwyl die VPN misluk, want die blaaier het ’n ander naam as die profiel gebruik. Dieselfde splitsing ontstaan wanneer split-horizon-DNS die VPN-gasheernaam na ’n interne adres oplos terwyl die blaaier ’n openbare adres bereik het. Pas die profiel eers by die gedokumenteerde gasheernaam aan en vergelyk dan die sertifikate. Enigiets anders wat jy voor dit verander, is raaiwerk.
Wat die bediener-sertifikaat moet dra
Moderne kliënte pas by die onderwerp-alternatiewe-naam-uitbreiding, so die gasheernaam moet daar as ’n DNS-inskrywing voorkom. ’n Algemene naam alleen is nie genoeg vir huidige valideringstapels nie, en ’n jokerteken dek een etiket eerder as enige subdomein wat jy uitdink. Drie sertifikate wys die grens: die regte naam met die verkeerde doel valideer die identiteit en misluk dan die doelkontrole, die regte naam en doel met ’n ontbrekende tussen sertifikaat misluk die ketting, en ’n naam wat net in die algemene naam verskyn, misluk voordat enige van dié twee saak maak.
Die sertifikaat benodig ook die bedienerverifikasie-doel, die uitgebreide sleutelgebruikwaarde wat in Microsoft se SSTP-spesifikasie genoem word, serverAuth met objekidentifiseerder 1.3.6.1.5.5.7.3.1. Sleutelgebruik en ’n geldige ketting maak die stel vol. ’n Sertifikaat wat op die bediener bestaan, vir die regte naam uitgereik is, maar net vir kliëntverifikasie bedoel is, misluk steeds.
Kontroleer eers die ketting en die klok, dan die aanmelding
Tyd- en vertrouensfoute lewer dieselfde sigbare resultaat as ’n naamwanpassing, en albei is goedkoper om te diagnoseer as ’n wagwoordprobleem. Kontroleer die bediener se klok en die kliënt se klok en lees dan die ketting soos die kliënt dit sien:
# 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 /statusDie eerste opdrag druk die naam, die geldigheidsvenster en die alternatiewe name waarmee die kliënt sal vergelyk. Die tweede rapporteer verifikasiefoute met die ketting soos dit voorgelê word, en dit is waar ’n ontbrekende tussen sertifikaat opduik. Op Windows vertel die tyddiens-navraag jou of die klok reggestel word of bloot gedryf het.
’n Interne CA voeg nog een voorwaarde by: die kliënt moet daardie CA vertrou. Installeer die organisasie-wortel via sy goedgekeurde verspreidingskanaal, nie vanaf ’n bladsy wat ’n vervangingsertifikaat aanbied nie, want daardie besluit is die hele vertrouensmodel in klein formaat.
Bedienerverifikasie en gebruiker-verifikasie is opeenvolgende stadiums met verskillende mislukkings. ’n Sertifikaatfout beteken die kliënt het die bediener nooit vertrou nie, terwyl ’n verwerpte wagwoord beteken hy het die bediener vertrou en die geloofsbriewe was verkeerd. Om sertifikaatvalidering af te skakel om by die wagwoordprompt uit te kom, verwyder die waarborg in plaas daarvan om dit te herstel. Om te bewys dat die res van die pad werk, toets dieselfde gasheernaam en poort vanaf ’n kliënt wat die ketting al vertrou, en los die ontplooide profiel alleen.
Maak die naam of die sertifikaat reg en toets weer
Drie voorwaardes bepaal die herstel. As die profielnaam verkeerd is, maak die profiel reg of voeg die ontbrekende naam by die sertifikaat. As die ketting onvolledig is, installeer die tussen sertifikaat op die bediener. As die doel verkeerd is, heruitreik eerder as om daaromheen te pleister.
Maak ná die verandering weer kontak met die ondersteunde kliënt en bevestig dat die aanmeldingsprompt verskyn en dan dat die tonnel opkom. Noteer die gasheernaam wat gebruik is, die uitreiker en die vervaldatum in die kaartjie. Daardie rekord is wat die volgende hernuwing ’n geskeduleerde taak maak eerder as nog ’n onderbreking, en dit wys ook vir die volgende persoon watter van die drie voorwaardes werklik gebreek het.