Tipos de CA

El tipo de CA puede ser cualquiera de los siguientes:

• X509: una CA normal para correo electrónico seguro, inicio de sesión, autenticación web, VPN, etc.

• CVC: CA que emite certificados CV, que son certificados especiales para pasaportes electrónicos de la UE y la CAE. Para más información sobre las CA CVC, consulte CA CVC .

• ECA: Autoridad de certificación de inscripción, que emite credenciales de inscripción para entornos ITS PKI, consulte C-ITS ECA .

Algoritmo de firma

El algoritmo de firma a utilizar para emitir certificados, firmar CRL, etc.

Token criptográfico

El token criptográfico donde se espera que existan las asignaciones de claves de la CA.

Enumera los tokens criptográficos disponibles que el administrador puede ver y usar. Para que se muestren, el token criptográfico debe estar activo y contener una clave compatible con el algoritmo de firma de la CA.

Las asignaciones de propósito son el alias de clave en el token criptográfico utilizado para:

• defaultKey: La clave a utilizar, no se selecciona ningún alias específico (Obligatorio).

• certSignKey: La clave que se utilizará para la emisión del certificado. Debe cumplir con el algoritmo de firma y solo se muestran las opciones válidas.

• crlSignKey: La clave para firmar CRL. Aunque teóricamente podría ser independiente de certSignKey según las RFC, el soporte del cliente es poco frecuente y certSignKey siempre se usará.

• keyEncryptKey: Clave que se utiliza para la recuperación de claves cuando está habilitada. Descifra las claves en custodia y debe ser RSA.

• hardTokenEncrypt: Funcionalidad obsoleta, no utilizar.

• testKey: Clave utilizada por la comprobación de estado para verificar que el token criptográfico sea utilizable. Generalmente, es una clave corta para comprobaciones de conexión rápidas.

Si no se ha especificado ningún token criptográfico, se puede generar automáticamente un token criptográfico suave (PKCS#12) con el mismo nombre que la CA. Este token criptográfico se activará automáticamente y tendrá la contraseña predeterminada foo123. Además, NODEFAULTPWD se establecerá como falso, lo que permite manipularlo sin usar contraseña. Cambiar la contraseña (mediante la CLI) o deshabilitar la activación automática también invalidará el uso de la contraseña predeterminada.

Especificación clave de servicios extendidos

Cada CA cuenta con un conjunto de Servicios Extendidos que pueden habilitarse y firmar solicitudes en diversos formatos. Para algunos servicios, la CA delegará la firma en claves programables almacenadas en la base de datos como parte del objeto de la CA. Estos servicios contarán con certificados de firma emitidos por las claves de firma de la CA y un SubjectDN similar al de la CA. Este campo permite seleccionar las especificaciones de clave que se utilizarán para estas claves programables. Actualmente, los siguientes servicios de CA Extendida utilizan esta especificación de clave (los servicios de CA Extendida también pueden usar claves de CA):

• Sintaxis de mensaje criptográfico (CMS, reemplazó a PKCS#7) para firmar registros exportados: se utilizará un par de claves programables en la base de datos.

Secuencia de teclas

La secuencia de claves se utiliza en la referencia del titular del certificado de un certificado/solicitud de certificado EAC CVC. Según las especificaciones de BSI, la secuencia debe tener 5 bytes. El valor inicial debe especificarse en el campo de secuencia. La secuencia puede comenzar con un código de país ISO 3166-2.

Al renovar las claves de los HSM mediante la interfaz gráfica de administración, la nueva etiqueta de la clave de firma será la antigua, con la nueva secuencia de claves al final. Al renovar las claves de los HSM mediante la interfaz gráfica de administración, la secuencia de claves se incrementa automáticamente.

Para las CA X.509, la secuencia de teclas no debería ser importante, excepto para las etiquetas de las teclas al renovarlas. Si no está seguro de la secuencia de teclas, deje que se gestione automáticamente.

Para obtener más información, consulte Secuencia CVC.

Tamaño del octeto del número de serie

Establece la longitud en octetos de los números de serie de los certificados generados en los certificados emitidos. Los valores posibles pueden oscilar entre 4 y 20 octetos, y el valor predeterminado para todas las CA nuevas es de 20 octetos.

El generador de números de serie predeterminado es un generador de números de serie aleatorios de tamaño de octeto constante .

El propósito de este generador de números de serie de certificados es generar números de serie aleatorios con un tamaño fijo de octetos. Si especifica 8 octetos, el número de serie será de 8 octetos; si especifica 20 octetos, será de 20 octetos, etc.

Para lograr esto se realiza el siguiente proceso:

• La cantidad especificada de octetos se recupera de un CSPRNG (SecureRandom en varias formas y formatos).

• Los octetos se convierten en un BigInteger positivo (los números de serie son ENTEROS ASN.1) tomando el valor absoluto del BigInteger creado a partir de los bytes aleatorios.

• Si este entero no cumple con los requisitos y limitaciones especificados por RFC5280 y X.690, el número de serie se descarta.

• Este proceso se repite con nuevos octetos del CSPRNG hasta que se recupera un entero que cumple las pruebas.

• El entero resultante se devuelve como número de serie del generador.

La RFC 5280 define serialNumber como un entero positivo. El simple uso de un entero conforme a la RFC 5280 dará lugar a una codificación de longitud variable del número de serie en el certificado. Si se recupera el entero (aleatorio) 3 del CSPRNG, se codificará como '03' y el número 65535 como 'FFFF', etc. Asimismo, si el número es demasiado grande (los enteros ASN.1 se representan en complemento a dos), se codificará como 9 bytes.

Para lograr números seriales con una longitud fija de octetos, aplicamos restricciones según X.690. X.690 define que INTEGER consta de uno o más octetos, y también define lo siguiente:

Si los octetos de contenido de una codificación de valor entero constan de más de un octeto, entonces los bits del primer octeto y el bit 8 del segundo octeto:

a) no serán todos unos; y b) no serán todos ceros.

