Introducción

Una CA raíz funciona como un ancla de confianza en dispositivos, sistemas operativos, navegadores web, etc. Una CA raíz emite un certificado autofirmado que se aprovisiona en los sistemas, generalmente en un almacén de confianza, que almacena varios certificados de CA raíz (por ejemplo, el almacén de confianza del navegador web de Mozilla). El certificado autofirmado emitido por una CA raíz suele tener una validez prolongada, generalmente un mínimo de 10 años, pero que puede llegar hasta los 40 años, o incluso indefinida para los identificadores iniciales de dispositivos IoT. También existen periodos de validez más cortos, por ejemplo, estandarizados por la OACI y la UE para pasaportes y documentos de identidad electrónicos.

La razón por la que los tiempos de validez de las CA raíz son largos es que actualizar el almacén de confianza con un nuevo certificado de CA raíz requiere un proceso independiente. Dado que el certificado de CA raíz es autofirmado, no se puede distribuir sin más, ya que los clientes no pueden confiar en la integridad del nuevo certificado, y añadir certificados de CA raíz no autorizados comprometería la seguridad de todo el sistema. Los procesos para actualizar los certificados de CA raíz pueden ser una actualización de software, una actualización específica del almacén de confianza (p. ej., Mozilla, etc.) o un mensaje de protocolo específico. En algunos casos, se utilizan los denominados certificados de enlace para confiar en los nuevos certificados de CA raíz a medida que se distribuyen, confiando en el antiguo certificado de CA raíz y en la cadena de verificación para que se pueda construir el nuevo certificado. Sin embargo, esto no es posible en muchos casos.

Cuando una CA raíz expira, hay al menos dos opciones diferentes con respecto a la nueva CA raíz:

• Mantenga el mismo nombre distinguido (DN) del sujeto de la CA raíz, solo cree una nueva clave de CA y un nuevo certificado de CA, es decir, la CA raíz anterior con una nueva clave.

• Cree un nuevo nombre distinguido (DN) de sujeto de CA raíz, cree una nueva clave de CA y un nuevo certificado de CA, es decir, una nueva CA raíz.

Si bien el primer enfoque puede parecer atractivo, tiene una serie de problemas potenciales cuando se considera un sistema con un cliente antiguo (solo con la antigua CA raíz) y un cliente nuevo (con la antigua y la nueva CA raíz):

• Complicación de la creación de rutas de certificados con múltiples CA con el mismo DN, tanto en clientes antiguos como nuevos.

• Emisión y verificación de CRL de clientes antiguos y nuevos.

Aunque no parezca demasiado complicado, la historia está plagada de diferentes implementaciones de clientes que toman decisiones diferentes que, con el tiempo, causan problemas de interoperabilidad e interrupciones graves. Mantenerlo simple puede evitar algunos de estos problemas.

Por ello, el enfoque recomendado cuando una CA raíz caduca es crear una nueva CA raíz y migrar los clientes a la nueva raíz a medida que caducan y se renuevan. El cliente antiguo puede obtener la actualización del nuevo certificado de la CA raíz para comunicarse con los nuevos clientes, simplificando así las rutas de los certificados.

Tener un proceso para reemplazar completamente una CA antigua por una nueva CA siempre es una buena recomendación, ya que tener este proceso implementado también hace que su organización sea más ágil cuando se trata de compromisos, vulnerabilidades criptográficas y posibles temas futuros como la criptografía post-cuántica.

Recomendaciones generales

Nuestra recomendación general, que se detalla más en la sección a continuación, es crear siempre un nuevo DN de sujeto de CA al renovar las CA raíz.

• Cree un nuevo DN de CA único, por ejemplo: CN=CA emisora corporativa G1 o CN=CA emisora corporativa G2, etc.

• Realice el proceso a tiempo antes de que expire la antigua CA y realice la transición de clientes de forma controlada.

A menos que sepas realmente lo que estás haciendo, en cuyo caso EJBCA tiene funciones fáciles de usar para la renovación manteniendo el mismo DN del sujeto de CA.

Interoperabilidad de PKI de aplicaciones de Microsoft

Las aplicaciones de Microsoft no admiten certificados de enlace para la CA raíz y, además, requieren que la clave de la CA que firmó el certificado emitido firme la CRL correspondiente. EJBCA firma la CRL con la clave de la CA más reciente, lo que normalmente no supone un problema cuando el certificado de la CA anterior caduca y se crea uno nuevo, ya que las entradas de las CRL se eliminan al expirar. Una actualización de la clave en EJBCA antes del vencimiento del certificado de la CA impediría que las aplicaciones de Microsoft validaran los certificados emitidos por la clave de la CA anterior. El diagrama a continuación ilustra la firma de EJBCA y la CA de Microsoft.

Interoperabilidad de la PKI de la OACI

En la PKI de la OACI (pasaportes electrónicos), los certificados de enlace se utilizan para generar confianza entre los certificados de CA raíz antiguos y los nuevos (denominados CA firmantes de país en la PKI de la OACI). La PKI de la OACI tiene una forma especial (no conforme a RFC5280) de gestionar las CRL: un país solo tiene una CRL incluso si existen varias (generaciones) de CA. Es decir, todos los registros de CRL de las CA antiguas se transfieren a la nueva CRL, incluso si el DN emitido es diferente. Para gestionar esto, entre otras cosas, la OACI ha definido una Extensión de Cambio de Nombre específica, que se utiliza para indicar que la nueva CA raíz tiene un nuevo DN de sujeto.

Las recomendaciones para actualizar una CA de firma de país son las mismas que para el caso de Microsoft:

• Cree un nuevo DN de CA único, por ejemplo, CN=Country Signing CA G1 o CN=Country Signing CA G2, o utilice otro componente DN, es decir, CN=CSCA, SerialNumber=100 o CN=CSCA, SerialNumber=101, etc.

• Utilice la extensión de certificado ICAO NameChange

• Crear un certificado de enlace al generar el nuevo CSCA

Para obtener más información, consulte ePassport PKI .