Algoritmos clave disponibles

Lista de algoritmos de clave permitidos que debe cumplir la clave pública utilizada en las solicitudes de certificado.

Curvas ECDSA disponibles

Lista de curvas con nombre permitidas. Seleccione "Cualquiera permitida por longitud de bits" para permitir cualquier curva que coincida con la restricción de longitud de bits seleccionada.

Longitudes de broca disponibles

Lista de tamaños de clave permitidos que debe cumplir la clave pública utilizada en las solicitudes de certificado. Actualmente, esta validación solo verifica que el tamaño de la clave utilizada esté dentro del intervalo entre el valor mínimo y el máximo seleccionado. Seleccione 0 bits para curvas de EC implícitas.

Validez

La validez determina la fecha de finalización de los certificados emitidos y se puede configurar como:

• fecha fija con formato ISO8601 'aaaa-MM-dd HH:mm:ssZZ', es decir '2017-06-03 18:15:00+00:00', o

• tiempo relativo en términos de años, meses, días, horas y segundos en la forma '*y *mo *d *h *m *s', es decir '2y-10d'

Para una validez relativa, la fecha de finalización del certificado se calcula sumando su fecha de inicio al valor configurado. La hora de inicio suele ser la fecha de emisión (es decir, si no se configura ninguna diferencia para la hora de inicio).

El campo "notAfter" del certificado emitido tendrá el valor "ahora + días de validez". Si se indica en el campo, también puede introducirse en años, meses y días. Por ejemplo, "10a 9mo 8d" se traduce a 10 años, 9 meses y 8 días a partir de ahora. En lugar del período de validez, se podría especificar una fecha de finalización absoluta. Esta fecha debe indicarse en el formato "aaaa-MM-dd HH:mm:ssZZ". Por ejemplo, la fecha "3 de junio de 2017 a las 18:15" en UTC debe indicarse como "2017-06-03 18:15:00+00:00".

La opción "Permitir anulación de validez" permite solicitar una fecha específica de "notAfter". Esto es posible actualmente al usar CMP (el formato de solicitud CRMF) al usar la API para emitir certificados o al usar la página de inscripción en la web de RA.

La validez de un certificado se determina de la siguiente manera:

• El campo Validez en el perfil especifica la validez máxima permitida, que será la validez si no se especifica nada más.

• Si "Permitir anulación de validez" está habilitado en el perfil, el valor del perfil se puede anular con:

  • Hora de inicio y finalización especificada al agregar la entidad final, si está permitido en el Perfil de entidad final.

  • Validez solicitada de la solicitud de certificado (CMP por ejemplo).

Compensación de validez

Se puede configurar un desplazamiento de validez (utilizado para adelantar o retrasar la fecha de inicio y gestionar el desfase horario) en el perfil del certificado como una hora relativa en formato '*y *mo *d *h *m *s'. Con esto, se sobrescribirá el desplazamiento predeterminado del certificado (especificado en cesecore.properties '-10m').

Si se utiliza una fecha de finalización fija con el formato '2016-10-09 14:41:39+01:00' como validez del certificado, solo se compensará la fecha de inicio del certificado.

Si se utiliza un tiempo relativo en formato '*y *mo *d *h *m *s' como validez del certificado, la fecha de inicio y la fecha de finalización del certificado se compensan.

Ejemplo: utilice el valor '-5m' para tener una fecha notBefore que sea 5 minutos antes de la hora actual, para que sea válida para las partes confiables si sus relojes están un poco atrasados.

Restricciones de vencimiento

Las restricciones de vencimiento se pueden configurar en el perfil del certificado para no permitir que los certificados de usuario expiren en ciertos días de la semana, sino antes o después.

Si se utiliza una fecha de finalización fija con el formato '2016-10-09 14:41:39+01:00' como validez del certificado, la restricción se aplica después de guardar el perfil del certificado y se muestra un mensaje de usuario con la nueva fecha de finalización fija.

Si se utiliza un tiempo relativo en formato '*y *mo *d *h *m *s' como validez del certificado, la restricción se aplica durante la emisión del certificado si no entra en conflicto con otras restricciones (es decir, tiempo anidado con el certificado de SubCA).

Descripción del perfil

Utilice el campo Descripción del perfil para definir el perfil del certificado de forma libre. La descripción que especifique se mostrará en la página "Crear nueva solicitud" de RA Web ( Inscribirse > Crear nueva solicitud ) junto al subtipo de certificado seleccionado.

Permitir anulación de extensión

