Pregunta Autoridad de certificación del certificado raíz de caducidad y renovación


En 2004, configuré una pequeña autoridad de certificación utilizando OpenSSL en Linux y los scripts de administración simples proporcionados con OpenVPN. De acuerdo con las guías que encontré en ese momento, establecí el período de validez del certificado de CA raíz en 10 años. Desde entonces, he firmado muchos certificados para túneles OpenVPN, sitios web y servidores de correo electrónico, todos los cuales también tienen un período de validez de 10 años (esto puede haber sido incorrecto, pero no lo sabía mejor en ese momento).

He encontrado muchas guías sobre la configuración de una CA, pero muy poca información sobre su administración, y en particular, sobre qué se debe hacer cuando caduque el certificado de la CA raíz, lo que ocurrirá en algún momento de 2014. Así que tengo la siguiente información. preguntas:

  • ¿Los certificados que tienen un período de validez que se extiende después de la expiración del certificado de CA raíz dejarán de ser válidos tan pronto como el último caduque, o seguirán siendo válidos (porque se firmaron durante el período de validez del certificado de CA)?
  • ¿Qué operaciones son necesarias para renovar el certificado de CA raíz y garantizar una transición sin problemas una vez que finalice?
    • ¿Puedo volver a firmar el certificado de CA raíz actual con un período de validez diferente y cargar el certificado recién firmado a los clientes para que los certificados de cliente sigan siendo válidos?
    • ¿O necesito reemplazar todos los certificados de cliente con nuevos firmados por un nuevo certificado de CA raíz?
  • ¿Cuándo debe renovarse el certificado de CA raíz? ¿Cerca del vencimiento, o un tiempo razonable antes del vencimiento?
  • Si la renovación del certificado de CA raíz se convierte en una pieza importante del trabajo, ¿qué puedo hacer mejor ahora para garantizar una transición más suave en la próxima renovación (aparte de establecer el período de validez en 100 años, por supuesto)?

La situación se complica un poco más por el hecho de que mi único acceso a algunos de los clientes es a través de un túnel OpenVPN que utiliza un certificado firmado por el certificado de CA actual, por lo que si tengo que reemplazar todos los certificados de cliente, tendré que copiar Los nuevos archivos al cliente, reinicie el túnel, cruce mis dedos y espero que aparezca después.


87
2017-08-30 08:34


origen




Respuestas:


Mantener la misma clave privada en su CA raíz permite que todos los certificados continúen validándose exitosamente contra la nueva raíz; todo lo que se requiere de ti es confiar en la nueva raíz.

La relación de firma de certificado se basa en una firma de la clave privada; Mantener la misma clave privada (y, implícitamente, la misma clave pública) al generar un nuevo certificado público, con un nuevo período de validez y cualquier otro atributo nuevo cambiado según sea necesario, mantiene la relación de confianza en su lugar. Las CRL también pueden continuar desde el antiguo certificado al nuevo, tal como son, como los certificados, firmados por la clave privada.


Por lo tanto, vamos a verificar!

Hacer una CA raíz:

openssl req -new -x509 -keyout root.key -out origroot.pem -days 3650 -nodes

Generar un certificado de niño de él:

openssl genrsa -out cert.key 1024
openssl req -new -key cert.key -out cert.csr

Firme el certificado de niño:

openssl x509 -req -in cert.csr -CA origroot.pem -CAkey root.key -create_serial -out cert.pem
rm cert.csr

Todo listo allí, relación de certificado normal. Vamos a verificar la confianza:

# openssl verify -CAfile origroot.pem -verbose cert.pem
cert.pem: OK

Ok, entonces, ahora digamos que pasaron 10 años. Generemos un nuevo certificado público a partir de la misma clave privada raíz.

openssl req -new -key root.key -out newcsr.csr
openssl x509 -req -days 3650 -in newcsr.csr -signkey root.key -out newroot.pem
rm newcsr.csr

Y ... funcionó?

# openssl verify -CAfile newroot.pem -verbose cert.pem
cert.pem: OK

¿Pero por qué? Son archivos diferentes, ¿verdad?

# sha1sum newroot.pem
62577e00309e5eacf210d0538cd79c3cdc834020  newroot.pem
# sha1sum origroot.pem
c1d65a6cdfa6fc0e0a800be5edd3ab3b603e1899  origroot.pem

