De hecho, es posible renunciar a la CA raíz como una CA subordinada.
Teóricamente ni siquiera necesita la cooperación de la "raíz sin conexión" y su clave privada. El nuevo über-CA simplemente emite un nuevo certificado que contiene la clave pública y el nombre de la raíz anterior, y eso es todo; Esta información es pública de todos modos (están en el certificado del ex-root, que es público). Sin embargo, en la práctica, el über-CA puede preferirlo si recibe una solicitud de certificado firmada por el ex-root, utilizando así su clave privada.
Normalmente, debería poder realizar dicho archivo de solicitud con certreq.exe ( que ya debería estar presente en su máquina). Use certreq -new
con un archivo de política que contenga las propiedades KeyContainer
y ProviderName
para apuntar a la clave privada de su ex-root existente. asegúrese de especificar exactamente el mismo DN de sujeto que el utilizado en el certificado actual de ex-root: la condición para que el nuevo certificado de ex-root sea aceptable como sustituto del actual es que use exactamente el mismo DN y público llave.
Una vez que tenga la solicitud de certificado, transpórtela a über-CA, envíelo y use sus poderes administrativos para autorizar la emisión. Esto supone que über-CA acepta producir certificados de sub-CA, por lo que es posible que tenga que editar y / o habilitar la plantilla de certificado relevante en esa CA.
Una vez hecho esto , existe el nuevo certificado y los clientes pueden usarlo para validar los certificados emitidos por la raíz ex, incluso si solo confían en über-CA. Sin embargo, esto solo funciona si dichos clientes ven el nuevo certificado de la sub-CA. Puede insertarlo por la fuerza en el almacén "CA intermedio" en las máquinas cliente. De forma alternativa, es posible que desee colocarlo en un sitio web al que se haga referencia a partir de los certificados emitidos (entidad final).
De hecho, cualquier certificado dado generalmente contiene un Authority Information Access
extensión estándar que incluye una URL apuntando a un lugar desde donde se puede obtener el certificado de la CA emisora. Esta es la base para la creación de rutas cuando los certificados de CA intermedios relevantes no están fácilmente disponibles. Lo más probable es que su ex-root actualmente emita certificados con, como AIA, una URL que apunta a su propio certificado autofirmado (en un sitio web, en algún servidor LDAP ...). Si desea que los clientes obtengan automáticamente el nuevo certificado de sub-CA emitido para el ex-root, entonces debería ser suficiente para reemplazar el certificado autofirmado de ex-root (donde sea que esté almacenado) con el nuevo certificado de sub-CA.
Tenga en cuenta que el ex-root debe seguir emitiendo CRL según su política.