Si se permite la anulación de extensiones, se respetan las extensiones de certificado X509 incluidas en las solicitudes de certificado ; de lo contrario, se ignoran. Las extensiones proporcionadas externamente se añaden a los certificados tal cual. Si dicha extensión ya está definida en el perfil del certificado (es decir, si tiene el mismo OID), se anulará la definición en el perfil, incluido el indicador de criticidad.

Tenga en cuenta que no se realiza ninguna validación del contenido real de la extensión del certificado. Por lo tanto, esta opción solo debe utilizarse cuando se sepa que la solicitud proviene de una fuente muy confiable. Dicha fuente confiable suele ser una RA externa.

• Si la lista de OID de extensiones reemplazables no está vacía y la opción Lista de extensiones no permitidas está borrada, solo se pueden reemplazar (lista de permitidos) las extensiones con OID en esta lista.

• Si la Lista de OID de extensiones reemplazables no está vacía y se selecciona La lista de extensiones no permitidas , se pueden reemplazar todas las extensiones excepto las que se enumeran (lista de bloqueo).
  
  

Permitir que el CSR anule el DN del sujeto

Si se permite la anulación del DN del sujeto, el DN del sujeto X509 creado en un certificado puede provenir directamente de la CSR en la solicitud enviada por el usuario. Esto reemplaza el uso habitual del DN registrado del usuario.

Usando esta opción puedes crear certificados con DNs muy extraños, o con DNs en órdenes muy específicos.

Tenga en cuenta que no se realiza ninguna validación del contenido real del DN del sujeto. Por lo tanto, esta opción solo debe utilizarse cuando se sepa que la solicitud proviene de una fuente muy confiable. Dicha fuente confiable suele ser una RA externa.

Permitir la anulación del DN del sujeto por información de la entidad final

Si se permite la anulación del DN del sujeto, el DN del sujeto X509 creado en un certificado puede provenir directamente de la metainformación de la solicitud enviada por el usuario. Esto reemplaza el método habitual, donde se utiliza el DN registrado del usuario.

Con esta opción, puede crear certificados con un orden muy específico de los campos DN del sujeto. Tenga en cuenta lo siguiente:

• El asunto proporcionado aún tendrá caracteres bloqueados y espacios en blanco eliminados.

• Se escapa '+' ya que no se admiten RDN multivalor.

• Se eliminarán los RDN con valores de atributos vacíos.

• Los nombres deben cumplir con el estilo de nombres de CeSecore (por ejemplo, APELLIDO=... en lugar de SN=..).

Esta opción solo debe usarse cuando se sabe que la solicitud proviene de una fuente de confianza (RA) a través de la llamada "certificateRequest" del servicio web EJBCA. En este caso, el SubjectDN del objeto UserDataVOWS se utilizará sin modificaciones.

Si también se especifica Permitir anulación del DN del sujeto por CSR , se utilizará el DN del sujeto del CSR cuando esté presente.

Permitir anulación del número de serie del certificado

El número de serie del certificado generado podría anularse si la opción Permitir anulación del número de serie del certificado está habilitada en el perfil de certificado utilizado.

Si utiliza la interfaz de usuario de CA para crear entidades, también debe agregar el número de serie del certificado personalizado al perfil de entidad final utilizado.

Con los servicios web, utilice 'setCertificateSerialNumber' para su usuario 'UserDataVOWS'.

Con RA externa (ExtRA), la solicitud de certificado toma un número de serie de certificado como parámetro.

Tenga en cuenta que la fila "serialNumber" de la tabla de base de datos "CertificateData" debe tener un índice único para que esta función funcione. Normalmente, se utiliza un índice para el DN de emisor único, serialNumber. Sin un índice, la función se desactiva automáticamente.

 create unique index certificatedata_idx1 on CertificateData (issuerDN,serialNumber);

Si ejecuta la prueba de estrés de WS de clientToolBox, puede especificar que la prueba utilice 'setCertificateSerialNumber'. Se usará un nuevo número de serie aleatorio para cada usuario creado. La propiedad del sistema Java 'maxCertSN' especifica el número de bits que se usarán en el número de serie.

Ejemplo:

Permitir revocación retroactiva

La información de revocación de un certificado revocado contiene la fecha y hora a partir de las cuales el certificado deja de ser válido (hora de revocación). Normalmente, la hora de revocación se establece en el momento de la revocación. Al habilitar "Permitir revocación retroactiva" , se puede configurar una fecha anterior para la revocación de un certificado del perfil, lo que se denomina revocación retroactiva. La revocación retroactiva también permite cambiar el motivo de la revocación de certificados previamente revocados.

