Sertipiko ng VPN hindi pa wasto: tatlong dahilan, isang pagkakasunod-sunod ng pagsusuri
Ang hindi pa wasto ay nangangahulugang nahuhuli ang orasan ng device, talagang nagsisimula nang mas huli ang window, o hindi pa bumubukas ang intermediate na sertipiko. Suriin ang mga ito sa ganoong pagkakasunod-sunod.
Binubuksan mo ang kliyente, pinipili ang profile na ginagamit mo nang ilang buwan, at humihinto ito sa "certificate is not yet valid". Walang nagbago sa iyong pag-sign in, at malamang maayos ang trust store: ang sertipikong iniharap sa handshake ay may window ng validity na nagsisimula nang mas huli kaysa sa sandaling ginagamit ng verifier. Tatlong magkaibang sitwasyon ang gumagawa ng eksaktong mensaheng iyon, at nangangailangan ng magkaibang aksyon. Sinasabi ng pagkakasunod-sunod sa ibaba kung alin ang mayroon ka bago mo hawakan ang orasan o file ng sertipiko.
Alin sa tatlong dahilan ang nakikita mo
Ang unang dahilan ay lokal: ang device na gumagawa ng pagsusuri ay may oras na mas maaga kaysa petsa ng pagsisimula ng sertipiko. Nakikita ito sa hardware na patay ang bateryang CMOS, sa mga virtual machine na naibalik mula sa lumang snapshot, sa mga device na naiwan nang sapat na katagal na patay upang mawala ang oras, at sa mga network kung saan naka-block ang palabas na NTP at walang nakapansin. Ang sertipiko ay maaaring ganap na wasto at nabibigo pa rin sa ganitong paraan.
Ang ikalawang dahilan ay pag-aari ng issuer, dahil talagang nagsisimula ang sertipiko sa hinaharap: inisyu nang maaga, ginawa nang may tahasang oras ng pagsisimula, o pinirmahan bilang bahagi ng hakbang ng activation na hindi pa tumatakbo. Ang ikatlong dahilan ang pinakanagsasayang ng oras, dahil ang dahon ay kasalukuyan habang ang isa pang sertipiko sa iniharap na chain ay hindi, kaya pinangalanan ng error ang materyal na hindi mo kailanman na-install.
Isang tanong ang naghihiwalay sa kanila. Sinusundan ba ng pagkabigo ang device o ang serbisyo? Dalawang makina sa parehong network na magkaibang kumikilos ay tumutukoy sa mga orasan. Lahat ng kliyenteng nabibigo sa parehong paraan ay tumutukoy sa window ng sertipiko at sa chain sa likod nito.
Basahin ang window mula sa sertipikong aktwal na iniharap
Huwag siyasatin ang PEM file na natira mula sa naunang deployment; hingin sa serbisyo ang chain na ipinapadala nito ngayon. Ini-print ng openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts ang bawat sertipiko sa chain. I-save ang block na kailangan mo at patakbuhin ang openssl x509 -noout -subject -issuer -dates; ang huli ay nagpi-print ng notBefore at notAfter, at ang dalawang halagang iyon ang nagpapasya. Sa Windows, ang dialog ng sertipiko para sa koneksyon at ang certutil -dump sa na-export na file ay nagpapakita ng parehong mga field.
Basahin ang dalawang dulo ng window, hindi lamang ang simula. Ang sertipikong bumubukas sa dalawang oras at ang isang nagsasara sa dalawang oras ay nabibigo nang may magkaibang mensahe at nagsasangkot ng magkaibang team. Itala kung aling sertipiko ang pinangalanan ng error — dahon, intermediate o root — dahil iyon ang nagpapasya kung may maaayos pa sa panig ng kliyente.
Maaari mo ring subukan ang window nang hindi ito hinihintay. Tumatanggap ang verification ng tahasang oras: sinusuri ng openssl verify -attime 1793600000 -CAfile ca.pem -untrusted intermediate.pem leaf.pem ang chain sa timestamp na iyon. Patakbuhin ito sa kasalukuyang oras upang muling gawin ang pagkabigo, pagkatapos sa oras ng pagsisimula ng sertipiko upang kumpirmahin na ang parehong chain ay pumasa kapag bumukas ang window. Ang RFC 5280 ay tumutukoy sa field ng validity at sa tuntuning hindi dapat gamitin ang sertipiko sa labas nito, at iyon mismo ang tuntuning ipinatupad ng iyong kliyente.
Ang orasan mo, o ang kanila
Ihambing ang orasan ng device sa pagsisimula ng sertipiko sa UTC, mula sa pinagkakatiwalaan mong pinagmulan. Ibinibigay ng date -u ang sandali, at ang timedatectl status sa host ng systemd ay nag-uulat din kung naka-sync ang orasan. Sa Windows, ipinapakita ng w32tm /query /status ang kasalukuyang pinagmulan at ang huling matagumpay na sync. Ang timezone na ipinapakita sa tray ay pagpipilian sa pagpapakita, hindi maling orasan; inihahambing ng verifier ang mga sandali sa UTC.
| What you see | Most likely reading | Next step |
|---|---|---|
| Clock behind, one device affected | Local time fault | Resync time, keep validation on, retest |
| Clock correct, window opens soon | Certificate staged early | Wait for the window or follow the cutover plan |
| Clock correct, intermediate not yet valid | Chain material mismatch | Operator replaces the intermediate |
| Some peers pass, others do not | Inconsistent nodes | Record each peer's chain before changing anything |
Kung nahuhuli ang orasan, mag-sync muli at subukan muli bago baguhin ang anumang materyal ng sertipiko. Ang device na mali ng ilang minuto o oras ay tinatanggihan ang bawat kamakailang inisyung sertipiko na makasalubong nito, hindi lamang isang serbisyo, kaya ang paliwanag na isang serbisyo lamang ay karaniwang mali. Kung tama at naka-sync ang orasan, tigilan ang pagtingin sa device: pag-aari ng issuer ang window, at walang lokal na setting ang dapat ayusin upang ito ay pumasa.
Ang talahanayang iyon ang buong desisyon. Ang ilipat ang orasan sa inaasahan ng sertipiko ay hindi pag-aayos, at ang patayin ang mga pagsusuri ng oras ay hindi rin, dahil parehong itinatago ang kondisyong gumawa ng error.
Bakit nabibigo ang chain habang mukhang maayos ang dahon
Ang mga na-renew na dahon at kapalit na intermediate na sertipiko ay karaniwang ipinapadala nang sama-sama, at hindi sila laging dumarating sa parehong sandali. Maaaring magpadala ang serbisyo ng bagong dahon na pinirmahan ng intermediate na ang sariling window ay nagsisimula nang mas huli, o patuloy na maghatid ng mas lumang intermediate sa ilalim ng bagong dahon. Sa alinmang paraan, nabibigo ang chain habang ang mga petsa ng dahon mismo ay mukhang makatwiran.
Ang mga endpoint na may load balancing ay ginagawang hindi pare-pareho ang sirang ito. Kung nagtagumpay ang pagtatangkang muli, o gumagana ang isang network habang ang isa ay hindi, itala kung aling peer ang sumagot at kung aling chain ang ipinadala nito bago baguhin ang mga setting. Ini-print ng openssl s_client ang konektadong address, kaya ang ilang pagtatangka ay nagbubunyag kung ang bawat node ay naghahatid ng parehong chain.
Mga landas ng pag-aayos na nagpapanatili ng verification
Ang problema sa orasan ay inaayos sa device habang naka-on ang verification. Ang problema sa sertipiko ay inaayos ng operator gamit ang materyal na inisyu para sa window na kasama na ang ngayon. Walang setting ng kliyente ang gumagawang wasto ang sertipikong hindi pa wasto; ang mga flag na lumalampas sa mga pagsusuri ng oras ay umiiral upang kumpirmahin ang diagnosis, hindi upang ilabas sa production.
Kapag ang sertipiko ay inihanda para sa planadong activation, sundin ang plano ng paglipat. I-install ito kapag bumukas ang window nito, o gamitin ang overlap procedure na dokumentado ng provider, sa halip na i-install ito nang maaga at turuan ang mga user na i-click ang mga babala. Ang mga babalang natututunan ng mga tao na huwag pansinin ay mas mahal kaysa sa maikling pagkaantala.
Sa huli, subukan muli sa paraang nangyari ang pagkabigo: bagong session, parehong kliyente, ang resource na talagang kailangan mo. Maaaring i-cache ng mga TLS library ang na-verify na chain sa buong buhay ng koneksyon, at ang resumed na session ay hindi laging muling sinusuri ito, kaya ang lumang session ay maaaring patuloy na mabigo pagkatapos ng pag-aayos o patuloy na gumana pagkatapos ng regression. Ang file na bumubukas sa viewer ay nagpapatunay lamang na mababasa ang file; ang natapos na handshake ay nagpapatunay na nagva-validate ang chain.
Bago isara ang ticket, kumpirmahin ang apat na bagay: ang UTC time at estado ng sync ng nabigong device, ang notBefore at notAfter ng bawat sertipiko sa iniharap na chain, ang parehong chain mula sa ikalawang kliyente, at ang pangalang ibinibigay ng error sa sertipiko. Kung tama ang orasan at hindi bumukas ang window, ang natitira ay trabaho ng operator, at ang tamang hakbang sa iyong panig ay hintayin ang window sa halip na pahinain ang pagsusuri.