Gumagamit ang SSTP at IKEv2 ng magkaibang kontrol ng sertipiko ng RRAS

Kung papalitan mo ang «sertipiko ng VPN», maaaring mabago mo ang maling serbisyo. Nagtatago ang RRAS ng hindi bababa sa tatlong kontrol ng sertipiko, bawat isa ay kabilang sa magkaibang protocol at iba't ibang tungkulin ng koneksyon. Ang pagpangalan muna sa protocol ay ginagawang isang baligtaring pagbabago ng binding ang isang delikadong hula. Ang lahat sa ibaba ay nakasalalay sa nag-iisang pangungusap na iyon.

Pangalanan ang protocol bago ang sertipiko

Ang tagapakinig ng SSTP ay nagpapakita ng sertipiko ng TLS sa isang kliyenteng kumikilos tulad ng HTTPS. Ang papasok na koneksyong IKEv2 site-to-site ay nagpapahayag ng pagkakakilanlan ng server at nagpapatunay ng mga sertipiko ng kapares laban sa pinagkakatiwalaang ugat. Ang depinisyon ng site-to-site bawat interface ay may sariling pagkakakilanlan ng makina.

Tatlong kontrol ang mga ito na may tatlong saklaw. Ang paghahalo sa kanila ay lumilikha ng pagbabagong tila gumagana sa isang protocol at walang epekto sa isa, na mas masahol pa kaysa sa malinaw na pagkabigo. Isulat kung aling protocol ang nabigo, aling panig ang nagpakita ng sertipiko, at aling panig ang tumanggi dito bago mo hawakan ang anuman.

Ang SSTP ay isang binding ng HTTPS

Sa mga suportadong deployment ng Remote Access, ang Set-RemoteAccess ay naglalantad ng parameter na SslCertificate na ginagamit para sa konektibidad ng SSTP at para sa papel na DirectAccess na may kaugnayan sa HTTPS.

Ang saklaw ng pagpapatunay at deployment nito ay sumusunod sa configuration ng Remote Access, kaya ang isang pagbabago ng binding ay maaaring umabot sa higit sa isang koneksyon o node. Sa deployment na may load balancing, kasama sa saklaw na iyon ang bawat node na sakop ng configuration. Ang pagbabago ng isang node at pagsubok ng isang kliyente ay nag-iiwan sa iba na nagpapakita pa rin ng lumang dahon, at ito ang uri ng kalahating pagbabago na nakakaligtas sa isang maintenance window.

Bago ang update, i-verify ang inaasahang pangalan ng serbisyo, ang chain, ang validity, ang nilalayong paggamit, at ang pagkakaroon ng private key. Dapat tumugma ang sertipiko sa pangalang susuriin ng kliyente, at ang label ng adapter ay hindi ang pangalang iyon.

May sariling parameter ang papasok na IKEv2

Ang Set-VpnAuthProtocol ay nagko-configure ng papasok na authentication ng IKEv2 site-to-site, at ang CertificateAdvertised ay nagbibigay ng sertipiko kapag ginagamit ito ng tunnel authentication mode. Hindi ito pangkalahatang utos para pumili ng anumang sertipiko ng server sa host.

Paghiwalayin ang dalawang bagay: ang dahon na ipinapakita ng server bilang sariling pagkakakilanlan, at ang ugat na ginagamit nito para tanggapin ang mga sertipiko ng kapares. Ang pagpili kung aling issuer ang pagtitiwalaan mo ay walang sinasabi tungkol sa kung aling dahon ang ipinapakita ng server.

Ang pagkakakilanlan ng isang indibidwal na interface ng site-to-site ay itinatakda sa pamamagitan ng Set-VpnS2SInterface. Hindi ito awtomatikong sertipiko ng SSTP, kahit na pareho silang nasa parehong tindahan sa parehong makina.

Siyasatin muna ang kandidato

Ang nakatutok na pagtingin sa tindahan ng lokal na makina ay nagpapakita ng pampublikong metadata nang hindi nag-e-export ng anumang pribado:

Get-ChildItem Cert:\LocalMachine\My |
    Select-Object Thumbprint, Subject, HasPrivateKey, NotAfter

Ang listahang iyon ay isang panimulang punto, hindi isang pagsubok ng pagiging angkop. Siyasatin ang mga entry ng SAN, ang mga pinalawak na paggamit ng key, ang chain, at ang access ng service account sa private key para sa protocol na kinokonfigure mo.

Ang sertipikong naka-install para sa isang walang kaugnayang pagkakakilanlan ng cloud client ay hindi angkop dahil lamang lumilitaw ito sa parehong tindahan. Ang visibility ay hindi pagiging angkop, at ang fingerprint sa isang screenshot ay walang pinapatunayan tungkol sa kung mababasa ng service account ang key. Suriin nang tahasan ang access na iyon, dahil ang kulang na pahintulot sa key ay nabibigo lamang kapag nag-restart ang serbisyo at sinubukang gamitin ang sertipiko.

Itala ang kasalukuyang binding at kumpirmahin na maaabot mo pa rin ang host sa ibang paraan bago mo ito baguhin. Ang landas ng pagbawi ay bahagi ng pagbabago, hindi ng insidenteng susunod.

Ang pag-renew ay hindi pag-activate

Ang muling pag-isyu ng sertipiko ay ibang aksyon kaysa sa pagpili nito para sa tumatakbong serbisyo. Ang bagong dahon ay maaaring mapanatili ang nilalayong pagkakakilanlan ng DNS at magdala pa rin ng ibang fingerprint, kaya walang tumuturo dito hanggang ma-update ang binding. Binabago ng pag-renew ang bagay; binabago ng pag-activate ang sanggunian dito. Ang paghahalo sa dalawa ay ang dahilan kung bakit ang tamang na-renew na sertipiko ay maaaring manatiling hindi ginagamit nang ilang linggo.

Ilapat ang suportadong pagbabago sa angkop na window, kasama ang anumang dokumentadong restart, pagkatapos ay siyasatin ang sertipiko mula sa isang bagong koneksyon ng nilalayong protocol. Ang naka-cache na session ng kliyente ay maaaring magpakita pa rin ng lumang dahon at gawing parang sira ang tamang pagbabago.

Iretiro ang dating sertipiko sa pamamagitan ng normal na proseso lamang pagkatapos pumasa ang pagsusuring iyon. Ang Sanggunian ng Set-RemoteAccess ay nagdodokumento ng saklaw ng parameter ng SSL, kasama ang epekto nito sa mga deployment na may load balancing, at ito ang bahaging dapat basahin bago ang isang pagbabago ng binding.