Certificado VPN aún no válido: tres causas y un orden de comprobación
Aún no válido significa que el reloj del dispositivo va atrasado, que la ventana realmente empieza más tarde o que un certificado intermedio todavía no se ha abierto. Compruébelos en ese orden.
Abre el cliente, elige el perfil que lleva meses usando y se detiene con "certificate is not yet valid". Nada de su inicio de sesión ha cambiado y el almacén de confianza probablemente esté bien: el certificado presentado en el handshake lleva una ventana de validez que empieza más tarde que el instante que usa el verificador. Tres situaciones distintas producen exactamente ese mensaje y exigen acciones diferentes. El orden siguiente le dice cuál tiene antes de tocar un reloj o un archivo de certificado.
Cuál de las tres causas está viendo
La primera causa es local: el dispositivo que hace la comprobación tiene un reloj anterior a la fecha de inicio del certificado. Se ve en hardware con una batería CMOS muerta, en máquinas virtuales restauradas de una instantánea antigua, en equipos que estuvieron apagados el tiempo suficiente para perder la hora y en redes donde el NTP saliente está bloqueado y nadie se dio cuenta. El certificado puede ser totalmente válido y aun así fallar de esta manera.
La segunda causa pertenece al emisor, porque el certificado realmente empieza en el futuro: emitido antes de tiempo, generado con una hora de inicio explícita o firmado como parte de un paso de activación que aún no se ha ejecutado. La tercera causa es la que más tiempo hace perder, porque el certificado hoja está vigente mientras que otro certificado de la cadena presentada no lo está, así que el error nombra material que nunca instaló.
Una pregunta los separa. ¿El fallo sigue al dispositivo o al servicio? Dos máquinas en la misma red que se comportan de forma distinta apuntan a los relojes. Todos los clientes que fallan igual apuntan a la ventana del certificado y a la cadena que hay detrás.
Lea la ventana del certificado que realmente se presentó
No inspeccione un archivo PEM que quedó de un despliegue anterior; pida al servicio la cadena que envía ahora. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts imprime cada certificado de la cadena. Guarde el bloque que le interesa y ejecute openssl x509 -noout -subject -issuer -dates; el último imprime notBefore y notAfter, y esos son los dos valores que deciden. En Windows, el diálogo de certificado de la conexión y certutil -dump sobre un archivo exportado muestran los mismos campos.
Lea ambos extremos de la ventana, no solo el inicio. Un certificado que abre dentro de dos horas y otro que cierra dentro de dos horas fallan con mensajes distintos e implican a equipos distintos. Anote qué certificado nombra el error —hoja, intermedio o raíz—, porque eso decide si puede arreglarse algo del lado del cliente.
También puede probar la ventana sin esperarla. La verificación acepta una hora explícita: openssl verify -attime 1793600000 -CAfile ca.pem -untrusted intermediate.pem leaf.pem evalúa la cadena en esa marca de tiempo. Ejecútelo con la hora actual para reproducir el fallo y luego con la hora de inicio del certificado para confirmar que la misma cadena pasa cuando se abre la ventana. RFC 5280 define el campo de validez y la regla de que un certificado no debe usarse fuera de él, y esa es la regla que su cliente acaba de aplicar.
Su reloj o el suyo
Compare el reloj del dispositivo con el inicio del certificado en UTC, desde una fuente en la que confíe. date -u da el instante, y timedatectl status en un host systemd también informa de si el reloj está sincronizado. En Windows, w32tm /query /status muestra la fuente actual y la última sincronización correcta. La zona horaria que se ve en la bandeja es una elección de visualización, no un reloj equivocado; el 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 |
Si el reloj va atrasado, resincronice y vuelva a probar antes de cambiar cualquier material de certificado. Un dispositivo que va minutos u horas desviado rechaza todos los certificados emitidos recientemente que encuentra, no solo un servicio, así que una explicación de un solo servicio suele ser la incorrecta. Si el reloj es correcto y está sincronizado, deje de mirar el dispositivo: la ventana es del emisor y ningún ajuste local debe modificarse para hacerla pasar.
Esa tabla es toda la decisión. Mover el reloj a lo que el certificado espera no es una reparación, y desactivar las comprobaciones de hora tampoco lo es, porque ambas ocultan la condición que produjo el error.
Por qué falla la cadena mientras la hoja parece correcta
Las hojas renovadas y los intermedios de sustitución suelen enviarse juntos, y no siempre aterrizan en el mismo momento. Un servicio puede enviar una hoja nueva firmada por un intermedio cuya propia ventana empieza más tarde, o seguir sirviendo un intermedio más antiguo bajo una hoja nueva. En ambos casos la cadena falla mientras las fechas de la propia hoja parecen razonables.
Los extremos con balanceo de carga convierten esto de roto en incoherente. Si un reintento tiene éxito, o una red funciona y otra no, anote qué par respondió y qué cadena envió antes de cambiar ajustes. openssl s_client imprime la dirección conectada, así que unos cuantos intentos revelan si cada nodo sirve la misma cadena.
Caminos de reparación que mantienen intacta la validación
Un problema de reloj se corrige en el dispositivo con la validación activada. Un problema de certificado lo corrige el operador con material emitido para una ventana que ya incluye el ahora. Ningún ajuste del cliente hace válido un certificado aún no válido; los indicadores que omiten las comprobaciones de hora existen para confirmar un diagnóstico, no para ponerlos en producción.
Cuando el certificado está preparado para una activación planificada, siga el plan de transición. Instálelo cuando se abra su ventana, o use el procedimiento de solapamiento que documenta el proveedor, en lugar de instalarlo antes de tiempo y enseñar a los usuarios a hacer clic en los avisos. Los avisos que la gente aprende a descartar cuestan más que un breve retraso.
Por último, vuelva a probar tal como ocurrió el fallo: una sesión nueva, el mismo cliente, el recurso que realmente necesita. Las bibliotecas TLS pueden almacenar en caché una cadena verificada durante toda la vida de una conexión, y una sesión reanudada no necesariamente la comprueba otra vez, así que una sesión antigua puede seguir fallando tras la corrección o seguir funcionando tras una regresión. Un archivo que se abre en un visor solo demuestra que el archivo es legible; un handshake completado demuestra que la cadena valida.
Antes de cerrar el ticket, confirme cuatro cosas: la hora UTC y el estado de sincronización del dispositivo que falla, el notBefore y el notAfter de cada certificado de la cadena presentada, la misma cadena desde un segundo cliente y el nombre que el error pone al certificado. Si el reloj es correcto y la ventana no se ha abierto, el resto es trabajo del operador, y el movimiento correcto por su parte es esperar la ventana en lugar de debilitar la comprobación.