Ciclo de vida del certificado de CA

Cinco años es mucho tiempo en Seguridad de la Información. Diez años verán cómo el mundo de la seguridad decide que algunos algoritmos y claves se comprometen fácilmente. Tengo un cliente que había implementado hash SHA1 en cada nivel para admitir Windows XP sin parches utilizando un entorno PKI que se creó en los últimos cuatro años. Tuvimos que repetir el certificado de cada CA con SHA2 mucho antes de que se hubiera requerido una nueva clave o certificado. Los planes cambian.

Debería tener suficiente tiempo para investigar y decidir si simplemente renovar o cambiar la clave de un certificado es apropiado en cada etapa. No creo que sea un mal plan para cambiar la clave, ya que lo más probable es que existan algoritmos más aceptados (o claves más largas) cuando haya transcurrido ese lapso de años. El gran obstáculo con este enfoque es probar cada aplicación que se basa en su PKI antes de volver a introducir o cambiar los algoritmos.

Si trabaja en un entorno de Microsoft Windows, este es un gran recurso (aunque está agotado y, a menudo, costoso): enlace

Su pregunta sobre cuándo / cómo renovar la clave de CA es buena, pero me temo que no tiene una respuesta genérica; depende de qué aplicaciones estén consumiendo esos certificados y cómo esperan que se comporte una CA cuando se aproxima al final de su vida útil.

Una cosa que es universalmente cierta es que los certificados de entidad final nunca deben superar a cualquier CA en su cadena de emisión porque los certificados de zombis como ese no son revocables, por lo que cualquier "solapamiento" de los períodos de validez de la clave de CA esencialmente significa ejecutar dos CA:

1. Cuando el certificado de CA llegue a end_entity_lifetime de vencimiento, cree una nueva clave de CA y un certificado autofirmado.

2. Certifique de forma cruzada los certificados CA antiguos y nuevos.

3. Haga que su CA mantenga dos conjuntos de servicios CRL / OSCP / CMP: certificados antiguos manejados con la clave antigua, certificados nuevos manejados con la nueva clave.

Pros:

• Las entidades de extremo y las aplicaciones de terceros saben que solo se emitirá un certificado por clave de CA, y será válido hasta que se retire la clave. No tienen que preocuparse por consultar / actualizar el certificado de CA (realmente conveniente para aplicaciones sin conexión, de identificación de certificados o dependientes de caché).
• Las entidades finales emitidas desde las claves de CA antiguas y nuevas pueden confiar entre sí a través de los certificados de enlace de certificación cruzada.
• Las aplicaciones que desean validar un certificado de entidad final pueden seguir la información de CRL / OCSP en el certificado hasta el vencimiento de la clave de CA porque la CA continúa publicando CRL con la clave antigua.
• Para las aplicaciones que conocen los certificados de enlace, hacer una transferencia de la clave de CA es más seguro porque puede extender la confianza de una clave a la siguiente, en lugar de tener que confiar en la nueva clave de CA.

Cons:

• Más complejo de administrar porque básicamente duplicas el número de CA activas.
• No todas las aplicaciones son conscientes de los certificados de enlace, por lo que debe administrar la compatibilidad.

Volver a emitir un certificado raíz para la misma clave resuelve algunos de estos problemas, pero no todos. En particular, rompe el anclaje de certificados basado en el hash de certificados, y significa que los atacantes tienen una ventana más larga para forzar la clave. Dicho esto, esto claramente se hace en la práctica, así que debo estar perdiendo algo ...

Resumen: no estoy seguro de que haya una "respuesta correcta" aquí. Dependiendo de qué aplicaciones consuman sus certificados, es posible que la decisión ya se haya tomado por usted.