VPN-atestilo ankoraŭ ne valida: tri kaŭzoj, unu kontrolordo
Ankoraŭ ne valida signifas, ke la horloĝo de la aparato malantaŭas, ke la fenestro vere komenciĝas pli poste, aŭ ke intera atestilo ankoraŭ ne malfermiĝis. Kontrolu ilin laŭ tiu ordo.
Vi malfermas la klienton, elektas la profilon, kiun vi uzas jam monatojn, kaj ĝi haltas kun "certificate is not yet valid". Nenio pri via ensaluto ŝanĝiĝis, kaj la fido-deponejo verŝajne estas en ordo: la atestilo prezentata en la manpremo portas validecan fenestron, kiu komenciĝas pli poste ol la momento, kiun uzas la kontrolanto. Tri malsamaj situacioj produktas ĝuste tiun mesaĝon, kaj ili postulas malsamajn agojn. La ordo sube diras al vi, kiun vi havas, antaŭ ol vi tuŝos horloĝon aŭ atestilan dosieron.
Kiun el la tri kaŭzoj vi vidas
La unua kaŭzo estas loka: la aparato, kiu faras la kontrolon, havas horloĝon pli fruan ol la komenca dato de la atestilo. Vi vidas tion ĉe aparataro kun morta CMOS-baterio, ĉe virtualaj maŝinoj restarigitaj el malnova momentaĵo, ĉe aparatoj, kiuj restis malŝaltitaj sufiĉe longe por perdi la tempon, kaj en retoj, kie eliranta NTP estas blokita kaj neniu rimarkis. La atestilo povas esti tute valida kaj tamen malsukcesi tiel.
La dua kaŭzo apartenas al la eldoninto, ĉar la atestilo vere komenciĝas en la estonteco: eldonita frue, generita kun eksplicita komenca tempo, aŭ subskribita kiel parto de aktiviga paŝo, kiu ankoraŭ ne ruliĝis. La tria kaŭzo malŝparas la plej multan tempon, ĉar la folio estas aktuala dum alia atestilo en la prezentita ĉeno ne estas, do la eraro nomas materialon, kiun vi neniam instalis.
Unu demando apartigas ilin. Ĉu la fiasko sekvas la aparaton aŭ la servon? Du maŝinoj en la sama reto, kiuj kondutas malsame, indikas horloĝojn. Se ĉiu kliento malsukcesas same, tio indikas la fenestron de la atestilo kaj la ĉenon malantaŭ ĝi.
Legu la fenestron el la atestilo, kiu estis fakte prezentita
Ne inspektu PEM-dosieron restintan de antaŭa deplojo; demandu la servon pri la ĉeno, kiun ĝi sendas nun. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts presas ĉiun atestilon en la ĉeno. Konservu la blokon, kiu interesas vin, kaj rulu openssl x509 -noout -subject -issuer -dates; la lasta presas notBefore kaj notAfter, kaj tiuj estas la du valoroj, kiuj decidas. En Windows la atestila dialogo por la konekto kaj certutil -dump sur eksportita dosiero montras la samajn kampojn.
Legu ambaŭ finojn de la fenestro, ne nur la komencon. Atestilo, kiu malfermiĝas post du horoj, kaj unu, kiu fermiĝas post du horoj, malsukcesas kun malsamaj mesaĝoj kaj engaĝas malsamajn teamojn. Notu, kiun atestilon la eraro nomas — folion, interan aŭ radikon — ĉar tio decidas, ĉu io ajn ĉe la klienta flanko entute povas esti riparita.
Vi ankaŭ povas testi la fenestron sen atendi ĝin. La kontrolo akceptas eksplicitan tempon: openssl verify -attime 1793600000 -CAfile ca.pem -untrusted intermediate.pem leaf.pem taksas la ĉenon je tiu tempindiko. Rulu ĝin kun la nuna tempo por reprodukti la fiaskon, poste kun la komenca tempo de la atestilo por konfirmi, ke la sama ĉeno pasas, kiam la fenestro malfermiĝas. RFC 5280 difinas la validecan kampon kaj la regulon, ke atestilo ne rajtas esti uzata ekster ĝi, kaj ĝuste tiun regulon via kliento ĵus plenumis.
Via horloĝo aŭ ilia
Komparu la horloĝon de la aparato kun la komenco de la atestilo en UTC, el fonte, kiun vi fidas. date -u donas la momenton, kaj timedatectl status sur systemd-gastiganto ankaŭ raportas, ĉu la horloĝo estas sinkronigita. En Windows w32tm /query /status montras la nunan fonton kaj la lastan sukcesan sinkronigon. Horzono montrata en la taskopleto estas elekto de montrado, ne malĝusta horloĝo; la kontrolanto komparas UTC-momentojn.
| 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 |
Se la horloĝo malantaŭas, resinkronigu kaj retestu antaŭ ol ŝanĝi ajnan atestilan materialon. Aparato, kiu estas minutojn aŭ horojn maltrafa, rifuzas ĉiun lastatempe eldonitan atestilon, kiun ĝi renkontas, ne nur unu servon, do klarigo per unu servo kutime estas la malĝusta. Se la horloĝo estas ĝusta kaj sinkronigita, ĉesu rigardi la aparaton: la fenestro apartenas al la eldoninto, kaj neniu loka agordo estu ŝanĝata por igi ĝin pasi.
Tiu tabelo estas la tuta decido. Movi vian horloĝon al tio, kion la atestilo atendas, ne estas riparo, kaj malŝalti tempokontrolojn ankaŭ ne estas, ĉar ambaŭ kaŝas la kondiĉon, kiu produktis la eraron.
Kial la ĉeno fiaskas, dum la folio aspektas bone
Renovigitaj folioj kaj anstataŭaj interaj atestiloj kutime sendiĝas kune, kaj ili ne ĉiam alvenas en la sama momento. Servo povas sendi novan folion subskribitan de intera atestilo, kies propra fenestro komenciĝas pli poste, aŭ daŭrigi servi pli malnovan interan sub freŝa folio. Ambaŭkaze la ĉeno fiaskas, dum la propraj datoj de la folio aspektas raciaj.
Ŝarĝobalancitaj finpunktoj transformas tion de rompita al malkonsekvenca. Se ripeto sukcesas, aŭ unu reto funkcias dum alia ne, notu, kiu samtavolano respondis kaj kiun ĉenon ĝi sendis, antaŭ ol ŝanĝi agordojn. openssl s_client presas la konektitan adreson, do kelkaj provoj malkaŝas, ĉu ĉiu nodo servas la saman ĉenon.
Riparaj vojoj, kiuj konservas la kontrolon sendifekta
Horloĝa problemo estas riparata sur la aparato kun la kontrolo lasita ŝaltita. Atestilan problemon riparas la operaciisto per materialo eldonita por fenestro, kiu jam inkluzivas nun. Neniu klienta agordo igas ankoraŭ-nevalidan atestilon valida; la flagoj, kiuj preterpasas tempokontrolojn, ekzistas por ke vi konfirmu diagnozon, ne por ke vi ilin uzu en produktaĵo.
Kiam la atestilo estas preparita por planita aktivigo, sekvu la transiran planon. Instalu ĝin, kiam ĝia fenestro malfermiĝas, aŭ uzu la koincidan proceduron, kiun la provizanto dokumentas, anstataŭ instali frue kaj instrui uzantojn klaki tra avertoj. Avertoj, kiujn homoj lernas ignori, kostas pli ol mallonga prokrasto.
Fine, retestu tiel, kiel la fiasko okazis: nova sesio, la sama kliento, la rimedo, kiun vi vere bezonas. TLS-bibliotekoj povas kaŝmemorigi kontrolitan ĉenon por la tuta vivo de konekto, kaj rekomencigita sesio ne nepre kontrolas ĝin denove, do malnova sesio povas daŭre fiaski post la riparo aŭ daŭre funkcii post regreso. Dosiero, kiu malfermiĝas en rigardilo, pruvas nur, ke la dosiero estas legebla; kompletigita manpremo pruvas, ke la ĉeno validiĝas.
Antaŭ ol fermi la bileton, konfirmu kvar aferojn: la UTC-tempon kaj sinkronigan staton de la fiaskanta aparato, la notBefore kaj notAfter de ĉiu atestilo en la prezentita ĉeno, la saman ĉenon de dua kliento, kaj la nomon, kiun la eraro donas al la atestilo. Se la horloĝo estas ĝusta kaj la fenestro ne malfermiĝis, la resto estas la laboro de la operaciisto, kaj la ĝusta movo ĉe vi estas atendi la fenestron anstataŭ malfortigi la kontrolon.