Hindi tugma ang sertipiko ng SSTP: ang pangalang dapat ipakita ng iyong server

SSTP tinatanggap ng kliyente ng SSTP ang server pagkatapos lamang ng matagumpay na balidasyon ng TLS, at inihahambing ng pagsusuring iyon ang isang pangalan, isang kadena at isang layunin. Ang pangalan ay nagmumula sa profile ng koneksyon, hindi sa address na nagkataon lamang na maaari mong i-ping. Kapag ang isa sa tatlo ay hindi tugma, nag-uulat ang kliyente ng problema sa sertipiko at hindi kailanman nakarating sa prompt ng pag-login.

Ang pangalan sa profile ang nagtatakda ng susuriin

Pinapatakbo ng SSTP ang TLS sa ibabaw ng TCP 443, kaya kumikilos ang kliyente tulad ng anumang iba pang kliyente ng TLS: kinukuha nito ang hostname mula sa profile, hinihiling ang pangalang iyon at inihahambing ang sertipiko dito. Kung magta-type ka ng address ng IP sa profile, ang paghahambing ay magiging paghahambing ng mga address ng IP, na hindi natutugunan ng karamihan sa mga sertipiko ng server.

Kaya maaaring magtagumpay ang pagsubok sa browser habang nabigo ang VPN, dahil gumamit ang browser ng ibang pangalan kaysa sa profile. Ang parehong paghahati ay lumilitaw kapag niresolba ng DNS split-horizon ang hostname ng VPN sa isang panloob na address habang nakarating ang browser sa isang pampublikong address. Ihanay muna ang profile sa dokumentadong hostname, pagkatapos ihambing ang mga sertipiko. Anumang iba pang babaguhin mo bago iyon ay haka-haka.

Ano ang dapat dalhin ng sertipiko ng server

Inihahambing ng mga makabagong kliyente ang extension ng mga alternatibong pangalan ng paksa, kaya dapat naroon ang hostname bilang entry ng DNS. Ang pangalang karaniwan lamang ay hindi sapat para sa mga stack ng balidasyon ngayon, at ang wildcard ay sumasaklaw sa isang label, hindi sa anumang subdomain na imbentuhin mo. Tatlong sertipiko ang nagpapakita ng hangganan: ang tamang pangalan na may maling layunin ay nagpapatunay ng pagkakakilanlan at pagkatapos ay nabigo sa pagsusuri ng layunin, ang tamang pangalan at layunin na may kulang na intermediate ay nabigo sa kadena, at ang pangalan na lumilitaw lamang sa karaniwang pangalan ay nabigo bago maging mahalaga ang alinman sa dalawang iyon.

Kailangan din ng sertipiko ang layunin ng pagpapatunay ng server, ang halaga ng pinahabang paggamit ng susi na binanggit sa espesipikasyon ng SSTP ng Microsoft, ibig sabihin ang serverAuth na may identifier ng object na 1.3.6.1.5.5.7.3.1. Kinukumpleto ng paggamit ng susi at wastong kadena ang set. Ang sertipikong umiiral sa server, na inisyu para sa tamang pangalan ngunit para lamang sa pagpapatunay ng kliyente, ay nabigo pa rin.

Suriin ang kadena at orasan bago ang mga kredensyal

Mga kabiguan ng oras at tiwala ay nagbibigay ng parehong nakikitang resulta gaya ng hindi pagtugma ng pangalan, at pareho silang mas mura pang-diagnose kaysa sa problema sa password. Suriin ang orasan ng server at ang orasan ng kliyente, pagkatapos basahin ang kadena ayon sa nakikita ng kliyente:

# 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

Ang unang utos ay nagpi-print ng pangalan, window ng bisa at ang mga alternatibong pangalan na ihahambing ng kliyente. Ang pangalawa ay nag-uulat ng mga error sa pagpapatunay kasama ang kadenang iniharap, at doon lumilitaw ang kulang na intermediate. Sa Windows, sinasabi ng query ng serbisyo ng oras kung ang orasan ay itinatama o umiwas lamang.

Nagdaragdag ang panloob na CA ng isa pang kundisyon: dapat magtiwala ang kliyente sa CA na iyon. I-install ang root ng organisasyon sa pamamagitan ng aprubadong channel ng distribusyon nito, hindi mula sa pahinang nag-aalok ng kapalit na sertipiko, dahil ang desisyong iyon ang buong modelo ng tiwala sa maliit na anyo.

Ang balidasyon ng server at pagpapatunay ng user ay magkakasunod na yugto na may magkaibang kabiguan. Ang error sa sertipiko ay nangangahulugang hindi kailanman nagtiwala ang kliyente sa server, samantalang ang tinanggihang password ay nangangahulugang nagtiwala ito sa server at mali ang mga kredensyal. Ang pag-off ng balidasyon ng sertipiko upang maabot ang prompt ng password ay nag-aalis ng garantiya sa halip na ayusin ito. Upang patunayan na gumagana ang natitirang landas, subukan ang parehong hostname at port mula sa kliyenteng nagtitiwala na sa kadena, at iwanan ang naka-deploy na profile kung ano ito.

Ayusin ang pangalan o sertipiko at subukan muli

Tatlong kundisyon ang nagtatakda ng pag-aayos. Kung mali ang pangalan sa profile, ayusin ang profile o idagdag ang kulang na pangalan sa sertipiko. Kung hindi kumpleto ang kadena, i-install ang intermediate sa server. Kung mali ang layunin, muling mag-isyu sa halip na tapalan ito sa paligid.

Pagkatapos ng pagbabago, muling kumonekta gamit ang sinusuportahang kliyente at kumpirmahin na lumilitaw ang prompt ng pag-login, at pagkatapos ay tumataas ang tunnel. Itala sa ticket ang hostname na ginamit, ang nag-isyu at ang petsa ng pag-expire. Ang rekord na iyon ang gumagawa sa susunod na pag-renew na isang naka-iskedyul na gawain sa halip na isa pang pagkaantala, at ipinapakita rin nito sa susunod na tao kung alin sa tatlong kundisyon ang tunay na sira.