Certificado VPN aínda non válido: tres causas e unha orde de comprobación
Aínda non válido significa que o reloxo do dispositivo vai atrasado, que a xanela realmente comeza máis tarde ou que un certificado intermedio aínda non se abriu. Compódeos nesa orde.
Abre o cliente, escolle o perfil que leva meses usando e detense con "certificate is not yet valid". Nada do seu inicio de sesión cambiou e o almacén de confianza probablemente estea ben: o certificado presentado no handshake leva unha xanela de validez que comeza máis tarde que o instante que usa o verificador. Tres situacións distintas producen exactamente esa mensaxe e esixen accións diferentes. A orde seguinte dille cal ten antes de tocar un reloxo ou un ficheiro de certificado.
Cal das tres causas está vendo
A primeira causa é local: o dispositivo que fai a comprobación ten un reloxo anterior á data de inicio do certificado. Vese en hardware cunha batería CMOS morta, en máquinas virtuais restauradas dunha instantánea antiga, en equipos que estiveron apagados o tempo suficiente para perder a hora e en redes onde o NTP saínte está bloqueado e ninguén se decatou. O certificado pode ser totalmente válido e aínda así fallar deste xeito.
A segunda causa pertence ao emisor, porque o certificado realmente comeza no futuro: emitido antes de tempo, xerado cunha hora de inicio explícita ou asinado como parte dun paso de activación que aínda non se executou. A terceira causa é a que máis tempo fai perder, porque o certificado folla está vixente mentres que outro certificado da cadea presentada non o está, así que o erro nomea material que nunca instalou.
Unha pregunta sepáraos. O fallo segue o dispositivo ou o servizo? Dúas máquinas na mesma rede que se comportan de forma distinta apuntan aos reloxos. Todos os clientes que fallan igual apuntan á xanela do certificado e á cadea que hai detrás.
Lea a xanela do certificado que realmente se presentou
Non inspeccione un ficheiro PEM que quedou dun despregamento anterior; pida ao servizo a cadea que envía agora. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts imprime cada certificado da cadea. Garde o bloque que lle interesa e execute openssl x509 -noout -subject -issuer -dates; o último imprime notBefore e notAfter, e eses son os dous valores que deciden. En Windows, o diálogo de certificado da conexión e certutil -dump sobre un ficheiro exportado mostran os mesmos campos.
Lea ambos os extremos da xanela, non só o inicio. Un certificado que abre dentro de dúas horas e outro que pecha dentro de dúas horas fallan con mensaxes distintas e implican equipos distintos. Anote que certificado nomea o erro —folla, intermedio ou raíz—, porque iso decide se se pode arranxar algo do lado do cliente.
Tamén pode probar a xanela sen esperala. A verificación acepta unha hora explícita: openssl verify -attime 1793600000 -CAfile ca.pem -untrusted intermediate.pem leaf.pem avalía a cadea nesa marca de tempo. Execúteo coa hora actual para reproducir o fallo e logo coa hora de inicio do certificado para confirmar que a mesma cadea pasa cando se abre a xanela. RFC 5280 define o campo de validez e a regra de que un certificado non debe usarse fóra del, e esa é a regra que o seu cliente acaba de aplicar.
O seu reloxo ou o seu
Compare o reloxo do dispositivo co inicio do certificado en UTC, desde unha fonte na que confíe. date -u dá o instante, e timedatectl status nun host systemd tamén informa de se o reloxo está sincronizado. En Windows, w32tm /query /status mostra a fonte actual e a última sincronización correcta. A zona horaria que se ve na bandexa é unha elección de visualización, non un reloxo equivocado; o verificador compara instantes 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 o reloxo vai atrasado, resincronice e volva probar antes de cambiar calquera material de certificado. Un dispositivo que vai minutos ou horas desviado rexeita todos os certificados emitidos recentemente que atopa, non só un servizo, así que unha explicación dun só servizo adoita ser a incorrecta. Se o reloxo é correcto e está sincronizado, deixe de mirar o dispositivo: a xanela é do emisor e ningún axuste local debe modificarse para facela pasar.
Esa táboa é toda a decisión. Mover o reloxo ao que o certificado espera non é unha reparación, e desactivar as comprobacións de hora tampouco o é, porque ambas ocultan a condición que produciu o erro.
Por que falla a cadea mentres a folla parece correcta
As follas renovadas e os intermedios de substitución adoitan enviarse xuntos, e non sempre aterran no mesmo momento. Un servizo pode enviar unha folla nova asinada por un intermedio cuxa propia xanela comeza máis tarde, ou seguir servindo un intermedio máis antigo baixo unha folla nova. En ambos os casos a cadea falla mentres as datas da propia folla parecen razoables.
Os extremos con balanceo de carga converten isto de roto en incoherente. Se un reintento ten éxito, ou unha rede funciona e outra non, anote que par respondeu e que cadea enviou antes de cambiar axustes. openssl s_client imprime o enderezo conectado, así que uns cantos intentos revelan se cada nodo serve a mesma cadea.
Camiños de reparación que manteñen intacta a validación
Un problema de reloxo corríxese no dispositivo coa validación activada. Un problema de certificado corríxoo o operador con material emitido para unha xanela que xa inclúe o agora. Ningún axuste do cliente fai válido un certificado aínda non válido; os indicadores que omiten as comprobacións de hora existen para confirmar un diagnóstico, non para poñelos en produción.
Cando o certificado está preparado para unha activación planificada, siga o plan de transición. Instáleo cando se abra a súa xanela, ou use o procedemento de solapamento que documenta o provedor, en lugar de instalalo antes de tempo e ensinar os usuarios a facer clic nos avisos. Os avisos que a xente aprende a descartar custan máis que un breve atraso.
Por último, volva probar tal como ocorreu o fallo: unha sesión nova, o mesmo cliente, o recurso que realmente necesita. As bibliotecas TLS poden almacenar en caché unha cadea verificada durante toda a vida dunha conexión, e unha sesión retomada non necesariamente a comproba outra vez, así que unha sesión antiga pode seguir fallando tras a corrección ou seguir funcionando tras unha regresión. Un ficheiro que se abre nun visor só demostra que o ficheiro é lexible; un handshake completado demostra que a cadea valida.
Antes de pechar o ticket, confirme catro cousas: a hora UTC e o estado de sincronización do dispositivo que falla, o notBefore e o notAfter de cada certificado da cadea presentada, a mesma cadea desde un segundo cliente e o nome que o erro pon ao certificado. Se o reloxo é correcto e a xanela non se abriu, o resto é traballo do operador, e o movemento correcto pola súa parte é esperar a xanela en lugar de debilitar a comprobación.