Migración de otras CA a EJBCA

Esta sección incluye información sobre la migración de CA y describe un procedimiento de migración general, así como información específica de cada caso sobre la migración de diferentes CA a EJBCA.

Procedimientos de migración específicos de CA

A continuación se describe información específica del caso sobre cómo migrar desde otras CA a EJBCA:

Procedimiento genérico de migración

A continuación, se describe un proceso genérico para migrar una CA a EJBCA. La migración real puede encontrar obstáculos, como contenido de certificado no compatible. Estos problemas suelen presentarse durante una migración de prueba, realizada para resolver problemas similares antes de una migración final en producción.

Plan de Migración

Este plan de migración genérico se puede utilizar como base para migrar cualquier CA a EJBCA.

La transferencia de datos desde otra CA implica cuatro tipos diferentes de datos:

  • Material de clave HSM

  • Certificados de CA

  • Certificados de entidad final

  • Información de revocación


Pasos de la migración

Una migración completa implica varios pasos. A continuación, se muestra un resumen de los pasos, seguido de información más detallada.

Configurar perfiles

Antes de importar los certificados, se deben configurar todos los perfiles de entidad final y los perfiles de certificado utilizados por las CA y las entidades finales importadas.

Importación de CA y certificados

  • Una vez que el material de claves está en el HSM y listo para usarse, se pueden importar las CA. Esto permite importar certificados de CA y crear objetos de CA en EJBCA, incluyendo tokens criptográficos. La importación de CA se realiza mediante scripts de línea de comandos, que requieren información sobre la ranura del HSM, las etiquetas de clave del HSM y el certificado de CA.

  • Al crear las CA, se pueden importar los certificados de entidad final y las CRL. La importación de certificados de entidad final se realiza mediante scripts de línea de comandos, que requieren la información del certificado, la CA emisora y el nombre de usuario que se usará en EJBCA.

Proceso de importación

Una vez que todo está probado, el proceso de importación implica los siguientes pasos:

  1. Obtener datos de producción

  2. Validar datos de producción

  3. Importar

Configuración después de la transferencia

Valide la configuración de los siguientes campos de Configuración de CA, Perfiles de certificado y Perfiles de entidad final después de la transferencia:

  • Configurar CDP y AIA en Perfiles.

  • Establecer la validez de CRL.

  • Establecer perfiles de certificado CA y configurar los ajustes de CA.

  • Emitir certificados OCSP.

  • Revocar certificados OCSP antiguos.

  • Publicar en OCSP.

  • Emitir CRL.

Una vez verificada la configuración, el sistema EJBCA puede ejecutarse en producción.

Requisitos previos para la migración

Se deben verificar los siguientes requisitos para poder migrar con éxito.

Requisitos de HSM

Las etiquetas de las claves privadas del HSM deben usarse y tener un valor correcto. Se recomienda el siguiente formato de patrón:

<caname>SignKey<date> por ejemplo, rootCAG3SignKey20160226 o highAssuranceCASignKey20160226

No utilice caracteres especiales o internalizados en las etiquetas.

Requisitos del certificado
Certificados y CRL entregados

Se debe descargar y poner a disposición lo siguiente:

  • Todos los certificados de toda la cadena de CA (en formato PEM o DER), incluidos los certificados de CA externos, es decir, los certificados de CA de la solución anterior.

  • Todos los certificados emitidos (en formato PEM o DER).

  • CRL por CA. Solo se requiere la CRL más reciente, a menos que también se necesite el historial de revocación de certificados caducados.

Requisitos técnicos del certificado

Los siguientes son requisitos sobre el contenido del certificado:

  • Sólo atributos DN de sujeto estándar. RFC5280 y CABForum.

  • Solo nombres alternativos de sujeto estándar. RFC5280 con restricciones adicionales.

    • No hay otro nombre, excepto MS UPN, ya que estos suelen ser personalizados

    • No x400Dirección

    • Sin ediPartyName

    • No hay identificación registrada

  • Sólo extensiones de certificado estándar. RFC5280.

  • No se permite el uso de los siguientes caracteres especiales en el DN del asunto o del emisor.

    • \n (nueva línea)

    • \r (retorno de carro)

    • \0 (nulo)

    • ;

    • !

    • %

    • ` (acento invertido)

    • ?

    • $

    • ~

CRL e información de revocación

Las CRL se utilizan para transferir la información de revocación.

Certificados vencidos

Los certificados caducados se pueden importar y las CRL se utilizan para la información de revocación. Si solo se descarga la CRL más reciente, es posible que los certificados caducados no se marquen como revocados, incluso si lo estuvieran, ya que no se incluyen en las CRL (según RFC 5280).

Formato de entrega del certificado

Los certificados deben descargarse y ponerse a disposición en un diseño de directorio, por CA, por perfil de certificado.

CAName/NombrePerfilCertificado/uid.pem (…)

El uid puede ser cualquier identificador utilizado como 'nombre de usuario' en EJBCA si dicha información existe.

Registros de auditoría

Los registros de auditoría deben exportarse de forma segura y almacenarse fuera de línea para que estén disponibles en una auditoría.

Preguntas y notas

Preguntas a considerar antes de una migración:

  • ¿Volúmenes de certificados esperados?

  • Considere exportar datos de la antigua CA para probar la validez.

  • ¿Serán las primeras CA creadas durante la migración (excepto la CA de gestión)? Es decir, la importación de la CA será la "ceremonia clave".

  • ¿Los sistemas funcionarán en paralelo? De ser así, es necesario realizar una especie de «migración delta».

  • ¿Qué se utilizará como 'nombre de usuario' en EJBCA?

Se puede realizar una prueba de importación bastante exhaustiva sin claves privadas (siempre que dispongamos de todos los certificados/CRL). Todas las CA se importarán como externas y se podrá validar la conformidad con el perfil de los datos proporcionados.

Proceso de migración de pruebas

El proceso debe probarse exhaustivamente antes de la migración.

  • Obtener datos de prueba.

  • Validar datos de prueba.

  • Si utiliza un HSM, haga un plan de ranuras de HSM, indicando qué ranura se utiliza para qué CA.

  • Importe ranuras HSM de acuerdo con el plan de ranuras.

  • Genere nuevas claves para una CA de administración e instale EJBCA. Ahora se crea una CA de administración.

  • Importar CA.

  • Importar certificados de entidad final.

  • Importar CRL.

Después de la prueba, se debe validar el sistema y emitir certificados de prueba.