HTTPS sa isang pribadong IP: pagkakakilanlan ng sertipiko o pangalan ng host?
Ang pribadong IP ay maaaring maging wastong pagkakakilanlang TLS kung sinasabi ito ng sertipiko. Pumili sa pagitan ng IP SAN at matatag na pangalan ng host, pagkatapos ay planuhin ang pagbabago ng address.
Ang iyong serbisyo sa https://10.60.0.25 ay maaaring may awtentikadong TLS kahit walang pangalan ng DNS. Ang address ang pagkakakilanlang dapat i-validate ng kliyente, at dapat itong ilarawan nang eksakto ng sertipiko. Ang desisyon ay kung sapat na matatag ang address na iyon upang maging pagkakakilanlan, o kung ang pangalan ng host ay mas madaling panatilihin. Sinasagot ng VPN ang maaabot; hindi nito sinasagot ito.
Ayusin ang pagkakakilanlan at pagtitiwala, at ang URL na nakabatay sa IP ay lehitimong disenyo.
Ano ang aktuwal na vine-validate ng kliyente
Inihahambing ng kliyente ang reference na pagkakakilanlan sa URL sa mga alternatibong pangalan ng paksa ng sertipiko. Para sa address ng IP, nangangahulugan ito ng entry na iPAddress na katumbas ng address. Ang magiliw na karaniwang pangalan ay hindi kapalit.
RFC 9525 naghihiwalay ng mga pagkakakilanlan ng address ng IP sa mga pangalan ng DNS at tinutukoy ang tuntunin ng pagtutugma. Ang paglalagay ng address sa label ng paksa lamang, o bilang entry na uri ng DNS, ay hindi nagbubunga ng pagtutugma. Kaya ang SAN ang field na dapat suriin kapag lumitaw ang babala.
Ang pagtitiwala ay ikalawang, malayang pagsusuri. Ang pagtutugma ng pangalan ay hindi nag-aayos ng hindi pinagkakatiwalaang kadena, nag-expire na sertipiko o sertipikong inilabas para sa ibang layunin.
Unang desisyon: sapat ba ang katatagan ng address upang maging pagkakakilanlan
Kung ang address ay nakatakda sa buong buhay ng pag-deploy, ang sertipikong IP SAN ay simple at tapat. Kung maaaring lumipat ang serbisyo, bawat paglipat ay nagiging pagpapalit ng sertipiko at coordinated na update ng kliyente.
Binabawasan ng matatag na pangalan ng host ang pagkakaugnay na iyon. Ginagamit ng mga kliyente ang pangalan, itinatapat ito ng aprubadong DNS sa kasalukuyang address, at ang pagbabago ng address ay hindi na pagbabago ng pagkakakilanlan. Kailangan pa ring i-renew ang sertipiko, ngunit hindi nagbabago ang URL.
Ang pinamamahalaang entry sa file ng hosts ay makapagbibigay ng mapping sa maliit na kapaligiran. Nagdaragdag ito ng responsibilidad sa pamamahagi; hindi nito pinapalitan ang pag-verify ng TLS.
Ikalawang desisyon: paano magtitiwala ang kliyente sa issuer
Para sa pribadong CA, ipamahagi ang anchor ng pagtitiwala sa mga nilalayong device sa pamamagitan ng aprubadong mekanismo. Huwag sanayin ang mga gumagamit na laktawan ang mga babala o mag-install ng sertipikong ibinibigay ng pahina ng pag-sign in. Kung gusto mo ng pampublikong pinagkakatiwalaang sertipiko, suriin ang kasalukuyang mga tuntunin ng issuer para sa mga pribadong address bago magplano. Karamihan sa mga pampublikong issuer ay hindi magva-validate ng pribadong IP bilang pampublikong pagkakakilanlan.
Suriin ang aktuwal na browser o application. Ang trust store at pag-uugali ng pag-validate nito ay mas mahalaga kaysa sa pangkalahatang dokumentasyon ng sertipiko ng operating system. Suriin ito sa aktuwal na device, hindi lamang sa console.
Maaaring hindi ang VPN gateway ang makina na nagpapatakbo ng web application, kaya huwag ipagpalagay na ang sertipiko ng tunnel ay may kaugnayan dito.
Planuhin ang pagbabago ng address bago ito mangyari
Kung ang 10.60.0.25 ay maging 10.60.0.40, hindi na ilarawan ng lumang sertipiko ang URL. Planuhin nang sabay ang pagpapalit at ang update ng kliyente, at huwag kailanman i-disable ang pag-verify habang lumilipat.
Piliin ang pagkakakilanlang itatype ng mga gumagamit o iko-configure ng mga application, pagkatapos ay ihanay ang pag-isyu, pagtitiwala, pag-deploy at pag-renew sa paligid nito. Ang maaabot na pahina na may tinanggihang babala ay hindi kaparehong resulta sa serbisyong vine-validate ng kliyente ang pagkakakilanlan.