Certificato VPN non ancora valido: tre cause, un ordine di controllo
Non ancora valido significa che l’orologio del dispositivo è indietro, che la finestra inizia davvero più tardi o che un certificato intermedio non è ancora aperto. Controllateli in questo ordine.
Aprite il client, scegliete il profilo che usate da mesi, e si ferma con «certificate is not yet valid». Nulla del vostro accesso è cambiato, e l’archivio di fiducia è probabilmente a posto: il certificato presentato nella stretta di mano porta una finestra di validità che inizia più tardi dell’istante usato dal verificatore. Tre situazioni diverse producono esattamente quel messaggio, e richiedono azioni diverse. L’ordine qui sotto vi dice quale avete prima di toccare un orologio o un file di certificato.
Quale delle tre cause state vedendo
La prima causa è locale: il dispositivo che esegue il controllo ha un orologio anteriore alla data di inizio del certificato. Si vede su hardware con una batteria CMOS scarica, su macchine virtuali ripristinate da un’istantanea vecchia, su apparati rimasti spenti abbastanza a lungo da perdere l’ora, e su reti in cui l’NTP in uscita è bloccato e nessuno se n’è accorto. Il certificato può essere del tutto valido e fallire comunque in questo modo.
La seconda causa appartiene all’emittente, perché il certificato inizia davvero nel futuro: emesso in anticipo, generato con un’ora di inizio esplicita, o firmato come parte di una fase di attivazione non ancora eseguita. La terza causa fa perdere più tempo, perché il certificato foglia è attuale mentre un altro certificato della catena presentata non lo è, quindi l’errore nomina materiale che non avete mai installato.
Una domanda le separa. Il guasto segue il dispositivo o il servizio? Due macchine sulla stessa rete che si comportano diversamente indicano gli orologi. Ogni client che fallisce allo stesso modo indica la finestra del certificato e la catena che c’è dietro.
Leggete la finestra dal certificato realmente presentato
Non ispezionate un file PEM rimasto da una distribuzione precedente; chiedete al servizio la catena che invia adesso. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts stampa ogni certificato della catena. Salvate il blocco che vi interessa ed eseguite openssl x509 -noout -subject -issuer -dates; l’ultimo stampa notBefore e notAfter, e sono quei due valori a decidere. Su Windows, la finestra di dialogo del certificato per la connessione e certutil -dump su un file esportato mostrano gli stessi campi.
Leggete entrambi gli estremi della finestra, non solo l’inizio. Un certificato che apre tra due ore e uno che chiude tra due ore falliscono con messaggi diversi e coinvolgono team diversi. Annotate quale certificato nomina l’errore — foglia, intermedio o radice —, perché questo decide se qualcosa sul lato client può essere riparato.
Potete anche provare la finestra senza aspettarla. La verifica accetta un’ora esplicita: openssl verify -attime 1793600000 -CAfile ca.pem -untrusted intermediate.pem leaf.pem valuta la catena a quel timestamp. Eseguitelo con l’ora attuale per riprodurre il guasto, poi con l’ora di inizio del certificato per confermare che la stessa catena passa quando la finestra si apre. RFC 5280 definisce il campo di validità e la regola per cui un certificato non va usato al di fuori, ed è esattamente la regola che il vostro client ha appena applicato.
Il vostro orologio, o il loro
Confrontate l’orologio del dispositivo con l’inizio del certificato in UTC, da una fonte di cui vi fidate. date -u dà l’istante, e timedatectl status su un host systemd riporta anche se l’orologio è sincronizzato. Su Windows, w32tm /query /status mostra la fonte attuale e l’ultima sincronizzazione riuscita. Il fuso orario mostrato nella barra delle applicazioni è una scelta di visualizzazione, non un orologio sbagliato; il verificatore confronta istanti 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 |
Se l’orologio è indietro, risincronizzate e riprovate prima di cambiare qualsiasi materiale del certificato. Un dispositivo sfasato di minuti o ore rifiuta ogni certificato emesso di recente che incontra, non solo un servizio, quindi una spiegazione basata su un solo servizio di solito è quella sbagliata. Se l’orologio è corretto e sincronizzato, smettete di guardare il dispositivo: la finestra appartiene all’emittente, e nessuna impostazione locale va modificata per farla passare.
Quella tabella è tutta la decisione. Spostare l’orologio su ciò che il certificato si aspetta non è una riparazione, e disattivare i controlli dell’ora non lo è nemmeno, perché entrambi nascondono la condizione che ha prodotto l’errore.
Perché la catena fallisce mentre la foglia sembra a posto
Le foglie rinnovate e gli intermedi di sostituzione di solito vengono spediti insieme, e non sempre arrivano nello stesso momento. Un servizio può inviare una nuova foglia firmata da un intermedio la cui finestra inizia più tardi, o continuare a servire un intermedio più vecchio sotto una foglia nuova. In entrambi i casi la catena fallisce mentre le date della foglia stessa sembrano ragionevoli.
Gli endpoint bilanciati trasformano questo da rotto in incoerente. Se un nuovo tentativo riesce, o una rete funziona e un’altra no, annotate quale peer ha risposto e quale catena ha inviato prima di cambiare impostazioni. openssl s_client stampa l’indirizzo connesso, quindi alcuni tentativi rivelano se ogni nodo serve la stessa catena.
Percorsi di riparazione che mantengono intatta la verifica
Un problema di orologio si corregge sul dispositivo lasciando attiva la verifica. Un problema di certificato lo corregge l’operatore con materiale emesso per una finestra che include già l’adesso. Nessuna impostazione del client rende valido un certificato non ancora valido; i flag che saltano i controlli dell’ora esistono per confermare una diagnosi, non per essere messi in produzione.
Quando il certificato è preparato per un’attivazione pianificata, seguite il piano di passaggio. Installatelo quando la sua finestra si apre, o usate la procedura di sovrapposizione documentata dal fornitore, invece di installarlo in anticipo e insegnare agli utenti a cliccare oltre gli avvisi. Gli avvisi che le persone imparano a ignorare costano più di un breve ritardo.
Infine, riprovate come si è verificato il guasto: una nuova sessione, lo stesso client, la risorsa che vi serve davvero. Le librerie TLS possono memorizzare una catena verificata per tutta la vita di una connessione, e una sessione ripresa non la ricontrolla necessariamente, quindi una vecchia sessione può continuare a fallire dopo la correzione o continuare a funzionare dopo una regressione. Un file che si apre in un visualizzatore dimostra solo che il file è leggibile; una stretta di mano completata dimostra che la catena si valida.
Prima di chiudere il ticket, confermate quattro cose: l’ora UTC e lo stato di sincronizzazione del dispositivo che fallisce, notBefore e notAfter di ogni certificato nella catena presentata, la stessa catena da un secondo client, e il nome che l’errore dà al certificato. Se l’orologio è corretto e la finestra non si è aperta, il resto è lavoro dell’operatore, e la mossa giusta dalla vostra parte è aspettare la finestra invece di indebolire il controllo.