Puede retrotraer las revocaciones mediante el punto final /revoke de la API REST de EJBCA o la interfaz del servicio web, ya sea mediante la llamada a la API de WS revokeCertBackdated en su aplicación o mediante la CLI de servicios web .

Usar almacenamiento de certificados

Los certificados emitidos se almacenan en la base de datos para poder proporcionarlos cuando se soliciten o proporcionar información de revocación. El almacenamiento de certificados también puede desactivarse en la configuración de la CA, creando así certificados efímeros (también conocidos como certificados desechables ). Si se establece cualquiera de estas opciones como "false", los certificados no se almacenarán, ni siquiera la metainformación.

El almacenamiento de certificados está habilitado de forma predeterminada.

Si se utiliza EJBCA como fábrica de certificados, donde no se requiere la funcionalidad de la interfaz de usuario de la CA, se puede deshabilitar el almacenamiento de certificados para mejorar el rendimiento. Para obtener más información, consulte Maximizar el rendimiento .

Almacenar datos del certificado

Permite almacenar metainformación sobre los certificados, pero omite el almacenamiento de los datos reales del certificado (base64Cert) en la base de datos. La metainformación del certificado incluye el estado de revocación, la información de expiración, la huella digital, etc.

Restricciones de longitud de ruta

Una restricción de longitud de ruta limita la profundidad de una cadena de certificados y es una forma eficiente de evitar que una CA intermedia emita otra CA por accidente. Se recomienda incluir una restricción de longitud de ruta en todos los certificados de CA intermedia. Las restricciones de longitud de ruta no suelen aparecer en los certificados de CA raíz, y la sección 7.1.2.1 de Requisitos Base desaconseja su inclusión. Algunas PKI para fines específicos, como las utilizadas para firmar pasaportes según el Doc. 9303 de la OACI, exigen el uso de restricciones de longitud de ruta para todos los certificados raíz CSCA.

El campo de restricción de longitud de ruta se define en la sección 4.2.1.9 del RFC 5280 :

El campo pathLenConstraint solo es relevante si se activa el booleano cA y la extensión de uso de clave, si está presente, activa el bit keyCertSign (Sección 4.2.1.3). En este caso, indica el número máximo de certificados intermedios no autoemitidos que pueden seguir a este certificado en una ruta de certificación válida. (Nota: El último certificado en la ruta de certificación no es un certificado intermedio y no se incluye en este límite. Normalmente, el último certificado es un certificado de entidad final, pero puede ser un certificado de CA). Un valor de pathLenConstraint igual a cero indica que no se pueden seguir certificados intermedios no autoemitidos de CA en una ruta de certificación válida. Si aparece, el valor de pathLenConstraint DEBE ser mayor o igual a cero. Si pathLenConstraint no aparece, no se impone ningún límite.

Uso de la clave

La extensión "Uso de clave" define el propósito sugerido de este certificado. Para los usuarios, el uso del certificado suele dividirse en certificados para firmas (firma digital y no repudio) y certificados para cifrado (cifrado de clave y cifrado de datos).

Para los certificados de CA, el Uso de clave normalmente se establece en Firma de certificado de clave y Firma de CRL .

Los perfiles fijos tienen valores predeterminados razonables. Para más información, consulte RFC 5280.

Permitir anulación del uso de claves

Habilite esta opción para permitir que los usuarios anulen los usos de clave definidos en el perfil al solicitar un certificado. Al habilitar la opción "Permitir anulación de uso de clave", podrá tener un solo perfil de certificado, pero emitir certificados para diferentes propósitos. Déjela deshabilitada a menos que esté seguro de lo que hace.

Uso extendido de la clave

El significado del uso de clave extendida se define en RFC 5280. Normalmente, los valores especificados en los perfiles de certificado fijos son adecuados para el uso previsto.

Puede definir sus propios usos de clave extendida en la página Configuración del sistema web de administración. Seleccione la pestaña Usos de clave extendida y agregue los OID y el nombre legible de su uso de clave extendida personalizado. Después de agregar el nuevo uso de clave, puede seleccionarlo en la página Editar perfil de certificado . Para obtener más información, consulte Usos de clave extendida .

Políticas de certificación

Las Políticas de Certificado indican bajo qué política se emite un certificado emitido con este perfil. Las Políticas de Certificado se describen con más detalle en varias RFC. Una política de certificado se presenta en forma de OID: 2.5.29.32.0