Esto establece límites mínimos y máximos para el número entero.

• El valor mínimo de 4 octetos es 00800000 y el valor máximo es 7FFFFFFF.

• El valor mínimo de 8 octetos es 00800000000000000 y el valor máximo es 7FFFFFFFFFFFFFFFF."

• Simplemente amplíe con '00' y 'FF' para otros tamaños de octetos.

Formato de secuencia de claves

Dentro de EAC, existen varias opciones para el formato de secuencia. El formato se puede seleccionar en el campo "Formato de secuencia de teclas". Están disponibles las siguientes opciones:

Para X.509, se recomienda el código numérico de 5 bytes.

Aplicar claves públicas únicas

La aplicación de claves públicas únicas garantiza que los certificados con la misma clave pública solo se puedan emitir al mismo usuario desde esta CA. Esto significa que un usuario puede tener varios certificados (por ejemplo, debido a una renovación) con la misma clave, siempre que utilice el mismo nombre de usuario , pero dos usuarios no pueden compartir la misma clave pública. Esta comprobación solo se realiza al emitir nuevos certificados.

Para usar esta función eficientemente, debe tener un índice de base de datos sobre (subjectKeyId,issuerDN) en la tabla CertificateData . Para más información, consulte "Crear índices de base de datos" en "Creación de la base de datos" y, para scripts de índice, consulte doc/sql-scripts .

Hacer cumplir la renovación de claves

La Renovación de Claves Exigida garantiza que esta CA no pueda emitir certificados con la misma clave pública. Esto significa que no se permiten varios certificados con la misma clave, ni siquiera para la misma entidad final. Esta comprobación solo se realiza al emitir nuevos certificados.

Aplicar DN único

La aplicación de un DN único garantiza que esta CA no pueda emitir certificados a usuarios con el mismo DN de sujeto. Esto significa que un usuario puede tener varios certificados (por ejemplo, para diferentes usos) con el mismo DN de sujeto, siempre que utilice el mismo nombre de usuario . Sin embargo, dos usuarios no pueden compartir el mismo DN de sujeto. Esta comprobación solo se realiza al emitir nuevos certificados.

La comprobación sólo afecta a los nuevos usuarios, es decir, si tienes dos usuarios con el mismo DN antes de habilitar la limitación, estos usuarios antiguos aún pueden compartir el mismo DN y obtener nuevos certificados.

Para usar esta función eficientemente, debe tener un índice de base de datos sobre (subjectDN,issuerDN) en la tabla CertificateData . Para más información, consulte "Crear índices de base de datos" en "Creación de la base de datos" y, para scripts de índice, consulte doc/sql-scripts .

Aplicar un número de serie DN de sujeto único

