Ang iyong VPN certificate ay mag-eexpire ngayon: ano ang tunay na humihinto

Tumutunog ang alerto sa pag-expire, dumadaan pa rin ang tunnel sa trapiko, at walang nagkakasundo kung mahalaga ang petsa. Mahalaga, ngunit hindi laging sa sandaling nakalimbag sa certificate. Ang nag-expire na certificate ay humihinto sa mga bagong pagpapatunay, at hinihinto rin ang mga muling pagpapatunay na ginagawa ng ilang implementasyon sa loob ng mahabang session. Kung mamamatay ang iyong umiiral na tunnel sa hatinggabi ay depende sa protocol, kliyente at mga setting ng muling pakikipag-usap ng server. Planuhin ang pag-renew bago ang petsa at i-verify ito sa bagong pag-login sa halip na sa session na nakabukas na.

Alamin kung aling certificate ang tunay na nag-eexpire

Ang isang deployment ay may server leaf certificate, mga kredensyal ng kliyente, isa o higit pang intermediate na certificate at isang trust anchor, at hindi sila sabay na nag-eexpire. Basahin ang certificate na pinangalanan sa error at ang chain na kasama nito, hindi ang unang file sa direktoryo ng profile. Ang server leaf na malinis na nagre-renew ay maaari pa ring mabigo kung ang intermediate sa itaas nito ay nag-expire na. Isulat ang subject, issuer, not-after at lokasyon ng deployment ng bawat file bago baguhin ang anuman.

Ang trust anchor ay karaniwang ang pinakamatagal na object at ang pinakamaliit na posibleng dahilan.

Bakit ang buhay na session ay maaaring lumampas sa petsa

Nagaganap ang pagpapatunay sa pagtatatag ng koneksyon, at ang ilang protocol ay muling nagsusuri ng pagkakakilanlan mamaya. Ang OpenVPN ay muling nakikipag-usap sa data channel sa isang timer, kaya ang muling pakikipag-usap na nagpapakita ng nag-expire na certificate ay nabibigo kahit na ang tunnel ay nakaupo nang ilang oras. Ang mga implementasyong hindi kailanman muling nagpapatunay ay maaaring magdala ng naitatag na session lampas sa petsa ng pag-expire, at kaya nga ang «gumagana pa rin» ay hindi ebidensya. Wala sa dalawang pag-uugali ang planuhin.

Ituring ang petsa bilang huling araw para sa mga bagong pag-login, at ang haba ng buhay ng session bilang hiram na oras.

Suriin ang orasan bago sisihin ang certificate

Ang validity ay sinusuri laban sa lokal na orasan, kaya ang device na may maling oras ay nag-uulat ng kabiguan sa validity para sa certificate na ganap na napapanahon. Suriin ang kliyente, server at anumang appliance sa landas.

Ang orasang nagre-reset sa boot ay nagpapaliwanag ng mga kabiguang lumilitaw lamang pagkatapos ng pagkawala ng kuryente.

I-renew sa pamamagitan ng awtoridad na naglabas nito

Panatilihin ang pagkakakilanlan, ang nilalayong layunin at isang tugmang key configuration. Kung ang pag-renew ay nagpapakilala ng bagong issuer o naka-pin na certificate, kailangan ng mga kliyente ng coordinated na pag-update ng tiwala sa halip na pagpapalit ng file sa server. Protektahan ang mga private key sa panahon ng paglabas at pamamahagi, dahil ang na-renew na certificate ay hindi nagpapawalang-bisa ng nakompromisong lumang key. Ang pag-reset ng password ay hindi pag-renew, anuman ang sabihin ng ticket.

Ilathala nang buo ang bagong chain, dahil ang leaf na walang intermediate nito ay kalahating pag-renew na gumagana lamang sa mga makinang naka-cache na ito.

Patunayan ito sa bagong pag-login, panatilihin ang paraan ng pag-urong

Pagkatapos ng deployment, magtatag ng bagong pinapayagang koneksyon mula sa isang representatibong kliyente at subukan ang aktwal na aplikasyon. Suriin na ang chain ay naihahatid ayon sa inaasahan ng mga kliyente at na ang anumang impormasyon sa pagpapawalang-bisa ay maabot. Panatilihin ang pag-urong na hindi umaasa sa pagtitiwala sa nag-expire na materyal, upang makabalik sa dating estado nang hindi pinapahina ang verification. Alisin ang mga lumang file pagkatapos lamang ma-verify ang kapalit.

Ang mga umiiral na session ay maaari pa ring sumasalamin sa dating estado, kaya wala silang pinapatunayan sa alinmang direksyon.

Ang pagkakasunod-sunod na ginagamit ko sa araw na iyon

Kumpirmahin ang nag-eexpire na object at ang chain nito, pagkatapos ay kumpirmahin ang mga orasan:

• Aling certificate ang nag-eexpire, at sa aling chain ito kabilang.
• Kung ang bawat intermediate ay naka-deploy at nailathala.
• Nagkakasundo ang mga orasan ng kliyente at server sa loob ng makatwirang margin.
• Nagtagumpay ang bagong pag-login mula sa representatibong kliyente.
• Maabot ang impormasyon sa pagpapawalang-bisa.
• May pag-urong na hindi pinapahina ang verification.

Pagkatapos ay i-renew, i-deploy ang buong chain, subukan sa bagong pag-login, at pagkatapos lamang maglinis. Ang mga panahon ng validity at ang mga tuntunin sa pagsusuri sa kanila ay tinukoy sa RFC 5280, at ang petsa ay hindi sorpresa kung binabantayan ng iyong monitoring ang object na tunay na nag-eexpire.