Sí, pero eso no significa que la nueva clave pública no coincida criptográficamente con la firma en el certificado. Diferentes números de serie, mismo módulo:

# openssl x509 -noout -text -in origroot.pem
        Serial Number:
            c0:67:16:c0:8a:6b:59:1d
...
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:bd:56:b5:26:06:c1:f6:4c:f4:7c:14:2c:0d:dd:
                    3c:eb:8f:0a:c0:9d:d8:b4:8c:b5:d9:c7:87:4e:25:
                    8f:7c:92:4d:8f:b3:cc:e9:56:8d:db:f7:fd:d3:57:
                    1f:17:13:25:e7:3f:79:68:9f:b5:20:c9:ef:2f:3d:
                    4b:8d:23:fe:52:98:15:53:3a:91:e1:14:05:a7:7a:
                    9b:20:a9:b2:98:6e:67:36:04:dd:a6:cb:6c:3e:23:
                    6b:73:5b:f1:dd:9e:70:2b:f7:6e:bd:dc:d1:39:98:
                    1f:84:2a:ca:6c:ad:99:8a:fa:05:41:68:f8:e4:10:
                    d7:a3:66:0a:45:bd:0e:cd:9d
# openssl x509 -noout -text -in newroot.pem
        Serial Number:
            9a:a4:7b:e9:2b:0e:2c:32
...
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:bd:56:b5:26:06:c1:f6:4c:f4:7c:14:2c:0d:dd:
                    3c:eb:8f:0a:c0:9d:d8:b4:8c:b5:d9:c7:87:4e:25:
                    8f:7c:92:4d:8f:b3:cc:e9:56:8d:db:f7:fd:d3:57:
                    1f:17:13:25:e7:3f:79:68:9f:b5:20:c9:ef:2f:3d:
                    4b:8d:23:fe:52:98:15:53:3a:91:e1:14:05:a7:7a:
                    9b:20:a9:b2:98:6e:67:36:04:dd:a6:cb:6c:3e:23:
                    6b:73:5b:f1:dd:9e:70:2b:f7:6e:bd:dc:d1:39:98:
                    1f:84:2a:ca:6c:ad:99:8a:fa:05:41:68:f8:e4:10:
                    d7:a3:66:0a:45:bd:0e:cd:9d

Vayamos un poco más para verificar que funciona en la validación de certificados del mundo real.

Inicie una instancia de Apache, y vamos a darle una oportunidad (estructura de archivos de Debian, ajuste según sea necesario):

# cp cert.pem /etc/ssl/certs/
# cp origroot.pem /etc/ssl/certs/
# cp newroot.pem /etc/ssl/certs/
# cp cert.key /etc/ssl/private/

Pondremos estas directivas en una VirtualHost escuchando en 443 - recuerda, el newroot.pem certificado de raíz ni siquiera existía cuando cert.pem Fue generado y firmado.

SSLEngine on
SSLCertificateFile /etc/ssl/certs/cert.pem
SSLCertificateKeyFile /etc/ssl/private/cert.key
SSLCertificateChainFile /etc/ssl/certs/newroot.pem

Veamos cómo se ve en openssl:

# openssl s_client -showcerts -CAfile newroot.pem -connect localhost:443

Certificate chain
 0 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server.lan
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
MIICHzCCAYgCCQCapHvpKw4sMjANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJB
...
-----END CERTIFICATE-----
(this should match the actual contents of newroot.pem)
...
Verify return code: 0 (ok)

Ok, y ¿qué tal un navegador que usa la API criptográfica de MS? Tengo que confiar en la raíz, primero, luego está todo bien, con el número de serie de la nueva raíz:

newroot

Y, todavía deberíamos estar trabajando con la raíz vieja, también. Cambie la configuración de Apache alrededor de:

SSLEngine on
SSLCertificateFile /etc/ssl/certs/cert.pem
SSLCertificateKeyFile /etc/ssl/private/cert.key
SSLCertificateChainFile /etc/ssl/certs/origroot.pem

Haga un reinicio completo en Apache, una recarga no cambiará los certificados correctamente.

# openssl s_client -showcerts -CAfile origroot.pem -connect localhost:443

Certificate chain
 0 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server.lan
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
MIIC3jCCAkegAwIBAgIJAMBnFsCKa1kdMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNV
...
-----END CERTIFICATE-----
(this should match the actual contents of origroot.pem)
...
Verify return code: 0 (ok)