La aplicación de un número de serie de DN de sujeto único garantiza que solo una entidad final con un número de serie de DN de sujeto específico pueda emitirse desde esta CA. Al añadir una nueva entidad final, se verifica que ninguna otra entidad final, emitida previamente por esta CA, tenga el mismo número de serie de DN de sujeto. Tenga en cuenta que las entidades finales emitidas por otras CA pueden tener el mismo número de serie de DN de sujeto que las entidades finales emitidas por esta CA.

Usar el historial de solicitudes de certificados

El Historial de Solicitudes de Certificados almacena los valores utilizados al generar un certificado para una entidad final. Dado que los valores de la entidad final, como el DN, se pueden editar entre solicitudes, esta función permite rastrear los valores utilizados para emitir un certificado.

Se almacena la siguiente información:

• huella dactilar

• número de serie

• DN del emisor

• nombre de usuario

• marca de tiempo

• Datos de usuarioVO

El historial de solicitudes de certificados está deshabilitado de forma predeterminada a partir de la versión 6.0 de EJBCA. Habilitarlo reduce el rendimiento y ocupa más espacio en la base de datos. Si necesita el historial de solicitudes, considere usar la función de registro de auditoría; consulte Descripción general del registro de auditoría .

Usar almacenamiento de usuario

Los certificados se emiten normalmente en un proceso de dos pasos: primero se añade un usuario a la base de datos con un nombre de usuario, una contraseña (o código de registro) y la información adicional que debe incluirse en el certificado. Posteriormente, EJBCA procesa una solicitud para que se le emita un certificado a este usuario y las credenciales proporcionadas (nombre de usuario y contraseña) se verifican con los datos de usuario almacenados. Actualmente, en la interfaz gráfica de usuario de EJBCA solo se pueden buscar usuarios, no certificados; por lo tanto, sin esta opción habilitada, la interfaz gráfica de usuario no será muy útil.

El almacenamiento de datos de usuario está habilitado de forma predeterminada.

Si se utiliza EJBCA como fábrica de certificados, donde no se requiere la funcionalidad de la interfaz gráfica de usuario (GUI) de administración, se puede deshabilitar el almacenamiento de datos de usuario para mejorar el rendimiento. Para obtener más información, consulte la sección"California de Certificados de Descarte" en Maximización del Rendimiento .

Usar almacenamiento de certificados

Los certificados emitidos se almacenan en la base de datos para permitir su entrega cuando se solicite o para proporcionar información de revocación. El almacenamiento de certificados también se puede desactivar en los Perfiles de Certificado. Desactivar cualquiera de estas opciones hará que los certificados no se almacenen.

El almacenamiento de datos del certificado está habilitado de forma predeterminada.

Si se utiliza EJBCA como fábrica de certificados, donde no se requiere la funcionalidad de la interfaz gráfica de administración, se debe deshabilitar el almacenamiento de datos de certificados para mejorar el rendimiento. Para obtener más información, consulte"Cadena de certificados desechable" .

Aceptar revocaciones de entradas inexistentes

Si la opción Usar almacenamiento de certificados está deshabilitada, los certificados emitidos no se almacenan en EJBCA. Por lo tanto, de forma predeterminada, no es posible revocar este tipo de certificados. Para permitir la revocación de certificados, habilite esta opción. Para obtener más información, consulte la sección"Certificado de CA descartable" en Maximizar el rendimiento .

Perfil de certificado predeterminado para entradas inexistentes

Los certificados desechables no conservan información relacionada con ningún perfil de certificado. La opción "Perfil de certificado predeterminado para entradas inexistentes" determina qué perfil de certificado se usará de forma predeterminada al revocar los certificados desechables emitidos por esta CA. Esta opción solo aplica a las CA desechables.

Usar tabla de solo anexar

Al aceptar revocaciones de certificados desechables, al seleccionar Usar tabla de solo anexar se conservarán todos los datos del certificado desechable revocado en una tabla de base de datos separada de solo anexar.

Preproducir respuestas de OCSP

EMPRESA Esta es una característica de EJBCA Enterprise.

Permite la generación y entrega de respuestas OCSP preproducidas para esta CA. Consulte " Preproducción de respuestas OCSP" para obtener información detallada.

Respuestas de la tienda a pedido

Al habilitar las respuestas de almacenamiento bajo demanda, se conservará una copia de las respuestas OCSP generadas al solicitar el estado de los certificados emitidos por esta CA. Esta respuesta se utilizará para atender futuras solicitudes del mismo certificado hasta que caduque su validez o se genere una nueva. Para obtener más información, consulte Preproducción de respuestas OCSP .

ID de política de certificado

