I-renew ang sertipiko ng VPN nang hindi binabago ang pagkakakilanlan nito

Ang pag-renew ng sertipiko na nagbabago ng pagkakakilanlan ay hindi pag-renew, ito ay migrasyon na nakasuot ng maintenance ticket. Sinusuri ng kliyente ang isang pangalan, isang chain at kung minsan ang isang partikular na key, at ang tatlo ay maaaring magbago nang hindi nagbabago ang petsa ng pag-expire. Bago humiling ng kapalit, isulat kung ano talaga ang sinusuri ng kliyente: ang hostname o pagkakakilanlan ng peer, ang layunin ng sertipiko, ang patakaran sa key at ang chain ng issuer. Ang pag-renew ay rutina o koordinado depende sa kung alin sa mga ito ang binabago ng kapalit.

Tatlong kundisyon ang nagpapasya sa anyo ng pag-renew

Ang tatlong kundisyon ay kung may nagpi-pin sa dahon, kung nagbabago ang chain, at sino pa ang nagpapatunay ng pangalan. Sagutin ang mga ito mula sa panig ng kliyente at hindi mula sa kaginhawahan ng CA, dahil ang kliyente ang nabigo sa alas-tres ng madaling-araw.

Magsimula sa pagsusuri ng sertipikong mayroon ka. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName ay nagpi-print ng subject, issuer, validity window at mga pangalang talagang valid ang sertipiko. Ang huling field na iyon ang pinakamahalaga at pinakamadalas na ipinapalagay: ang isang kahilingan sa pag-renew na nag-iiwan ng SAN na pinagkakatiwalaan ng kliyente ay gumagawa ng sertipikong teknikal na valid ngunit mali sa paggana. Kopyahin ang listahan ng SAN mula sa lumang sertipiko papunta sa kahilingan sa halip na i-type itong muli mula sa memorya.

Kundisyon isa: may nagpi-pin ba sa dahon

Kung nagtitiwala ang mga kliyente sa isang pinapanatili na CA at pinapatunayan nila ang pangalan, ang pag-renew ng dahon na may bagong key ay hindi nakikita sa kanila. Kung may kliyenteng nagpi-pin sa sertipiko ng dahon, sa fingerprint nito o sa public key nito, ang kapalit ay isang koordinadong pagbabago na may matigas na paglipat, dahil hindi maipapatunay ng lumang pin ang bagong sertipiko.

Alamin kung aling kaso ang kinalalagyan mo bago umorder ng kahit ano. Ang pin na walang nagdokumento ay pin pa rin kapag ito ay nasira.

Kundisyon dalawa: ihambing ang mga pin at ang chain

Ginagawang masusuri ng mga fingerprint ang pin: openssl x509 -noout -fingerprint -sha256 -in server.crt sa luma at bagong sertipiko, at openssl x509 -noout -pubkey upang ihambing ang mga public key. Kung ang configuration ng kliyente, isang mobile profile o isang trust store ng appliance ay naglalaman ng alinman sa mga value, mayroon kang pin. Ang mga mobile VPN profile ay karaniwang taguan, dahil ang profile ay ipinamimigay nang isang beses at hindi na muling sinusuri.

Kung ang kapalit ay nagmumula sa parehong intermediate at mayroon na ang kliyente o makukuha nito, walang nagbabago sa panig ng tiwala. Ang bagong intermediate, ibang issuer o chain na inihatid sa maling pagkakasunod-sunod ay ginagawang pagbabago ng tiwala ang pag-renew, at ang kabiguan ay mukhang hindi kilalang issuer sa halip na isang sertipikong nag-expire.

Suriin ang chain na talagang ipinapadala ng server gamit ang openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts, at i-verify ito nang lokal gamit ang openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. Ang paggawa nito bago ang pagbabago ay nagbibigay sa iyo ng baseline na paghahambingan pagkatapos.

Kundisyon tatlo: sino pa ang nagpapatunay ng pangalan

Ang isang VPN concentrator, isang load balancer, isang monitoring probe, isang integrasyon ng RADIUS o SAML at isang mobile profile ay maaaring may kanya-kanyang kopya ng inaasahang pangalan o trust anchor. Ang pag-renew ang sandali kung kailan naghihiwalay ang mga kopyang iyon, dahil nagbabago ang sertipiko at hindi nagbabago ang mga kopya.

Ilista ang bawat consumer bago ang pagbabago at magpasya, para sa bawat isa, kung kailangan nito ng update. Ang kalimutan mo ang siyang tatawag sa iyo.

May bitag din sa oras. Suriin ang simula ng validity kasama ang pag-expire, dahil ang sertipikong inihanda para sa mamaya pang activation ay tinatanggihan kung maagang naka-install, at ang error ay mukhang problema sa orasan sa halip na problema sa paghahanda. Ang openssl x509 -noout -dates sa bagong file bago mo ito i-deploy ay isang tsek na dalawang segundo. Panatilihin din ang isang suportadong recovery path at ang known-good na configuration, upang ang pag-renew na mali ay maibalik sa pamamagitan ng pag-restore ng dating sertipiko at key.

Ilunsad, i-verify gamit ang bagong authentication, pagkatapos ay alisin sa serbisyo

Ang isang naitatag na tunnel ay sumasalamin sa pagpapatunay na nangyari nang ito ay itinayo, kaya maaari itong mukhang malusog habang bawat bagong koneksyon ay nabibigo. Subukan gamit ang bagong authentication gamit ang tunay na pangalan ng serbisyo na ginagamit ng mga kliyente.

Kumpletuhin ang tsek sa antas ng application na mahalaga sa user, at kumpirmahin ang paghahatid ng chain mula sa pananaw ng kliyente at hindi ng server. Huwag pigilan ang mga tsek sa pangalan o sertipiko upang manatiling tahimik ang transisyon; ginagawa nitong permanente ang pansamantalang problema sa compatibility.

Alisin sa serbisyo ang lipas na materyal pagkatapos lamang ma-verify ang deployment, at ituring ang kompromisong key bilang ganap na ibang kaso: ang pag-renew lamang ay walang binabawi, kaya ang apektadong pagkakakilanlan ay nangangailangan ng proseso ng pagbawi at pamamahala ng session ng deployment. RFC 5280 ang naglalarawan ng mga tuntunin ng sertipiko at pag-verify ng landas na nasa ilalim ng lahat ng ito. Panatilihing hiwalay ang rutinang pag-renew ng dahon sa pagpapalit ng CA, upang hindi hilingin sa mga kliyente na magtiwala sa bagong issuer nang walang dahilan.