Y, con el navegador MS crypto API, Apache presenta la raíz anterior, pero la nueva raíz aún se encuentra en el confiable almacén de raíz de la computadora. Lo encontrará y validará automáticamente el certificado con la raíz confiable (nueva), a pesar de que Apache presenta una cadena diferente (la raíz antigua). Después de eliminar la nueva raíz de las raíces de confianza y agregar el certificado original de la raíz, todo está bien:

oldroot


¡Eso es todo! Mantenga la misma clave privada cuando renueve, intercambie la nueva raíz de confianza, y prácticamente todo solo funciona. ¡Buena suerte!


124
2017-09-04 18:40



De todos modos, ¿qué sentido tiene crear un nuevo certificado raíz si solo va a reutilizar la misma clave privada? Si sigue haciendo esto una y otra vez, ¿cuál es el punto de tener una fecha de vencimiento para el certificado? Pensé que la caducidad de la raíz se usaba para forzar a los administradores a crear una clave privada más nueva (probablemente más fuerte) que sea más segura contra las máquinas en constante avance que intentan romper las claves. Una llave de 40 bits hecha hace 20 años no es lo suficientemente segura para - jvhashe
@jvhashe Si el certificado raíz ya no es criptográficamente lo suficientemente fuerte, entonces debería deshacerse de él independientemente de su fecha de caducidad. Si está generando su propia raíz, no hay nada que le impida configurarlo para que caduque hace cientos de años cuando ya no estará en el planeta. El vencimiento apenas es relevante en un certificado raíz, y para un certificado secundario, el vencimiento tampoco tiene que ver con la fuerza criptográfica (pregunte a las CA que se están preparando para revocar todos los certificados de 1024 bits en octubre). aquí para más información. - Shane Madden♦
Además de lo anterior, encontré que el número de serie debe ser el mismo para que este método funcione. - Scott Presnell
-set_serial 01 - WTF ??? NO PUEDES REUTIR LOS NUMEROS DE SERIE. Incluso consultaste RFC 4158, Infraestructura de clave pública de Internet X.509: Creación de rutas de certificación? ¿O simplemente lo estás inventando a medida que avanzas? No tiene idea de los problemas que está causando en los agentes de usuario cuando comienzan la construcción de la ruta. - jww
@jww ¿Leíste la respuesta? Eso es solo una demostración del hecho de que la criptografía funciona. Ese comando está literalmente generando un certificado de prueba que podemos verificar más adelante, con el propósito de probar la relación entre el antiguo y el nuevo certificado raíz. Si alguien es Al usar esos comandos directamente, ciertamente espero que algo se rompa, y se dan cuenta de que deben prestar atención al contexto de algo antes de ejecutarlo a ciegas (o no saber si 01 es una serie aceptable en un laboratorio). - Shane Madden♦


Me he dado cuenta de que faltan extensiones de CA en el certificado renovado de la clave de CA original. Esto funcionó más apropiadamente para mí (crea un ./renewedselfsignedca.conf donde se definen las extensiones CA v3, y ca.key y ca.crt se asume que son la clave de CA original y el certificado):

openssl x509 -x509toreq -in ca.crt -signkey ca.key -out renewedselfsignedca.csr
echo -e "[ v3_ca ]\nbasicConstraints= CA:TRUE\nsubjectKeyIdentifier= hash\nauthorityKeyIdentifier= keyid:always,issuer:always\n" > renewedselfsignedca.conf
openssl x509 -req -days 1095 -in renewedselfsignedca.csr -signkey ca.key -out renewedselfsignedca.crt -extfile ./renewedselfsignedca.conf -extensions v3_ca

13
2018-04-22 10:31



Esta ha sido una adición extremadamente útil. La respuesta realmente válida no da como resultado un certificado suficientemente compatible para mí si tiene configuraciones arbitrarias en su raíz original ca. - Theuni
Secundado, muy útil. Otra adición: al igual que Scott Presnell en los comentarios a la respuesta aceptada, también tuve que especificar manualmente el número de serie hexadecimal del certificado renovado para que coincidiera con el anterior. Esto significaba agregar -set_serial 0xdeadbeefabba (no el número de serie real :)) para el último comando x509. Solo entonces mis certificados de cliente se verificaron correctamente con el certificado de CA renovado. - JK Laiho
Este método es más fácil ya que mantiene la misma información que el certificado anterior. - lepe
He creado un script para esta solución más -set_serial - vea mi respuesta - Wolfgang Fahl
¡Esta respuesta me ahorró mucho trabajo, después de pasar casi un día en un problema que requería esto, estaba casi a punto de darme por vencido, me quito el sombrero por esto! - Onitlikesonic