Configurar el ID de la política de certificados al crear una CA afecta a la extensión de la política de certificados del certificado de CA. Puede definir el ID de la política de certificados en:

• Configuración de CA

• Perfil del certificado

• Ambos

Al crear o renovar una CA, los campos de ID de política de certificados de la configuración de la CA y del perfil del certificado se fusionan al crear el certificado. Esto significa que, si se define un valor en ambos lugares, ambos ID de política de certificados se incluirán en el certificado de la CA.

Por razones de coherencia, puede ser una buena idea utilizar únicamente el Id. de la política de certificados en los perfiles de certificados, ya que es el mismo para todos los tipos de certificados y los efectos de combinación pueden resultar confusos.

Codificación de PrintableString en DN

Se utiliza la codificación PrintableString en lugar de la codificación UTF8 para el DN. Se utilizará la codificación PrintableString para el DN de la CA y para el DN de los certificados emitidos por dicha CA. Al configurar la codificación PrintableString en el DN , si algún RDN contiene un carácter que no está en el conjunto PrintableString, dicho RDN adoptará la codificación UTF8 de forma predeterminada.

Restricciones de nombre

Puede restringir los nombres de dominio y las direcciones IP bajo los cuales una CA puede emitir certificados. Los operadores de CA raíz podrían requerir que esta extensión de certificado se use en sub-CA operadas por clientes. El flujo de trabajo previsto consiste en especificar las restricciones de nombre en la entidad final de una sub-CA, lo que hará que la extensión de las restricciones de nombre se incluya en el certificado de la sub-CA una vez generado. La entidad final de la sub-CA se crea en la CA raíz (emitiendo el certificado de la sub-CA).

También es posible agregar restricciones de nombre directamente a una CA secundaria durante su creación. La configuración de las restricciones de nombre se configura en el menú Crear. Pantalla CA y se aplica cuando se crea una Sub CA, firmada por una CA raíz en la misma instancia de EJBCA, y se emite el certificado de Sub CA.

EJBCA admite las siguientes restricciones:

• Nombre de dominio

• Identificador uniforme de recursos (URI)

• Nombre del directorio

• Correo electrónico (nombre RFC 822)

• Dirección IP (tanto IPv4 como IPv6).

Se aceptan las siguientes sintaxis:

Las restricciones de nombre solo se verifican para los tipos de restricciones especificados. Por ejemplo, si no hay direcciones IP, esta no se restringirá. Por el contrario, si un nombre de dominio figura como permitido, no se permitirán otros nombres de dominio. Si no se introducen nombres permitidos ni excluidos, la extensión "Restricciones de Nombre" se omitirá del certificado.

Un ejemplo de certificado con nombre restringido, como el que se muestra usando OpenSSL, podría contener:

Para emitir dicho certificado, configure lo siguiente:

• En el Perfil de certificado, seleccione Restricciones de nombre - Usar .

• En el Perfil de entidad final, seleccione Restricciones de nombre, Permitido - Uso y Restricciones de nombre, Excluido - Uso .

• Agregue la entidad final y especifique lo siguiente en los campos Restricciones de nombre, Permitidas y Restricciones de nombre, Excluidas .

• Genere el certificado y verifique el contenido con: openssl x509 -in cert.pem -text :

Si se le ha emitido un certificado de sub-CA con restricción de nombre de otra CA raíz, puede importar los certificados emitidos por esta CA a otras instancias EJBCA. A continuación, importe el certificado de sub-CA como una CA externa en la nueva instancia EJBCA. Al importar certificados de entidad final, considere configurar los ajustes useLdapDnOrder y usePrintableStringSubjectDN. Los ajustes deben editarse mediante la CLI para una CA externa:

Modo de compatibilidad de CA de Microsoft

Esta configuración garantiza que las CRL y las respuestas de OCSP se firmen con la clave esperada por los clientes de Microsoft Windows después de la regeneración de claves de CA.

Para obtener más información sobre el modo de compatibilidad de CA de Microsoft, consulte Actualizaciones de claves de CA compatibles con Microsoft .

Punto de distribución de emisión en CRL

Al habilitar el Punto de Distribución de Emisión en las CRL, se colocará el Punto de Distribución de CRL predeterminado (el primero de varios) en una extensión de Punto de Distribución de Emisión en las CRL generadas. Según RFC5280, esta extensión de CRL DEBE ser crítica. Sin embargo, si observa que sus CRL son rechazadas, puede optar por que esta extensión no sea crítica.

