Ano ang nangyayari kapag pinapalitan mo ang awtoridad ng sertipiko ng VPN

Ang pagpapalit ng awtoridad ng sertipiko ng VPN ay hindi pagpapalit ng file. Sa sandaling pumirma ang bagong CA sa una nitong sertipiko, bawat validator na tiwala pa rin sa luma lang ay kailangang magpasya, at ang mga host na hindi kailanman tumatanggap ng bagong anchor ay patuloy na tinatanggihan ang mabubuting kapares. Nakita ko itong bumagsak sa dalawang direksyon: natutunan ng gateway ang bagong CA at hindi ng mga kliyente, kaya nabigo ang mga bagong koneksyon, habang ang mga tunnel na nakaangat na ay nanatiling nakaangat at ginawang parang problema sa routing ang aberya. Narito ang nagbabago, sa ayos na lumilitaw ang mga pagkabigo.

Isang pagpapalit, dalawang hiwalay na pagbabago

Ang awtoridad ng sertipiko ay isang pangalan, isang pampublikong susi at ang pribadong susi na pumipirma. Hindi kailanman nagtitiwala ang mga validator sa «CA» sa abstrak na paraan. Nagtitiwala sila sa isang partikular na sertipiko na nasa imbakan ng tiwala na, at tinatanggap lang nila ang issuer kung ang kadena ng mga pirma ay umabot sa nakaimbak na kopyang iyon. Kaya binabago ng pagpapalit ng CA ang dalawang bagay na hiwalay na nabibigo: kung aling anchor ang tinatanggap at kung aling pagkakakilanlan ng kapares ang inilabas sa ilalim ng mga ito.

Karamihan sa mga deployment ng VPN ay nagva-validate sa dalawang direksyon. Pinatutunayan ng kliyente ang sertipiko ng gateway, at ng gateway ang sa kliyente. Ang isang pag-ikot na nagre-refresh lang ng bundle ng kliyente ay nag-iiwan sa server na tinatanggihan ang bawat kliyenteng nagpapakita pa rin ng pagkakakilanlan mula sa lumang CA, at ang kabaligtaran ay kasingkaraniwan. Unahin ang pag-iimbentaryo ng mga punto ng pagpapatupad: mga imbakan ng tiwala ng kliyente, ang ca na file ng gateway, anumang proxy na nagtatapos ng TLS sa harap nito, at ang probe na sumisiyasat sa endpoint mula sa labas.

Ano ang sinisiyasat ng validator, sa ayos

Ang validation ng landas ay umaakyat mula sa sertipiko ng kapares sa pamamagitan ng anumang intermediate hanggang maabot ang pinagkakatiwalaang anchor. Sa bawat hakbang, bineberipika nito ang pirma, sinusuri na ang bawat sertipiko ay nasa loob ng validity window nito, at kinukumpirma na pinapayagan ng mga pangunahing paghihigpit at paggamit ng susi ang issuer na pumirma. Pagkatapos lang tinitingnan ng aplikasyon ang leaf certificate: dapat masaklaw ng mga alternatibong pangalan ng subject ang pangalang na-dial, at dapat payagan ng extended key usage ang authentication ng server o kliyente.

Para ulitin ang paglalakbay na iyon offline, ituro ang -CAfile sa eksaktong bundle na ide-deploy mo, hindi sa imbakan ng system. Kung hindi, sinusuri mo ang host, hindi ang pagbabago:

openssl verify -CAfile new-ca.crt gateway.crt
openssl verify -CAfile new-ca.crt -untrusted intermediate.crt client.crt
openssl x509 -in gateway.crt -noout -subject -issuer -dates
openssl s_client -connect gw.example.net:443 -CAfile new-ca.crt

Gumagana lang ang utos na iyon laban sa payak na TLS listener tulad ng HTTPS admin page ng gateway; ang control channel ng OpenVPN ay nauuna sa TLS, kaya hindi masisiyasat ng s_client ang handshake ng tunnel.

Ang mga tuntunin sa pagbuo ng landas sa likod ng mga error na iyon ay nasa RFC 5280 seksyon 6. Ipinapaliwanag nila ang mga pagkabigong mukhang arbitraryo kung hindi: isang nag-expire na intermediate na walang naalala, isang sertipikong pinagbabawal ng paggamit ng susi ang pagpirma, o isang paghihigpit sa pangalan na nagbubukod sa host na sinusuri mo.

Bakit patuloy na gumagana ang lumang tunnel

Parehong pinapanatiling buhay ng TLS at OpenVPN ang naitatag na session pagkatapos ng handshake. Walang nagre-validate ng sertipiko ng kapares kada packet, kaya ang kliyenteng kumonekta bago ang pagbabago ay patuloy na nagpapadala ng trapiko hanggang makipagnegosasyon muli, makakonekta muli, o mahulog ang tunnel. Ang agwat na ito ang dahilan kung bakit ang pagpapalit ng CA ay mukhang maayos nang isang oras at pagkatapos ay nabibigo sa pinakamasamang sandali: nagigising ang laptop mula sa pagtulog, nag-expire ang NAT mapping, nag-restart ang gateway.

