Hapni klientin, zgjidhni profilin që e përdorni prej muajsh, dhe ai ndalon me "certificate is not yet valid". Asgjë në hyrjen tuaj nuk ka ndryshuar, dhe depoja e besimit ndoshta është në rregull: certifikata e paraqitur në shtrëngimin e duarve mban një dritare vlefshmërie që fillon më vonë sesa momenti që përdor verifikuesi. Tri situata të ndryshme prodhojnë pikërisht atë mesazh dhe kërkojnë veprime të ndryshme. Rendi më poshtë ju tregon se cilën keni përpara se të prekni një orë ose një skedar certifikate.

Cilën nga tri shkaqet po shihni

Shkaku i parë është lokal: pajisja që kryen kontrollin ka një orë më të hershme se data e fillimit të certifikatës. E shihni në harduer me bateri CMOS të vdekur, në makina virtuale të rikthyera nga një pamje e vjetër, në pajisje që kanë qenë të fikura mjaft gjatë për të humbur kohën, dhe në rrjete ku NTP dalës është bllokuar dhe askush nuk e ka vënë re. Certifikata mund të jetë plotësisht e vlefshme dhe gjithsesi të dështojë në këtë mënyrë.

Shkaku i dytë i përket lëshuesit, sepse certifikata vërtet fillon në të ardhmen: lëshuar herët, gjeneruar me kohë fillimi të qartë, ose nënshkruar si pjesë e një hapi aktivizimi që nuk është ekzekutuar ende. Shkaku i tretë humb më shumë kohë, sepse fleta është aktuale ndërsa një certifikatë tjetër në zinxhirin e paraqitur nuk është, kështu që gabimi emërton material që nuk e keni instaluar kurrë.

Një pyetje i ndan. A ndjek dështimi pajisjen apo shërbimin? Dy makina në të njëjtin rrjet që sillen ndryshe tregojnë orët. Nëse çdo klient dështon në të njëjtën mënyrë, kjo tregon dritaren e certifikatës dhe zinxhirin pas saj.

Lexoni dritaren nga certifikata që u paraqit vërtet

Mos inspektoni një skedar PEM që ka mbetur nga një vendosje e mëparshme; pyesni shërbimin për zinxhirin që dërgon tani. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts printon çdo certifikatë në zinxhir. Ruani bllokun që ju intereson dhe ekzekutoni openssl x509 -noout -subject -issuer -dates; i fundit printon notBefore dhe notAfter, dhe janë këto dy vlera që vendosin. Në Windows, dialogu i certifikatës për lidhjen dhe certutil -dump në një skedar të eksportuar tregojnë të njëjtat fusha.

Lexoni të dy skajet e dritares, jo vetëm fillimin. Një certifikatë që hapet pas dy orësh dhe një që mbyllet pas dy orësh dështojnë me mesazhe të ndryshme dhe përfshijnë ekipe të ndryshme. Vini re cilën certifikatë emërton gabimi — fletë, e ndërmjetme ose rrënjë —, sepse kjo vendos nëse mund të rregullohet diçka në anën e klientit.

Mund ta provoni dritaren edhe pa pritur për të. Verifikimi pranon një kohë të qartë: openssl verify -attime 1793600000 -CAfile ca.pem -untrusted intermediate.pem leaf.pem vlerëson zinxhirin në atë vulë kohore. Ekzekutojeni me kohën aktuale për të riprodhuar dështimin, pastaj me kohën e fillimit të certifikatës për të konfirmuar se i njëjti zinxhir kalon sapo hapet dritarja. RFC 5280 përcakton fushën e vlefshmërisë dhe rregullin që një certifikatë nuk duhet të përdoret jashtë saj, dhe pikërisht ky rregull u zbatua sapo nga klienti juaj.

Ora juaj, apo e tyre

Krahasoni orën e pajisjes me fillimin e certifikatës në UTC, nga një burim që i besoni. date -u jep momentin, dhe timedatectl status në një host systemd raporton gjithashtu nëse ora është sinkronizuar. Në Windows, w32tm /query /status tregon burimin aktual dhe sinkronizimin e fundit të suksesshëm. Zona kohore e shfaqur në tabaka është një zgjedhje shfaqjeje, jo një orë e gabuar; verifikuesi krahason momentet UTC.