Mantener los certificados caducados en la CRL

Esta configuración regula qué sucede con los certificados caducados revocados. Está deshabilitada de forma predeterminada y solo debe habilitarse en casos excepcionales.

Para la mayoría de las operaciones de CA, se debe utilizar el comportamiento predeterminado, según lo especificado en RFC5280. En esta configuración, los certificados caducados y revocados se eliminan de la CRL. Esto reduce el tamaño de la CRL, ya que no crecerá más que el número de certificados revocados activos. Dado que la validación básica de certificados comienza verificando su validez, esto es suficiente para la mayoría de los usos habituales de las CRL. Este comportamiento se especifica en RFC5280, secciones 3.3 y 5.2.4.

Algunas normas específicas exigen que los certificados se mantengan en la CRL incluso después de su vencimiento. Al marcar esta casilla, los certificados vencidos y revocados nunca se eliminarán de las CRL futuras, por lo que la CRL puede crecer infinitamente si no se tiene cuidado. Por ejemplo, CABForum lo especifica en sus «Requisitos mínimos para la emisión y gestión de certificados de firma de código de confianza pública», versión 1.1, sección 13.2.1.

Cuando se selecciona esta opción, se agrega a la CRL la extensión CRL ExpiredCertsOnCRL según ISO 9594-8 par. 8.5.2.12.

Utilizar particiones CRL

Permite particionar las CRL en varias CRL más pequeñas, en lugar de una sola CRL grande. Para más información, consulte CRL particionadas .

Periodo de CRL

Las siguientes configuraciones de CA controlan cuándo y si se genera una nueva CRL:

Solo necesita definir el Intervalo de Emisión de CRL o el Tiempo de Superposición de CRL (aunque es perfectamente posible definir ambos). La configuración predeterminada garantiza que no haya un periodo de tiempo (ni siquiera unos segundos) sin una CRL válida emitida, y ofrece a los clientes un intervalo de 10 minutos para descargar una nueva CRL antes de que caduque la anterior. Si desea aumentar este intervalo de tiempo, debe reducir el Intervalo de Emisión de CRL o aumentar el Tiempo de Superposición de CRL.

Permitir cambiar el motivo de la revocación

Esta configuración permite cambiar los motivos de revocación de certificados previamente revocados emitidos por la autoridad de certificación. El motivo de revocación se puede cambiar mediante la interfaz web de RA, la API REST y los servicios web.

URI del emisor de la CA de la CRL

Este valor se utiliza para el campo "Emisor de CA" de las extensiones CRL de acceso a la información de la autoridad, según se especifica en la RFC 5280 (sección 5.2.7) . Debe ser una URL que apunte a un único certificado codificado en DER o a un conjunto de certificados en un mensaje CMS "solo para certificados" codificado en BER o DER, por ejemplo, http://ca.example.xy/cacert.cer.

Los URI múltiples se especifican como una lista separada por punto y coma, y cada URI debe apuntar a un archivo que contenga un solo certificado (.cer) o una colección de certificados (.p7c). Para obtener más información, consulte la sección URI del emisor de CA en Campos de perfiles de certificado .

Datos de validación definidos por CA predeterminados

Los valores de la lista separada por punto y coma para el "Emisor de CA" y el "Localizador de Servicios OCSP" (solo una URL posible) se utilizan para la extensión de Acceso a la Información de la Autoridad de Certificación, según se especifica en la RFC 5280 (sección 4.2.2.1). Los perfiles de certificado utilizados para emitir certificados de entidad final con dicha CA deben tener habilitadas las opciones "Acceso a la Información de la Autoridad ", "Usar emisor de CA definido por la CA" o "Usar localizador OCSP definido por la CA" .

Para obtener más información, consulte URI del emisor de CA y Localizador de servicio OCSP en los campos del perfil de certificado .

Usuario final

La configuración del usuario final define si la CA llama a un proceso llamado "finishUser" después de que se haya emitido un certificado para una entidad final.

• Con esta configuración habilitada, la contraseña de una entidad final solo se puede usar una vez (o tantas veces como se defina en "Número de solicitudes permitidas" al agregar la entidad final) para inscribirse en un certificado. Tras la emisión del último certificado, el estado del usuario se establece en "Generado" y la contraseña se borra. Cuando el estado es "Generado", no se puede emitir un nuevo certificado hasta que se restablezca el estado a "Nuevo", generalmente editando la entidad final.