Mas pinahaba pa ng session resumption ang ilusyon. Ang TLS session ticket ay nagpapahintulot sa kliyenteng bumalik nang hindi ipinapadala muli ang mga sertipiko, at nilalaktawan ng resumption ang path validation dahil nagawa na ito ng unang handshake. Kaya ang tapat na pagsubok ay isang buong handshake sa bagong proseso. I-restart ang kliyente sa halip na ikonekta muli ang tunnel, at sa test profile isaalang-alang ang pag-disable ng mga ticket upang hindi maitago ng resumption path ang sirang kadena.

Panatilihing hiwalay ang layer ng static key dito. Ang tls-auth ay nagdadagdag ng HMAC sa control channel, ini-encrypt at pinatutunayan ito ng tls-crypt, at wala sa dalawa ang nagdadala ng materyal ng sertipiko, kaya ang pag-ikot ng alinman sa mga ito ay hiwalay na pagbabago na may sariling failure mode. Ang mga deployment na pinaghahalo ang dalawa ay nauuwi sa kliyenteng maayos ang static key, luma na ang sertipiko, at hindi binabanggit ng mensahe ng error ang alinman.

Ang bitag ng muling paggamit ng pangalan ng subject

Nakakatuksiyon na muling gamitin ang natatanging pangalan ng hinalinhan upang walang kailangang magbago sa ibaba. Pinapanatili nitong matatag ang linya ng issuer sa interface at sinisira ang nag-iisang senyales na kailangan mo. Dalawang sertipikong may magkatulad na subject at magkaibang susi ay hindi makikilala sa pangalan, kaya ang bundle na may dalawang anchor ay nagbibigay sa validator ng dalawang kandidato at walang tuntunin sa pagpili.

Maaaring piliin ng pagbuo ng landas ang mali, mag-ulat ng «hindi makuha ang sertipiko ng lokal na issuer» habang naroon ang tamang anchor, o magtagumpay sa isang host at mabigo sa isa pang may parehong bundle, dahil magkaiba ang ayos ng mga kandidato. Kung kailangang muling gamitin ang pangalan, itago ang dalawang anchor sa magkahiwalay na file habang nagbabago at i-load ang mga ito nang tahasan, at pagsamahin lamang kapag inilahad na ng bawat kapares ang bagong issuer. Kung hindi, bigyan ang kapalit ng natatanging karaniwang pangalan — sapat na ang hulaping henerasyon o petsa — upang masabi ng mga log at teksto ng error kung sa ilalim ng aling awtoridad inilabas ang bumabagsak na kapares.

Isang pag-ikot na hindi nagpapatumba sa network

Para sa planadong pagpapalit, tanggapin ang dalawang anchor sa loob ng limitadong panahon sa halip na lumipat sa isang hakbang. Ilabas ang bagong CA at ang mga intermediate nito, ilagay ang bagong anchor sa bundle ng bawat validator sa tabi ng luma, at pagkatapos lang magsimulang maglabas ng sertipiko ng kapares mula rito. Ang mga kapares na may lumang pagkakakilanlan ay nagva-validate laban sa lumang anchor; gumagana ang mga bago laban sa bago.

Kapag ginawa sa ayos na iyon, bawat hakbang ay mababalik. Ang pagkabigong iniiwasan mo ay ang sabay na paglipat, kung saan ang kliyenteng nakaligtaan ang update ng bundle ay nakasalubong ng gateway na na-retire na ang lumang anchor, namamatay ang handshake, at walang log na nagsasabi kung aling panig ang luma.

Mag-retiro sa kabaligtaran. Muling ilabas ang bawat pagkakakilanlang kailangang manatili, kumpirmahin na inilalahad ng bawat isa ang bagong kadena, pagkatapos ay alisin ang lumang anchor sa mga bundle. Alisin sa serbisyo ang pribadong susi ng lumang CA, dahil ang issuer na makakapirma pa ay nangangahulugang hindi pa tapos ang pag-ikot. Itago ang mga sertipiko at talaan ng paglabas para sa audit. Ang nawalang issuer ay naibabalik sa parehong tiwala; ang pagkakalantad ay nangangailangan ng bagong pagkakakilanlan at walang pagbabalik sa lumang anchor.

I-verify ang resulta, hindi ang listahan ng file

Kaunti lang ang pinatutunayan ng trust file sa inaasahang direktoryo. Maaaring magbasa ang aplikasyon ng ibang landas, ibang format o kopya sa loob ng package na pinapalitan ng upgrade. Siyasatin ang pag-uugali sa dalawang dulo, hindi ang pag-iral ng file.

Kumpirmahin na nagtagumpay ang bagong koneksyon na may bagong pagkakakilanlan, pagkatapos ay kumpirmahin na tinatanggihan ang pagkakakilanlang inilabas ng retired CA. Ang ikalawang pagsubok na iyon ang nilalaktawan ng mga tao, at ang tanging nagpapakita na hindi na nagbibigay ng access ang lumang awtoridad. Kung ang deployment ay umaasa sa CRL o OCSP, siyasatin na nareresolba ang mga distribution point sa mga bagong sertipiko at na naaabot ng mga kapares na nagtatanong ang responder.

Tapusin sa kliyenteng hindi kailanman kumonekta: burahin ang estado ng profile nito, kumonekta at basahin ang naayos na kadena. Ang kapares na muling nagpapatuloy ng naka-cache na session ay masayang mag-uulat na nagtagumpay ang migrasyon gayong wala itong na-validate.