¿Certificado de OpenVPN caducado? Revise primero el reloj y luego el certificado

El cliente se conecta, negocia durante un segundo y luego informa que un certificado ha caducado. Antes de pedirle a alguien que reemita algo, mire la fecha del dispositivo que tiene delante: un portátil que ha dormido un mes, un teléfono con el reloj manual y un router sin una fuente NTP funcional informan todos al momento equivocado a una pila TLS. Un certificado solo es válido dentro de una ventana, y la comprobación compara esa ventana con lo que afirma el reloj local. Corrija el reloj y después decida si el problema es real.

Empiece por el reloj del dispositivo

Abra un terminal y lea la idea que tiene el sistema de UTC, no el widget del reloj del escritorio, que puede mostrar una vista ajustada por zona horaria o un valor obsoleto almacenado en caché por la interfaz gráfica.

date -u
timedatectl status

Un reloj muy adelantado hace que un certificado válido parezca caducado, y uno muy atrasado lo hace parecer aún no válido, lo que algunos clientes informan con el mismo fallo genérico de handshake. Si la sincronización está desactivada o la fuente de tiempo no es accesible, arréglelo primero y vuelva a probar antes de tocar cualquier archivo. Atrasar el reloj para saltarse una caducidad no es una solución: rompe otros servicios del dispositivo y deja el problema de identidad exactamente donde estaba.

Si el reloj es correcto, la caducidad es real y el resto de este recorrido se aplica. Fíjese en qué zona horaria usa el registro del cliente antes de comparar marcas de tiempo de dos dispositivos. Un servidor en otra zona puede hacer que una renovación parezca temprana o tardía cuando no lo era. Compare con la marca de tiempo de la línea de registro del propio cliente en lugar del reloj de pared de su escritorio.

Lea la línea de error antes del perfil

Conserve el texto exacto. El fallo de verificación de OpenVPN indica una profundidad y un motivo, y esos dos campos le dicen quién debe actuar.

Un VERIFY ERROR con error=certificate has expired es un fallo de validez en un punto concreto de la cadena. No es un rechazo de contraseña ni un tiempo de espera agotado, y los tres requieren respuestas distintas.

Copie toda la línea en sus notas junto con la versión del cliente. Si el mensaje dice en cambio que el certificado aún no es válido, vuelve a la cuestión del reloj. Si dice que el emisor es desconocido, tiene un problema de confianza y no de vida útil, y ninguna renovación lo cambiará.

Averigüe qué certificado caducó

La profundidad cero es el certificado que presenta el par con el que se conectó, y las profundidades mayores avanzan hacia la raíz. Una VPN de trabajo suele dejar caducar una identidad de cliente o un certificado de servidor, y a veces un intermedio que la organización olvidó que poseía.

Imprima las fechas de los archivos a los que el perfil hace referencia realmente, empezando por el de la profundidad indicada en el error.

openssl x509 -in client.crt -noout -subject -issuer -dates
openssl x509 -in ca.crt -noout -subject -dates

Si el perfil incrusta certificados como bloques incrustados en lugar de apuntar a archivos, los archivos separados del disco pueden ser más antiguos o más nuevos que los que usa el cliente, y por eso emparejar el error con un archivo exige leer el perfil y no el listado del directorio.

Renueve a través del emisor

Un certificado de cliente lo sustituye quien lo emitió, y restablecer la contraseña de la cuenta no renueva nada. Para una conexión de trabajo, use el canal de renovación que publica su organización; para un servicio alojado, inicie sesión en el portal del proveedor mediante una dirección verificada en lugar de abrir un adjunto que afirma contener un perfil nuevo. Un paquete no solicitado no es fiable solo porque el nombre del archivo mencione VPN.

Si usted administra el servidor, revise los datos públicos y los registros de emisión antes de sustituir material, porque un cambio de CA afecta a todos los clientes que confían en ella.

Renovar una identidad no debería exigir sustituir la jerarquía de confianza. Si alguien propone una CA nueva para arreglar una sola hoja caducada, pregunte primero qué más depende de la vieja. Las reglas de validez y de ruta de la RFC 5280 son el modelo que siguen ambas partes.

Haga que el cliente use el reemplazo

Descargar un archivo no es importarlo. Revise la entrada de conexión que elige realmente y compruebe si el perfil hace referencia a rutas de certificados externas que olvidó sobrescribir.

Mantenga visible la entrada antigua hasta que la nueva se conecte y luego elimínela para que nadie elija el perfil caducado por costumbre. Vuelva a conectarse y confirme que el error de caducidad concreto ha desaparecido.

Si queda un error TLS distinto, trátelo como un problema nuevo en lugar de debilitar la configuración de verificación para pasarlo. Un rechazo de cuenta o una ruta ausente tras una renovación correcta es un fallo separado con una solución separada.