• Con esta configuración deshabilitada, la contraseña se puede usar una cantidad ilimitada de veces para inscribirse en certificados y el estado permanece como "Nuevo" después de cada uso.

• Tenga en cuenta que la contraseña solo se borrará para tipos de tokens distintos a los generados por el usuario.

Secreto de autenticación de CMP RA

CMP se puede configurar en modo RA para usar un secreto compartido por cada CA para autenticar los mensajes de la RA. Si se configura cmp.ra.authenticationsecret en cmp.properties , este campo se ignorará.

Un valor vacío en este campo denegará todas las solicitudes CMP del modo RA (a menos que cmp.ra.authenticationsecret esté configurado).

Procesador de solicitudes

Un procesador de solicitudes es un complemento que de alguna manera modifica o actúa sobre una CSR entrante antes de emitir certificados cuando se utilizan los siguientes protocolos:

• CMP

• DESCANSAR

• WS

Para obtener más información, consulte Creación de procesadores de solicitudes personalizados.

Cambio de nombre de CA

El cambio de nombres de CA se implementa según la norma ICAO 9303, 7.ª edición, parte 12. También se puede encontrar información en los suplementos de la norma ICAO 9303, 6.ª edición. Actualmente, esta función no forma parte del estándar X509 (RFC5280).

Para aplicar el cambio de nombre de CA durante la renovación, vaya a la página Editar CA y haga lo siguiente:

• Seleccione Usar cambio de nombre de CA y especifique un nuevo DN de sujeto en el campo de texto Nuevo DN de sujeto .
  (Si las opciones están ocultas en la GUI, su administrador debe activar Habilitar cambio de nombre de CA en la página Configuración del sistema )

• Habilitar certificados de enlace

• Para renovar CA, haga clic en Renovar CA

El proceso de renovación de cambio de nombre de CA da como resultado lo siguiente, además de la renovación estándar de CA X509:

• La CA renovada se presentará como nueva CA en la GUI de EJBCA

• El certificado de CA renovado tendrá un DN de sujeto actualizado

• Las CRL emitidas por una CA renovada aún contendrán certificados revocados antes del cambio de nombre.

• La numeración de CRL continuará después de la última CRL emitida antes del cambio de nombre.

• Si se crean, los certificados de enlace tendrán la extensión de cambio de nombre de CA especificada con el documento ICAO 9303
  

Campos específicos de ECA

Los certificados de las Autoridades de Certificación de Inscripción (ECA) de ITS contienen un conjunto de atributos completamente diferente al de X.509, por lo que sus campos de CA también son bastante diferentes. A continuación, se describe los campos de CA utilizados específicamente para la creación de ECA.

• CertificateId: Identificador único de la Autoridad de Inscripción (EA). Se permite cualquier cadena de texto, pero existen estructuras de nombres específicas para cada protocolo, como la versión 1.2 del Protocolo de Punto de Contacto (CPOC) de C-ITS .

• Regiones geográficas: Indica en qué región es válido el certificado. EJBCA actualmente admite regiones europeas circulares, rectangulares e identificadas.

Para obtener más información, consulte Descripción general de ECA de C-ITS y Gestión de ECA de C-ITS .

Cadena(s) de certificados cruzados X509

Para cargar una cadena de certificados cruzados, haga lo siguiente:

1. Vaya a la página Editar CA de la CA deseada.

2. Desplácese hacia abajo hasta la sección Creación/renovación de CA firmada externamente .

3. En la subsección Paso 2 , seleccione el archivo de cadena de certificados cruzados y seleccione Almacenar como una cadena de certificados cruzados separada .

4. Haga clic en Recibir respuesta del certificado para guardar la cadena cruzada.

La cadena de certificados cruzados puede contener varios niveles de jerarquía, y no es necesario importar los certificados de la CA a EJBCA como CA externa. Tras la importación, se muestra un mensaje de éxito en todas las páginas de las Autoridades de Certificación. Esto no convierte a la CA en una "CA firmada externamente" y se conserva la cadena de certificados interna de EJBCA.

Se pueden cargar varias cadenas cruzadas para una CA y también se pueden eliminar en la sección "Certificados cruzados alternativos de CA" de la página "Editar CA" . Los enlaces que se muestran como "subjectDn raíz" se pueden usar para descargar o ver la cadena. Estas cadenas deben terminar con un certificado raíz autofirmado. Se puede cargar una cadena renovada con el mismo subjectDn raíz para reemplazar la cadena anterior.