El OID 2.5.29.32.0 corresponde a "anyPolicy", según la definición de RFC 5280. Si crea su propia política, debe crear su propio OID, construido a partir de un "Número de Empresa" asignado por la IANA. Obtener un Número de Empresa es gratuito y puede obtenerlo de la IANA .

Por ejemplo, el número de empresa de PrimeKey es 22408 y se puede construir un OID como 1.3.6.1.4.1.22408.1.1.1.1. Aquí, 1.3.6.1.4.1 es el prefijo estándar de la IANA, PrimeKey es 22408 y lo siguiente significa productos->ejbca->atributos->ejbcaDeviceCertificate. Los números después de 22408 están definidos por PrimeKey.

Para agregar los calificadores de política "Aviso de Usuario" y "URI de CPS" al mismo OID de política, agregue el OID de política dos veces: una con el calificador "Aviso de Usuario" y otra con el calificador "URI de CPS ". En el certificado, se codificará con ambos calificadores bajo el mismo OID (según RFC5280).

Nombre alternativo del emisor

Al utilizar la extensión Nombre alternativo del emisor, se copia el valor del Nombre alternativo del sujeto del certificado de la CA emisora y lo coloca en el certificado producido.

Ejemplos de uso:

• Utilice la extensión Nombre Alternativo del Emisor para crear una CA con el Nombre Alternativo del Sujeto "rfc822Name=ca@org.org" e incluirlo en el certificado de CA. Si incluye el Nombre Alternativo del Emisor en el perfil de certificado utilizado para emitir certificados de entidad final (o sub-CA), estos certificados recibirán el Nombre Alternativo del Emisor "rfc822Name=ca@org.org". Los certificados de entidad final pueden tener un Nombre Alternativo del Sujeto diferente, ya que este está registrado para la entidad final específica.

• Agregue un nombre alternativo de sujeto y emisor con un DirectoryName a una CA raíz configurando el valor para el Nombre alternativo de sujeto en "DirectoryName=L=SWE\,ST=FOO", es decir, con la coma escapada.

Puntos de distribución de CRL

La extensión Punto de Distribución de CRL (CDP) proporciona información a los clientes que verifican un certificado. El valor es un URI que apunta a una CRL que permite comprobar si el certificado está revocado. La CRL la emite la CA. Existen diferentes tipos de Puntos de Distribución de CRL y, actualmente, EJBCA admite un URI.

Un CRLDistributionPoint para una CA en EJBCA podría verse así:

como el enlace desde las páginas de distribución web

• host es el nombre DNS mediante el cual se accede a la CA. El puerto 8080 es el puerto predeterminado que JBoss escucha, pero si lo cambia, este valor también debería cambiar.

• url-encoded-issuerDN es el nombre común de la CA, tal como se configuró al crearla. Este es el mismo DN que aparece como emisor en los certificados emitidos por esta CA.

Al configurar esta extensión debes tomar la URI ingresada y probarla en un navegador normal, desde otra máquina que no sea la CA, para ver que funciona antes de emitir cualquier certificado.

También debería ser posible utilizar un punto de distribución LDAP, si ha configurado un publicador para publicar CRL en LDAP:

Al definir el punto de distribución de CRL y el emisor de CRL en un perfil de certificado, puede configurar los valores en el perfil de certificado o en la configuración de la CA (editar CA). Al configurar la CA, es posible usar el mismo perfil de certificado para varias CA; de lo contrario, tendría que crear un nuevo perfil de certificado para todos los puntos de distribución de CRL.

Al seleccionar "Usar punto de distribución de CRL definido por la CA", puede configurar el punto de distribución de CRL en la página de edición de CA y usar este valor en todos los perfiles de certificado que utilicen esa CA. Esta función es práctica, ya que evita tener que introducir el mismo punto de distribución de CRL en todos los perfiles de certificado.

Es posible configurar varias URL para CDP si se separan con ';'. Por ejemplo: http://cdpurl-1/mycrl.der;http://cdpurl-2/crl.crl

Lo mismo se aplica a CRLIssuer, por ejemplo: CN=Foo,C=SE;CN=Bar,C=US

Tenga en cuenta que si una URL contiene un ';', debe ir entre comillas dobles. Por ejemplo, si tiene dos URL:

• http://cdpurl-1/mycrl.der

• http://cdpurl-2/getcrl;binario

Luego podrías juntarlos como: http://cdpurl-1/mycrl.der;"http://cdpurl-2/getcrl;binary"