What you seeMost likely readingNext step
Clock behind, one device affectedLocal time faultResync time, keep validation on, retest
Clock correct, window opens soonCertificate staged earlyWait for the window or follow the cutover plan
Clock correct, intermediate not yet validChain material mismatchOperator replaces the intermediate
Some peers pass, others do notInconsistent nodesRecord each peer's chain before changing anything

Nëse ora mbetet pas, sinkronizoni përsëri dhe provoni përsëri përpara se të ndryshoni çdo material certifikate. Një pajisje që është minuta ose orë gabim refuzon çdo certifikatë të lëshuar së fundmi që takon, jo vetëm një shërbim, kështu që një shpjegim me një shërbim të vetëm është zakonisht ai i gabuari. Nëse ora është e saktë dhe e sinkronizuar, ndaloni së shikuari pajisjen: dritarja i përket lëshuesit, dhe asnjë cilësim lokal nuk duhet të rregullohet për ta kaluar atë.

Ajo tabelë është e gjithë vendimi. Zhvendosja e orës në atë që pret certifikata nuk është riparim, dhe çaktivizimi i kontrolleve të kohës gjithashtu nuk është, sepse të dyja fshehin gjendjen që prodhoi gabimin.

Pse zinxhiri dështon ndërsa fleta duket mirë

Fletët e përtërira dhe certifikatat e ndërmjetme zëvendësuese zakonisht dërgohen së bashku, dhe nuk arrijnë gjithmonë në të njëjtin moment. Një shërbim mund të dërgojë një fletë të re të nënshkruar nga një e ndërmjetme, dritarja e së cilës fillon më vonë, ose të vazhdojë të shërbejë një të ndërmjetme më të vjetër nën një fletë të freskët. Në të dyja rastet zinxhiri dështon ndërsa datat e vetë fletës duken të arsyeshme.

Pikat fundore me balancim ngarkese e kthejnë këtë nga i thyer në jokonsistent. Nëse një provë e re ka sukses, ose një rrjet funksionon ndërsa një tjetër jo, shënoni cili palë u përgjigj dhe cilin zinxhir dërgoi përpara se të ndryshoni cilësimet. openssl s_client printon adresën e lidhur, kështu që disa përpjekje zbulojnë nëse çdo nyje shërben të njëjtin zinxhir.

Rrugë riparimi që e mbajnë verifikimin të paprekur

Një problem ore rregullohet në pajisje duke e lënë verifikimin të aktivizuar. Një problem certifikate rregullohet nga operatori me material të lëshuar për një dritare që përfshin tashmë tani. Asnjë cilësim klienti nuk e bën të vlefshme një certifikatë ende të pavlefshme; flamujt që anashkalojnë kontrollet e kohës ekzistojnë për të konfirmuar një diagnozë, jo për t'i vendosur në prodhim.

Kur certifikata është përgatitur për një aktivizim të planifikuar, ndiqni planin e tranzicionit. Instalojeni kur të hapet dritarja e saj, ose përdorni procedurën e mbivendosjes që dokumenton ofruesi, në vend që ta instaloni herët dhe t'u mësoni përdoruesve të klikojnë nëpër paralajmërime. Paralajmërimet që njerëzit mësojnë t'i injorojnë kushtojnë më shumë se një vonesë e shkurtër.

Së fundi, provoni përsëri ashtu siç ndodhi dështimi: një sesion i re, i njëjti klient, burimi që ju nevojitet vërtet. Bibliotekat TLS mund të ruajnë në cache një zinxhir të verifikuar për gjithë jetën e një lidhjeje, dhe një sesion i rifilluar nuk e kontrollon domosdoshmërisht përsëri, kështu që një sesion i vjetër mund të vazhdojë të dështojë pas rregullimit ose të vazhdojë të funksionojë pas një regresioni. Një skedar që hapet në një shikues vërteton vetëm se skedari është i lexueshëm; një shtrëngim duarsh i përfunduar vërteton se zinxhiri verifikohet.

Përpara se të mbyllni tiketën, konfirmoni katër gjëra: orën UTC dhe gjendjen e sinkronizimit të pajisjes që dështon, notBefore dhe notAfter të çdo certifikate në zinxhirin e paraqitur, të njëjtin zinxhir nga një klient i dytë, dhe emrin që gabimi i jep certifikatës. Nëse ora është e saktë dhe dritarja nuk është hapur, pjesa tjetër është puna e operatorit, dhe lëvizja e duhur nga ana juaj është të prisni dritaren në vend që të dobësoni kontrollin.

Artikuj të ngjashëm