Certificat VPN encara no vàlid: tres causes, un ordre de comprovació
Encara no vàlid vol dir que el rellotge del dispositiu va endarrerit, que la finestra realment comença més tard o que un certificat intermedi encara no s'ha obert. Comproveu-los en aquest ordre.
Obriu el client, trieu el perfil que feu servir des de fa mesos i s'atura amb «certificate is not yet valid». No ha canviat res del vostre inici de sessió i l'emmagatzematge de confiança probablement està bé: el certificat presentat a l'handshake porta una finestra de validesa que comença més tard que l'instant que fa servir el verificador. Tres situacions diferents produeixen exactament aquest missatge i demanen accions diferents. L'ordre següent us diu quina teniu abans que toqueu un rellotge o un fitxer de certificat.
Quina de les tres causes teniu
La primera causa és local: el dispositiu que fa la comprovació té un rellotge anterior a la data d'inici del certificat. Es veu en maquinari amb una bateria CMOS morta, en màquines virtuals restaurades d'una instantània antiga, en aparells que van estar apagats prou temps per perdre l'hora i en xarxes on el NTP de sortida està bloquejat i ningú no se'n va adonar. El certificat pot ser del tot vàlid i tot i així fallar d'aquesta manera.
La segona causa pertany a l'emissor, perquè el certificat realment comença en el futur: emès abans d'hora, generat amb una hora d'inici explícita o signat com a part d'un pas d'activació que encara no s'ha executat. La tercera causa és la que fa perdre més temps, perquè el certificat full és vigent mentre que un altre certificat de la cadena presentada no ho és, així que l'error anomena material que mai no vau instal·lar.
Una pregunta els separa. La fallada segueix el dispositiu o el servei? Dues màquines a la mateixa xarxa que es comporten diferent assenyalen els rellotges. Tots els clients que fallen igual assenyalen la finestra del certificat i la cadena que hi ha darrere.
Llegiu la finestra del certificat que realment s'ha presentat
No inspeccioneu un fitxer PEM que hagi quedat d'un desplegament anterior; demaneu al servei la cadena que envia ara. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts imprimeix cada certificat de la cadena. Deseu el bloc que us interessa i executeu openssl x509 -noout -subject -issuer -dates; l'últim imprimeix notBefore i notAfter, i aquests són els dos valors que decideixen el cas. A Windows, el diàleg de certificat de la connexió i certutil -dump sobre un fitxer exportat mostren els mateixos camps.
Llegiu els dos extrems de la finestra, no només l'inici. Un certificat que s'obre d'aquí a dues hores i un que es tanca d'aquí a dues hores fallen amb missatges diferents i impliquen equips diferents. Fixeu-vos quin certificat anomena l'error —full, intermedi o arrel—, perquè això decideix si es pot arreglar res a la banda del client.
També podeu provar la finestra sense esperar-la. La verificació accepta una hora explícita: openssl verify -attime 1793600000 -CAfile ca.pem -untrusted intermediate.pem leaf.pem avalua la cadena en aquell instant de temps. Executeu-lo amb l'hora actual per reproduir la fallada i després amb l'hora d'inici del certificat per confirmar que la mateixa cadena passa quan s'obre la finestra. RFC 5280 defineix el camp de validesa i la regla que un certificat no s'ha d'usar fora d'ell, i aquesta és la regla que el vostre client acaba d'aplicar.
El vostre rellotge o el seu
Compareu el rellotge del dispositiu amb l'inici del certificat en UTC, des d'una font de confiança. date -u dona l'instant, i timedatectl status en un amfitrió systemd també informa si el rellotge està sincronitzat. A Windows, w32tm /query /status mostra la font actual i l'última sincronització correcta. La zona horària que es veu a la safata és una tria de visualització, no un rellotge equivocat; el verificador compara instants 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 |
Si el rellotge va endarrerit, resincronitzeu i torneu a provar abans de canviar cap material de certificat. Un dispositiu que va uns minuts o unes hores desviat rebutja tots els certificats emesos recentment que troba, no només un servei, així que una explicació d'un sol servei normalment és la incorrecta. Si el rellotge és correcte i està sincronitzat, deixeu de mirar el dispositiu: la finestra és de l'emissor i cap paràmetre local no s'ha d'ajustar per fer-la passar.
Aquesta taula és tota la decisió. Moure el rellotge al que el certificat espera no és una reparació, i desactivar les comprovacions d'hora tampoc no ho és, perquè totes dues amaguen la condició que va produir l'error.
Per què falla la cadena mentre el full sembla bé
Els fulls renovats i els intermedis de substitució solen arribar junts, i no sempre ho fan en el mateix moment. Un servei pot enviar un full nou signat per un intermedi la finestra del qual comença més tard, o continuar servint un intermedi més antic sota un full nou. En tots dos casos la cadena falla mentre les dates del full semblen raonables.
Els punts finals amb balanceig de càrrega converteixen això de trencat en inconsistent. Si un reintent té èxit, o una xarxa funciona i una altra no, anoteu quin peer ha respost i quina cadena ha enviat abans de canviar paràmetres. openssl s_client imprimeix l'adreça connectada, així que uns quants intents revelen si cada node serveix la mateixa cadena.
Camins de reparació que mantenen la validació intacta
Un problema de rellotge es corregeix al dispositiu amb la validació activada. Un problema de certificat el corregeix l'operador amb material emès per a una finestra que ja inclou ara. Cap paràmetre del client fa vàlid un certificat encara no vàlid; els senyals que salten les comprovacions d'hora existeixen per confirmar un diagnòstic, no per posar-los en producció.
Quan el certificat està preparat per a una activació planificada, seguiu el pla de transició. Instal·leu-lo quan s'obri la seva finestra, o feu servir el procediment de solapament que documenta el proveïdor, en lloc d'instal·lar-lo abans d'hora i ensenyar els usuaris a clicar els avisos. Els avisos que la gent aprèn a descartar costen més que un petit retard.
Finalment, torneu a provar tal com va passar la fallada: una sessió nova, el mateix client, el recurs que realment necessiteu. Les biblioteques TLS poden emmagatzemar en memòria cau una cadena verificada durant tota la vida d'una connexió, i una sessió represa no necessàriament la torna a comprovar, així que una sessió antiga pot continuar fallant després de l'arranjament o continuar funcionant després d'una regressió. Un fitxer que s'obre en un visor només demostra que el fitxer és llegible; un handshake complet demostra que la cadena valida.
Abans de tancar el tiquet, confirmeu quatre coses: l'hora UTC i l'estat de sincronització del dispositiu que falla, el notBefore i el notAfter de cada certificat de la cadena presentada, la mateixa cadena des d'un segon client i el nom que l'error posa al certificat. Si el rellotge és correcte i la finestra no s'ha obert, la resta és feina de l'operador, i el moviment correcte de la vostra banda és esperar la finestra en lloc d'afeblir la comprovació.