Emisor de CRL

Según RFC5280 , un emisor de CRL es:

Un sistema opcional al que una CA delega la publicación de listas de revocación de certificados;

El contenido del campo en el perfil es un DN, como "CN=CRLIssuerForManagementCA,O=foo,C=SE". Debe crear usted mismo el software del emisor de CRL. Si se configura y los perfiles de certificado lo incluyen, el emisor de CRL se incluye en el punto de distribución de CRL de los certificados emitidos.

CRL más reciente

La extensión CRL más reciente (también llamada Punto de distribución de CRL Delta) se utiliza para las CRL Delta. La emisión de CRL Delta se explica en la configuración de la CA. La extensión CRL más reciente identifica cómo se obtiene la información de las CRL Delta. Se utiliza la misma sintaxis para esta extensión y para la extensión cRLDistributionPoints.

Del RFC5280:

La extensión de CRL más reciente identifica cómo se obtiene la información de la CRL delta. Las CA que cumplen con la normativa deben marcar la extensión como no crítica. La sección 5 contiene más información sobre la gestión de CRL. Se utiliza la misma sintaxis para esta extensión y la extensión cRLDistributionPoints, y se describe en la sección 4.2.1.13. Se aplican las mismas convenciones a ambas extensiones.

Localizador de servicios OCSP

Esta extensión se utiliza cuando la información de revocación del certificado que la contiene está disponible mediante el Protocolo de Estado de Certificados en Línea (OCSP) [ RFC6960 ] (anteriormente RFC2560). El campo URI indica la ubicación del respondedor OCSP, según las convenciones definidas en RFC6960 , generalmente una URL simple como http://ocsp.company.com/. La URL predeterminada para el respondedor OCSP interno en EJBCA es http://hostname:8080/ejbca/publicweb/status/ocsp.

OCSP sin verificación

Al seleccionar esta opción se incluye la extensión id-pkix-ocsp-nocheck tal como se define en la sección 4.2.2.2.1 de RFC6960 en los certificados emitidos utilizando este perfil de certificado.

URI del emisor de CA

Este valor se utiliza para el campo de extensiones CRL de acceso a información de autoridad Emisor de CA como se especifica en RFC 5280 (sección 5.2.7).

Las URI especificadas en esta lista separada por punto y coma deben apuntar a archivos que contengan un solo certificado (.cer o .der) o una colección de certificados (.p7c).

Usar orden DN LDAP

En un certificado, el orden de los componentes DN (CN, O, C, etc.) se puede colocar en un orden diferente al del certificado codificado en binario.

• De último a primero, hacia adelante (históricamente llamado Orden DN LDAP en EJBCA): CN=Nombre común, O=Organización, C=País

• De primero a último, orden inverso: C=País, O=Organización, CN=Nombre común

Al usar la representación de cadenas de DN, no suele mostrarse el orden real , pero la herramienta lo mostrará en el orden que considere oportuno, que podría ser inverso al orden binario real. Para ver el orden binario real, se puede usar una herramienta de análisis de ASN1, como OpenSSL. En la práctica, el orden de los DN puede ser importante, ya que las comparaciones se realizan a menudo mediante comparaciones de cadenas, donde el valor de la cadena puede depender o no del orden.

El orden más común es del primero al último (es decir, C, O, CN), pero por razones históricas, EJBCA usa el último al primero (CN, O, C). Sin embargo, algunas aplicaciones requieren este orden, por lo que EJBCA ofrece esta opción (borrando el orden de DN LDAP ). Hay dos opciones en EJBCA donde se puede configurar:

• En el perfil del Certificado (Perfiles de Certificado)

• En la configuración de CA (Autoridades de certificación)

La relación entre las configuraciones es que ambas se evalúan mediante una expresión lógica AND. Esto significa que si ambas son verdaderas, el DN tendrá el orden LDAP de último a primero, pero si alguna de ellas es falsa, el DN tendrá el orden X.500. Para referencias, consulte RFC2253 y RFC4514.

Al usar un orden de DN personalizado , la configuración de orden de DN LDAP también se aplica de forma predeterminada, definiendo qué componente va primero (por ejemplo, CN o C), independientemente del orden exacto especificado en el campo de texto. Desactive la opción "Aplicar configuración de orden de DN LDAP" para que el orden de DN personalizado se use exactamente como se especificó.

Período de uso de la clave privada

La extensión del certificado del Período de uso de clave privada se especifica en RFC 3280 .

