SSTP-atestilo ne kongruas: la nomo, kiun via servilo devas prezenti

SSTP kliento akceptas la servilon nur post kiam TLS-validigo sukcesas, kaj tiu kontrolo komparas nomon, ĉenon kaj celon. La nomo venas el la konekta profilo, ne el la adreso, kiun vi hazarde povas pingi. Kiam unu el la tri ne kongruas, la kliento raportas atestilan problemon kaj neniam atingas la ensalutan inviton.

La profila nomo decidas, kio estas kontrolata

SSTP funkciigas TLS super TCP 443, do la kliento kondutas kiel ajna alia TLS-kliento: ĝi prenas la gastigan nomon el la profilo, petas tiun nomon kaj komparas la atestilon kun ĝi. Se vi tajpas IP-adreson en la profilon, la komparo fariĝas komparo de IP-adresoj, kiun plej multaj servilaj atestiloj ne plenumas.

Tial retumila testo povas sukcesi dum la VPN malsukcesas, ĉar la retumilo uzis alian nomon ol la profilo. La sama disiĝo aperas kiam split-horizon DNS solvas la VPN-gastignomon al interna adreso dum la retumilo atingis publikan. Unue akordigu la profilon kun la dokumentita gastignomo, poste komparu atestilojn. Ĉio alia, kion vi ŝanĝas antaŭe, estas konjekto.

Kion la servila atestilo devas porti

Modernaj klientoj komparas kun la etendaĵo de alternativaj subjektaj nomoj, do la gastignomo devas aperi tie kiel DNS-enskribo. Nur komuna nomo ne sufiĉas por nunaj validigaj stakoj, kaj ĵokera signo kovras unu etikedon, ne ajnan subdomajnon, kiun vi elpensas. Tri atestiloj montras la limon: la ĝusta nomo kun la malĝusta celo validigas la identecon kaj poste malsukcesas la celan kontrolon, la ĝustaj nomo kaj celo kun mankanta intera atestilo malsukcesas la ĉenon, kaj nomo, kiu aperas nur en la komuna nomo, malsukcesas antaŭ ol iu el tiuj du gravas.

La atestilo ankaŭ bezonas la celon de servila aŭtentigo, la valoron de etendita ŝlosila uzo nomitan en la specifikaĵo SSTP de Microsoft, tio estas serverAuth kun objekta identigilo 1.3.6.1.5.5.7.3.1. Ŝlosila uzo kaj valida ĉeno kompletigas la aron. Atestilo, kiu ekzistas sur la servilo, estas eldonita por la ĝusta nomo sed nur por klienta aŭtentigo, ankoraŭ malsukcesas.

Kontrolu la ĉenon kaj la horloĝon antaŭ la akreditiloj

Tempaj kaj fido-malsukcesoj produktas la saman videblan rezulton kiel nommiskongruo, kaj ambaŭ estas pli malmultekoste diagnozeblaj ol pasvorta problemo. Kontrolu la horloĝon de la servilo kaj la horloĝon de la kliento, poste legu la ĉenon tiel, kiel la kliento vidas ĝin:

# 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

La unua komando presas la nomon, la validecan fenestron kaj la alternativajn nomojn, kun kiuj la kliento komparos. La dua raportas kontrolerarojn kun la ĉeno tiel prezentita, kaj ĝuste tie aperas mankanta intera atestilo. En Windows la demando al la temposervo diras al vi, ĉu la horloĝo estas korektata aŭ simple drivis.

Interna CA aldonas ankoraŭ unu kondiĉon: la kliento devas fidi tiun CA. Instalu la organizan radikon per sia aprobita dissenda kanalo, ne de paĝo proponanta anstataŭan atestilon, ĉar tiu decido estas la tuta fidmodelo en miniature.

Servila validigo kaj uzanta aŭtentigo estas sinsekvaj stadioj kun malsamaj malsukcesoj. Atestila eraro signifas, ke la kliento neniam fidis la servilon, dum rifuzita pasvorto signifas, ke ĝi fidis la servilon kaj la akreditiloj malĝustis. Malŝalti atestilan validigon por atingi la pasvortan inviton forigas la garantion anstataŭ ripari ĝin. Por pruvi, ke la cetero de la vojo funkcias, testu la saman gastignomon kaj pordon de kliento, kiu jam fidas la ĉenon, kaj lasu la deplojitan profilon trankvila.

Riparu la nomon aŭ la atestilon kaj retestu

Tri kondiĉoj decidas la riparon. Se la profila nomo malĝustas, korektu la profilon aŭ aldonu la mankantan nomon al la atestilo. Se la ĉeno nekompletas, instalu la interan atestilon sur la servilon. Se la celo malĝustas, reeldonu anstataŭ fliki ĉirkaŭ ĝi.

Post la ŝanĝo, rekonektu per la subtenata kliento kaj konfirmu, ke la ensaluta invito aperas, poste ke la tunelo leviĝas. Notu en la bileto la uzitan gastignomon, la eldoninton kaj la findaton. Tiu registro igas la sekvan renovigon planita tasko anstataŭ plia paneo, kaj ankaŭ montras al la sekva persono, kiu el la tri kondiĉoj estis efektive rompita.