Modo básico para extender el período válido de la raíz (necesita la clave privada pública X.509 y asociada):

Genere el CSR de X.509 público y clave privada:

openssl x509 -x509toreq -in XXX.crt -signkey XXX.key -out XXX.csr

Vuelva a firmar el CSR con clave privada:

openssl x509 -in XXX.csr -out XXX.crt -signkey XXX.key -req -days 365

2
2018-01-22 16:35





Cuando su certificado raíz expira, también lo hacen los certificados que ha firmado con él. Tendrá que generar un nuevo certificado raíz y firmar nuevos certificados con él. Si no desea repetir el proceso cada pocos años, la única opción real es extender la fecha válida en el certificado raíz algo así como diez o veinte años: la raíz que generé para mi propio uso la expuse veinte años.

No se puede "renovar" un certificado raíz. Todo lo que puedes hacer es generar uno nuevo.

Genere una nueva raíz al menos un año o dos antes de que caduque su antigua, para que tenga tiempo de cambiar sin estar en contra de un muro de tiempo si algo sale mal. De esa manera, siempre puedes volver temporalmente a los antiguos certificados hasta que resuelvas tus problemas con el nuevo.

En lo que respecta a los túneles VPN, configuraría un par de servidores de prueba para experimentar, de modo que entienda exactamente lo que tiene que hacer antes de hacerlo con la máquina de un cliente.


0
2017-09-03 23:59



Esta respuesta Parece sugerir que es posible renovar un certificado raíz, reutilizando su clave. Pero sospecho que esto no es diferente de empezar desde cero, ya que el nuevo certificado tendrá una firma diferente y, por lo tanto, no validará los certificados de clientes existentes. - Remy Blank
sí, puede extender el período válido ... y es menos trabajo que volver a crear todos los pki, certificados de cliente y volver a crear una nueva raíz ... - ggrandes
La parte sobre la emisión de nuevos certificados de entidad final no es necesariamente cierta. Depende de cómo se representa el Identificador de clave de autoridad (AKID) en las CA subordinadas y en los certificados de entidad final. Si el AKID se basa en {Nombre distinguido, Número de serie}, entonces se logrará la continuidad. Ver también RFC 4518, Infraestructura de clave pública de Internet X.509: Construcción de rutas de certificación. - jww


@Bianconiglio plus -set_serial trabajó para mí. Mi servidor es solo de intranet, por lo que no me preocupo por los efectos secundarios y ahora tengo tiempo para trabajar en una solución "adecuada".

Utilicé el siguiente script configurable. Solo establece las variables CACRT, CAKEY y NEWCA.

# WF 2017-06-30
# https://serverfault.com/a/501513/162693
CACRT=SnakeOilCA.crt
CAKEY=SnakeOilCA.key
NEWCA=SnakeOilCA2017
serial=`openssl x509 -in $CACRT -serial -noout | cut -f2 -d=`
echo $serial
openssl x509 -x509toreq -in $CACRT -signkey $CAKEY -out $NEWCA.csr
echo -e "[ v3_ca ]\nbasicConstraints= CA:TRUE\nsubjectKeyIdentifier= hash\nauthorityKeyIdentifier= keyid:always,issuer:always\n" > $NEWCA.conf
openssl x509 -req -days 3650 -in $NEWCA.csr -set_serial 0x$serial -signkey $CAKEY -out $NEWCA.crt -extfile ./$NEWCA.conf -extensions v3_ca
openssl x509 -in $NEWCA.crt -enddate -serial -noout

0
2018-06-30 17:33





Hemos tenido el mismo problema, y ​​eso fue en nuestro caso porque el servidor Debian estaba desactualizado y el openSSL tenía este problema:

https://en.wikipedia.org/wiki/Year_2038_problem

La última versión de OpenSSL disponible para Debian 6 trae este problema. Todos los certificados creados después del 23.01.2018 producen una Vality: ¡para 1901 años!

La solución es actualizar el OpenSSL. Puede crear de nuevo los archivos de configuración (con los certificados) para los clientes.


0
2018-03-09 10:38