EJBCA calcula los componentes notBefore y notAfter de la extensión en función del tiempo de emisión del certificado (cert.notBefore) y los valores de los campos Desplazamiento de inicio (startOffset) y Longitud del período (periodLength) de la siguiente manera:

 notBefore = cert.notBefore + startOffset notAfter = notBefore + periodLength 

Declaración de certificado calificado

La Declaración de Certificado Cualificado se describe generalmente en la RFC 3739 y en los documentos ETSI. Los siguientes campos implementan la declaración de control de calidad predefinida de la RFC 3739. Consulte la sección 3.2.6.1 de la RFC 3739. La RFC 3739 no especifica si el control de calidad debe ser crítico o no; puede serlo.

• Utilice PKIX QCSyntax-v2: RFC3739 define una versión anterior (v1 de RFC3039) y una nueva (v2 de RFC3739). Siempre debe utilizarse la versión 2.

• ID semántico: Seleccione el ID semántico para personas físicas o jurídicas (ETSI EN 319 412-1). EJBCA admite la especificación de múltiples ID semánticos agregándolos como OID separados por comas. Por ejemplo:

  • "0.4.0.194121.1.1,0.4.0.194121.1.2" tanto para personas físicas como jurídicas.

  • "0.4.0.194121.1.1,0.4.0.194121.1.3", para id-etsi-qcs-semanticsId-Natural y id-etsi-qcs-semanticsId-eIDASNatural.

• Autoridades de Registro de Nombres: Si están presentes, deben contener el nombre de una o más autoridades de registro de nombres, responsables del registro de atributos o nombres asociados con el sujeto (por ejemplo, rfc822Name=). Se utiliza poco.

Los siguientes campos implementan las declaraciones de control de calidad definidas en el perfil de certificado cualificado en ETSI EN 319 412-5 / ETSI TS 101 862:

• Utilice ETSI QC Compliance: Declaración que afirme que el certificado es un certificado cualificado (sección 5.2.1 del documento de perfil).

• Utilice el dispositivo de creación de firma segura ETSI (esi4-qcStatement-4): Declaración que afirma que la clave privada relacionada con la clave pública certificada reside en un dispositivo de creación de firma segura (sección 5.2.4 del documento de perfil).

• Usar límite de valor de transacción ETSI (esi4-qcStatement-2): Declaración sobre los límites de valor de las transacciones. Si se configura, se deben especificar los siguientes campos:

  • Límite de valor Moneda: Por ejemplo, EUR, SEK.

  • Importe límite de valor: por ejemplo, 10000.

  • Valor límite Exponente: por ejemplo, 0, 1. Valor total = cantidad * 10^exponente.

• Periodo de retención ETSI en años (esi4-qcStatement-3). El valor predeterminado es 0.

• Tipo ETSI (esi4-qcStatement-6). Puede ser: Sin usar, Firma electrónica (E-Signature), Sello electrónico (E-Seal) o Autenticación de sitio web (QWAC).

• Utilice la legislación de países de control de calidad del ETSI (esi4-qcStatement-7). Lista separada por comas de códigos de país ISO-3166-2 para los países en los que el certificado se clasificará como certificado cualificado según la legislación nacional. Permite especificar códigos ISO-3166-2 no incluidos en la Lista de Confianza de la UE. Por ejemplo, "CH" o "SE,NO".
  

• URL e idioma del PDS ETSI (esi4-qcStatement-5). Permite agregar múltiples pares de URL/idiomas del PDS. Debe ser una URL HTTPS. Por ejemplo, https://www.example.com/respository.
  

Los campos para la cadena de declaración de control de calidad personalizada implementan una declaración de control de calidad con el siguiente ASN.1:

 qcStatement-YourCustom QC-STATEMENT ::= { SYNTAX YourCustomUTF8String IDENTIFIED BY youroid } -- This statement gives you the possibility to define your own QC-statement -- using an OID and a simple UTF8String, with describing text. A sample text could for example be: -- This certificate, according to Act. No. xxxx Electronic Signature Law is a qualified electronic certificate YourCustomUTF8String ::= UTF8String

• Usar cadena de declaración de control de calidad personalizada: incluya esta declaración de control de calidad personalizada en la extensión de declaraciones de control de calidad en los certificados.

• OID de declaración de control de calidad personalizada: Su OID, tal como se define anteriormente, debe definirlo usted mismo.

• Texto de declaración de control de calidad personalizado: el texto descriptivo tal como se define anteriormente.

Una declaración de control de calidad eIDAS típica (EN 319 412-5) puede constar de:

