Tengo un servidor openvpn, los clientes se autentican mediante certificados SSL. Siempre que un certificado de cliente caduque, se debe emitir y enviar un nuevo certificado al cliente.
Descubrí que easyrsa de openvpn tiene unarenovarcomando pero AFAIK realmente no renueva:Easyrsa "renovar" es un nombre engañoso · Número 345 · OpenVPN/easy-rsa
Entonces la pregunta es: ¿es técnicamente posible extender la validez de un certificado SSL independientemente de si está caducado o no para evitar enviar un nuevo archivo al usuario del cliente?
Respuesta1
Esta es una muy buena pregunta :-).
Technically : yes (at the end the client could use expired one to connect)
Easily : no
En principio, no es posible que la CA firme la solicitud de certificado con un tiempo de validez específico, por lo que no se puede extender. Lo que puede hacer es crear un nuevo certificado y la parte complicada podría estar en el proceso de emisión y en el proceso de verificación de la validez.
Al principio, sería justo mencionar que lo siguiente está técnicamente relacionado con certificados en general y no lo probé con openvpn; si no pasa, la respuesta general sería NO :-(.
En la configuración de openVPN hay 3 parámetros relacionados con los certificados: ca, clave y certificado.
key: clave privada para la firma de datos. Se puede utilizar para descifrar los datos cifrados por elcertificado.
cert: clave pública (derivada dellave) para confirmar la validez de los datos firmados por la clave. Se puede utilizar para cifrar los datos de la clave. Esto se proporcionaría al "otro extremo" durante la negociación de la conexión segura. / este escenario funciona en el caso de que el certificado válido ya se pueda conocer en el extremo remoto, por lo que enviar el certificado puede ser opcional y, siempre que uno caducado, se pueda ignorar /
ca: se utiliza para verificar la validez del certificado proporcionado durante la negociación de conexión segura.
Una vez que el certificado del cliente ha caducado, el caso es que solocertificadoEsta anticuado. En principio, la clave no caduca y la CA no debería caducar (en ese caso, es un caso de uso totalmente diferente ;-)). El certificado contiene un período de validez y forma parte del "sobre" firmado por la CA en la estructura x.509.
Es una buena práctica generar una nueva clave generando un nuevo certificado, pero no hay nada que obligue a este paso, por lo que técnicamente no es un problema crear una CSR (Solicitud de firma de certificado) utilizando la misma clave que el certificado que realmente expira. En caso de que tenga una CSR antigua disponible, puede usarla directamente para obtener un nuevo certificado. Una vez que esta CSR se firma con CA, el nuevo certificado se deriva de la clave "antigua".
La parte complicada es que necesitas (uno de):
entregar este nuevo certificado al usuario actual para reemplazar el certificado
Conozca al servidor sobre este certificado para que pueda usarlo en lugar del caducado proporcionado por el cliente (esta es la parte teórica de este caso de uso ;-))
Lo que sé es que puedes combinar más certificados de CA enCaliforniaarchivo vinculado en la configuración en el servidor sin problemas (en formato PEM). Técnicamente, el certificado de "usuario" y el certificado "ca" difieren en el parámetro que indica si podría usarse como CA. Entonces, técnicamente, puede combinar el certificado de CA con este certificado recién generado en un solo archivo...
Una vez que este archivo esté en su lugar (lo más probable es que sea necesario reiniciar el servidor openvpn), puede intentar establecer una nueva conexión. Una vez que el cliente con la clave intente conectarse, puede suceder que el servidor pueda "identificar" la clave basándose en el hash emparejado con este certificado de cliente ubicado en el servidor e ignorar el certificado proporcionado por el cliente (esto debe probarse). ). Técnicamente (punto de vista del certificado como tecnología) funcionaría pero no lo probé con openVPN. Como openVPN utiliza una biblioteca externa para cosas SSL, puede que funcione ;-).
En el lado del cliente se necesita una CA para probar el lado del servidor (esto no está vencido), una clave para firmar y descifrar la comunicación (esto no está vencido) y un certificado propio no es realmente necesario para la operación local, por lo que uno vencido no es realmente un problema. El certificado del servidor se obtiene durante la negociación SSL y se verifica utilizando el certificado de CA local para que todo lo necesario esté disponible (clave local, certificado remoto).
La desventaja de este enfoque es que está perdiendo un poco el beneficio de CA como certificado único para la validación del certificado del cliente (debe tenerlo listado en el lado del servidor junto al certificado de CA) pero, por otro lado, la ventaja sería la posibilidad de renovarlo. el certificado...
En caso de que lo pruebes, no dudes en enviarnos tu opinión...
¡Buena suerte!
El otro enfoque en caso de planificación podría ser emitir un certificado de largo plazo de validez y utilizar CRL (Lista de reubicación de certificados) para revocar certificados no válidos durante ese tiempo. Pero este no es el alcance de esta pregunta...