• id-etsi-qcs-Cumplimiento de calidad

• id-qcs-pkixQCSyntax-v2

• id-etsi-qcs-QcSSCD

• id-etsi-qcs-QcPDS = www.primekey.com/repositorio

• id-etsi-qcs-QcType = 0.4.0.1862.1.6.1 (Firma electrónica)

• SematicsID = 0.4.0.194121.1.2 (Persona jurídica)

Transparencia del certificado

EMPRESA Esta es una característica de EJBCA Enterprise.

Para obtener más detalles sobre la transparencia de los certificados, consulte Transparencia de los certificados

Este es un módulo de EJBCA Enterprise Edition que implementa la Transparencia de Certificados (CT), según lo especificado en la RFC 6962. El propósito de la CT es crear registros de auditoría públicos de todos los certificados emitidos por las CA públicas SSL/TLS. Se prevé que la presencia de registros de auditoría sea obligatoria para los certificados EV en Google Chrome a partir de febrero de 2015 (y posteriormente también para otros navegadores web y certificados sin EV). Tenga en cuenta que la CT solo es relevante para las CA que emiten certificados SSL/TLS públicos ; otros tipos de CA no deben usarla. Para obtener más información, consulte el sitio web de la CT .

Las siguientes opciones son visibles si el módulo CT está disponible (en EJBCA Enterprise Edition):

• Uso en certificados nuevos: durante la emisión del certificado, si EJBCA debe enviar un precertificado a los registros CT e incluir los SCT resultantes en el certificado.

• Uso en OCSP: si EJBCA debe enviar certificados y obtener SCT del registro CT durante las solicitudes de OCSP e incluir los SCT en una extensión de respuesta de OCSP.

• Usar publicadores CT: Indica si los certificados deben publicarse mediante CTCustomPublisher. Se debe crear y habilitar un publicador de tipo CTCustomPublisher en el perfil del certificado.

Dependiendo de cuáles de las opciones anteriores estén habilitadas, pueden aparecer una o más de las siguientes opciones:

• Etiquetas CT habilitadas: A qué etiquetas se enviarán y de las cuales se obtendrán las marcas de tiempo del certificado firmado (SCT). Cada etiqueta contiene un conjunto de registros CT. Se enviará al menos un registro de cada etiqueta seleccionada. Se pueden agregar nuevos registros y etiquetas en la configuración del sistema; consulte Transparencia de certificados .

• Número mínimo de SCT: si responden con un SCT menos servidores que este número, la operación subyacente fallará (emisión de certificado o generación de una extensión de respuesta OCSP).

  • Por validez: Establece automáticamente el número mínimo de respuestas SCT según la validez del certificado. Este valor se determina según la Política CT para Chrome (mayo de 2016) .

  • Personalizado: Especifica manualmente el número mínimo de respuestas SCT. Este valor no puede ser menor que el número de etiquetas seleccionadas, ya que se escribirá al menos un registro CT de cada etiqueta y se esperará una respuesta.

• Número máximo de SCT: después de haber recibido esta cantidad de SCT, EJBCA dejará de contactar a los servidores de registro.

  • Por validez: Establece el número máximo de respuestas SCT por validez, es decir, máximo = mínimo. Esto garantiza que no se incluyan más SCT de los requeridos en el certificado final.

  • Personalizado: Especifica manualmente el número máximo de respuestas SCT. Este valor no puede ser menor que el número de etiquetas seleccionadas, ya que se escribirá al menos un registro CT de cada etiqueta y se esperará una respuesta.

• Enviar certificados existentes: si los certificados existentes (definidos como aquellos que aún no tienen un SCT) deben enviarse a los registros de CT durante las respuestas o publicaciones de OCSP.

• Número de reintentos: Si un servidor de registros agota el tiempo de espera, se volverá a intentar después de que se hayan intentado todos los demás registros. Este es el número máximo de intentos por servidor.

Tipo de perfil de certificado ITS

EMPRESA Esta es una característica de EJBCA Enterprise.

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

Permisos de la aplicación

Al igual que el campo de uso de clave en los certificados X509, appPermissions define el uso previsto del certificado. ETSI, IEEE y CPOC describen valores predefinidos para esto según el uso del certificado. Por ejemplo, una credencial de inscripción ITS-S tendría appPermissions diferente a la de una CA raíz de la UE.

Permisos de emisión de certificados

Al igual que appPermissions, los permisos de emisión de certificados restringen el tipo de certificado que una CA puede emitir. Por ejemplo, un EA solo puede emitir credenciales de inscripción, pero no tickets de autorización.

Tanto appPermission como certIssuePermissions están asociados con los SSP (Permisos Específicos del Servicio). EJBCA no especifica los appPermissions de los SSP en EA y acepta el SSP solicitado por ITS-S en un Identificador de Objeto de Aplicación (AID) permitido. Especifica los valores predeterminados de SSP en la tabla 6 del Protocolo de Punto de Contacto (CPOC) de C-ITS, versión 1.2, en certIssuePermissions en la solicitud de certificado firmado de EA.

Valor de plantilla de Microsoft

El valor de plantilla de Microsoft es una extensión especial de Microsoft que se utiliza en los certificados de controlador de dominio (controlador AD). Solo debe usarse en certificados emitidos para controladores de dominio.

Extensión de seguridad de Microsoft ObjectSid

EMPRESA Esta es una característica de EJBCA Enterprise.

El uso de la extensión de seguridad Microsoft ObjectSid Permite añadir la marca szOID_NTDS_CA_SECURITY_EXT a los certificados en entornos Microsoft como mitigación de CVE-2022-26931 . Dado que la extensión se añade de forma predeterminada, todos los perfiles de certificado tienen esta configuración habilitada de forma predeterminada. Sin embargo, tenga en cuenta que la extensión solo se añade a los certificados inscritos mediante la inscripción automática de Microsoft . También es posible deshabilitar la extensión mediante la marca msPKI-Enrollment-Flag en la plantilla de Microsoft. Sin embargo, un administrador debe deshabilitarla en el perfil de certificado de la implementación actual de EJBCA. Esta marca no afecta a las operaciones donde la misma extensión esté configurada en extensiones personalizadas de EJBCA.

Lista de tipos de documentos

La extensión DocumentTypeList se utiliza para indicar los tipos de documentos (tal como se incluyen en la MRZ) que el firmante del documento correspondiente puede producir. La lista debe separarse con una coma (,). Por ejemplo: "P" o "P,ID".

Consulte el Informe técnico MRTD de la OACI sobre mantenimiento de LDS y PKI como referencia.

Número de tarjeta

Seleccione esta opción si desea utilizar la extensión de número de tarjeta SEIS. El número de tarjeta es un identificador único que se almacena en el certificado y debe imprimirse en la parte superior de la tarjeta donde se almacena. Al utilizarlo, el número de tarjeta debe configurarse para la entidad final antes de crear un certificado. La extensión se especifica en el documento Seis SS 614331, capítulo 4.3, y su OID es 1.2.752.34.2.1.

Subconjunto del DN del sujeto

Al usar un subconjunto del DN del sujeto en el certificado, puede registrar usuarios con más información que la contenida en el certificado emitido. Ejemplo:

• Utilice "Subconjunto de DN de sujeto" en un perfil de certificado, con los valores seleccionados CN, O y C.

• Registre una entidad final con "CN=Tomas Gustavsson,O=PrimeKey,OU=Ignored,C=SE" y el perfil de certificado configurado.

• Emitir un certificado utilizando el perfil de certificado.

• Emitir un certificado. El certificado emitido contendrá el DN del sujeto "CN=Tomas Gustavsson,O=PrimeKey,C=SE".

CA disponibles

Seleccione las CA autorizadas a emitir este perfil de certificado. Utilice esta configuración para permitir que determinadas CA emitan este perfil cuando se requiera que solo una CA específica lo haga. Un ejemplo de este uso es permitir que una CA raíz específica emita solo un perfil de certificado de subCA. La configuración predeterminada permite la emisión desde cualquier CA.

Restricción de certificado activo único

Este valor añade la restricción de que solo puede existir un certificado activo para una entidad final en cualquier momento. La emisión de un nuevo certificado para una entidad final que utilice esta restricción conlleva automáticamente la revocación de cualquier certificado anterior no revocado ni caducado. El motivo de la revocación se establecerá como "Reemplazado".

Espacio de nombres de enlace de cuenta

Vincular un certificado a una identidad definida fuera de EJBCA puede ser útil si desea usar un UID de una base de datos de clientes o un identificador de organización definido externamente para un certificado de dispositivo. En EJBCA, esto se puede lograr mediante vinculaciones de cuentas externas. , que permiten el envío de un valor definido externamente durante el proceso de inscripción. Los espacios de nombres se utilizan para agrupar enlaces de cuentas externas y se configuran en la configuración del sistema EJBCA; consulte Enlaces de cuentas externas .