Nombre de usuario

El valor Nombre de usuario representa un identificador único para una entidad final (usuario, servidor, dispositivo, etc.). Al agregar una entidad final, el nombre de usuario puede configurarse manualmente o generarse automáticamente. Al seleccionar la casilla "Generado automáticamente" en el perfil de la entidad final, se generarán valores únicos al agregar entidades finales. El campo de entrada Nombre de usuario permite configurar un prefijo para el nombre de usuario de la entidad final.

Contraseña

Las contraseñas se utilizan cuando un usuario (entidad final) solicita un certificado o genera un almacén de claves. Normalmente, esto es obligatorio y no se configura ningún valor predeterminado. Cuando la contraseña solo se utiliza durante el proceso de solicitud, se denomina código de registro en la web de RA, ya que solo es válida una vez y no se utiliza para proteger las claves. Tenga en cuenta que no hay diferencia entre un código de registro y una contraseña , salvo el nombre.

Puede utilizar la generación automática de contraseñas con notificaciones por correo electrónico para enviar al usuario una contraseña generada junto con información sobre cómo obtener el certificado.

También puede especificar la seguridad mínima de bits que puede tener una contraseña para facilitar el cumplimiento de las políticas. La seguridad de una contraseña se calcula como

piso (( el número de caracteres de la contraseña )* registro ₂ ( número de caracteres de contraseña permitidos ))

Para las contraseñas no generadas, el número de caracteres de contraseña permitidos se estima en 72.

Ejemplo de uso:

 Password: "foobar123" (9 characters) Allowed characters: az, AZ, 0-9, 22 additional printable characters (72 in total) Password strength / char: log2(72) = 6.17 Password strength: floor(6.17 * 9) = floor(55.53) = 55 bits

Si se establece este valor en 55, el administrador de RA deberá establecer una contraseña de 9 caracteres o más.

Correo electrónico de la entidad final

Al seleccionar "Usar" , las entidades finales inscritas podrán especificar su correo electrónico, mientras que el campo de texto del perfil de la entidad final permite a los administradores proporcionar un dominio predeterminado. Al seleccionar la opción "Requerido" en el campo "Correo electrónico de la entidad final" , todas las entidades finales inscritas deberán especificar un correo electrónico. Al seleccionar "Modificable" , las entidades finales inscritas podrán modificar el dominio de correo electrónico, mientras que al desactivar esta opción, las entidades finales solo se vinculan a ese dominio.

Descripción del perfil

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

Campos DN del sujeto

Para obtener información sobre los nombres distinguidos de sujeto en general, reglas de nomenclatura y ejemplos, consulte Nombres distinguidos de sujeto .

Los campos DN del sujeto definen qué componentes DN deben estar presentes en una entidad final. Si la opción de configuración del sistema "Habilitar limitaciones del perfil de entidad final" está habilitada, se restringen los valores que se pueden usar al agregar o editar una entidad final mediante todas las interfaces, ya sea la interfaz web, el servicio web, CMP u otra. Si define valores como obligatorios y no modificables, puede especificar uno o más. Si especifica varios valores separados por ";", el administrador en la interfaz web mostrará un menú desplegable para seleccionar.

En el campo Validación, puede restringir la entrada permitida mediante una expresión regular (regex). EJBCA utiliza la sintaxis de patrones de Java , similar a la de las expresiones regulares de Perl. La coincidencia distingue entre mayúsculas y minúsculas por defecto, pero esto se puede cambiar añadiendo (?i) delante de la expresión regular. A continuación, se muestran algunos ejemplos:

• [0-9]+ solo permite dígitos y no comodines

• [0-9A-Za-z]+ permite dígitos, solo letras en inglés, sin espacios y sin comodines.

• [0-9A-Za-z ]+ permite dígitos, solo letras en inglés, espacios y ningún comodín

• .+@.+ permite cadenas que contengan "@", por ejemplo, direcciones de correo electrónico

• [a-zA-Z0-9+._-]+@[a-zA-Z0-9.-]+ permite direcciones de correo electrónico solo con caracteres en inglés

• [a-zA-Z0-9+._-]+@yourdomain\.com solo permite correos electrónicos de un dominio específico

• [a-zA-Z0-9._-]+\.yourdomain\.com solo permite subdominios de yourdomain.com (pero no yourdomain.com en sí) o comodines (*)

• ([a-zA-Z0-9._-]+\.)?yourdomain\.com permite yourdomain.com con o sin subdominio y sin comodín (*)

• Un ejemplo de expresión regular para validar nombres de dominio es:

  ^(\*.)?(((?!-))(xn--)?[a-z0- 9 -]{ 0 , 61 }[a-z0- 9 ]{ 1 , 1 }\.)*(xn--)?([a-z0- 9 \-]{ 1 , 61 }|[a-z0- 9 -]{ 1 , 30 }\.[az]{ 2 ,})$

Al tener varios campos de un mismo tipo con campos obligatorios y no obligatorios combinados, podría ser necesario un manejo especial al agregar usuarios mediante la API de servicios web. Por ejemplo, si tiene:

• El primer campo OU es obligatorio (Bar1) y no se puede modificar.

• Los siguientes 3 campos de OU son únicamente modificables (no obligatorios).

• La última OU es obligatoria (Bar1) y no se puede modificar.

Entonces, si se agrega una entidad final con DN "CN=Foo,OU=Bar1,OU=Bar2" se obtendrá un error como el siguiente:

Esto se debe a que EJBCA no puede registrar los campos que desea configurar, ya sean obligatorios o no obligatorios. Para ayudar a EJBCA a determinar esto, puede especificar los campos de OU no obligatorios con valores vacíos: " CN=Foo,OU=Bar1,OU=,OU=,OU=,OU=Bar2 ".

Hay un campo DN de tema en particular que merece información adicional: postalAddress .

La dirección postal no se codifica como una cadena, sino como una secuencia ASN.1 . Si solo introduce el valor como cadena, se codificará como una cadena UTF-8 simple, lo cual no es válido. Debe introducirlo como una cadena de directorio ASN.1 con codificación hexadecimal. Esto se realiza codificando hexadecimalmente el objeto ASN.1 y anteponiéndolo con #, por ejemplo, #30.

Nombres alternativos del sujeto

Los nombres alternativos de sujeto (altNames) son elementos de nombre adicionales que no son adecuados para el nombre distinguido, como correo electrónico, DNS, dirección IP, etc. Hay varios estándares y la posibilidad de definir nombres especiales, lo que muchas empresas han hecho para altNames como MS UPN, GUID, Krb5PrincipalName.

Los nombres alternativos del sujeto pueden ser: rfc822Name=<correo electrónico>, dNSName=<nombre de host>, uri=< http://host.com/ >, ipaddress=<dirección>, upn=<UPN de MS>, guid=<ID único global de MS>, directoryName=<DN de escape LDAP>, krb5principal=<nombre principal de Krb5>, permanentIdentifier=<valores del identificador permanente>, subjectIdentificationMethod=<valores o parámetros del método de identificación del sujeto>

Los campos de texto y las opciones para los nombres alternativos de sujeto generalmente funcionan de manera similar a los campos DN de sujeto .

Validez del certificado

Al configurar la hora de inicio y la hora de finalización de la validez del certificado, puede especificar con precisión, para una entidad final específica, cuándo el certificado comenzará a ser válido y cuándo dejará de ser válido.

Al seleccionar la hora de inicio o de fin de la validez del certificado, podrá introducir estos campos al añadir una nueva entidad final. También puede especificar un valor predeterminado para el perfil de la entidad final. En la página del perfil de la entidad final se ofrecen ejemplos de diferentes formatos para especificar el tiempo de validez.

Esta función requiere la función 'Permitir anulación de validez' en el Perfil de certificado.

Motivo de revocación a establecer después de la emisión del certificado

Con esta opción puede definir que al agregar un nuevo usuario, el estado de revocación de un certificado emitido se pueda establecer inmediatamente en algo distinto de 'Activo'.

Esto es útil si desea emitir certificados en espera para los usuarios. Una vez que el usuario recibe el certificado, es posible que deba realizar alguna acción para activarlo.

Más útil cuando se utiliza en combinación con OCSP, ya que requerirá, en la práctica, una verificación de revocación instantánea.

Al habilitar esta opción en el perfil, se mostrará la selección correspondiente al añadir nuevos usuarios. Los datos de usuario correspondientes a esta opción son el atributo ExtendedInformation: ExtendedInformation.CUSTOM_REVOCATIONREASON.

Notificaciones por correo electrónico

EJBCA utiliza un servicio de correo en el servidor de aplicaciones para enviar correos electrónicos. Puede configurar los datos que se incluirán en las notificaciones y eventos de correo electrónico para activar su envío. Para obtener más información, consulte Notificaciones por correo electrónico .

Verificaciones inversas de nombres alternativos de sujeto DN

No se recomienda usar esta casilla en operaciones normales. Al usar la RA externa y configurar más de un tipo de campo DN en el perfil (por ejemplo, una unidad organizativa opcional y una obligatoria), podría ser necesario marcar esta casilla para que la validación del perfil funcione.

Úselo solo en casos especiales si nada más funciona. Esta opción podría eliminarse en el futuro.

Permitir la fusión de DN en todas las interfaces

Si la información del perfil de la entidad final debe usarse para definir valores predeterminados al crear un usuario, debe seleccionarse la opción " Permitir fusionar DN en todas las interfaces" en dicho perfil. Al habilitar esta opción y crear o actualizar una entidad final, el DN transferido se fusionará con los valores predeterminados del perfil. Esta configuración es válida para todos los protocolos (a partir de EJBCA 7.9.0) y, por lo tanto, funciona con cualquier método de servicio web, interfaz de CA, interfaz de RA, interfaz REST, etc., y protocolos como ACME, EST, CMP, etc. Por ejemplo, si el perfil de la entidad final tiene valores predeterminados para O=PrimeKey y C=SE , y la llamada WS editUser establece el DN del usuario en CN=Donald Duck , el DN de la entidad final añadida a EJBCA será CN=Donald Duck,O=PrimeKey,C=SE .

Esta función es compleja, por lo que presenta algunas limitaciones. Gestiona varios campos de un tipo específico, por ejemplo , OU , y se recomienda limitar su uso a los campos recomendados, es decir, usar un CN , nunca usar un DN Email (ya que no debería hacerlo en ningún caso), etc. Verifique el funcionamiento antes de usarla. Algunos casos de uso típicos:

• Perfil de entidad final con valor predeterminado: OU=OrgUnit , agregar entidad final (con WS) con DN de asunto CN=Nombre de usuario,O=Org,C=SE → el DN de entidad final resultante es CN=Nombre de usuario,OU=OrgUnit,O=Org,C=SE

• Perfil de entidad final con valor predeterminado: OU=OrgUnit,OU=OrgUnit2 , agregar entidad final (con WS) con DN de asunto CN=Nombre de usuario,O=Org,C=SE → el DN de entidad final resultante es CN=Nombre de usuario,OU=OrgUnit,OU=OrgUnit2,O=Org,C=SE

• Perfil de entidad final con valor predeterminado: OU=OrgUnit , O=Org2 , C=SE agregar entidad final (con WS) con DN de asunto CN=Nombre de usuario → el DN de entidad final resultante es CN=Nombre de usuario, OU=OrgUnit, O=Org2, C=SE

• Perfil de entidad final con valor predeterminado: OU=Org1,OU=Org2,OU=,OU=,C=SE agrega entidad final (con WS) con DN de asunto CN=Nombre de usuario,OU=Org3,OU=Org4 → el DN de entidad final resultante es CN=Nombre de usuario,OU=Org1,OU=Org2,OU=Org3,OU=Org4,C=SE

La opción "Permitir fusión de DN en todas las interfaces" hereda la configuración de " Permitir fusión de DN para servicios web" de EJBCA anterior a EJBCA 7.9.0. Para obtener más información, consulte " Configuración del comportamiento de los servicios web" .

Permitir RDN de múltiples valores

Esta configuración permite el uso de RDN de múltiples valores como se describe en Nombres distinguidos de sujeto .

Número máximo de intentos de inicio de sesión fallidos

Al seleccionar un número máximo de intentos fallidos de inicio de sesión, el estado del usuario cambiará a GENERADO si se introduce una contraseña incorrecta más de la cantidad especificada. Tenga en cuenta que lo que se denomina "contraseña" en la web de administración suele denominarse "código de registro" en la web de RA. La opción "Usar " debe estar seleccionada para que las entidades finales utilicen esta función. Si se selecciona "Modificable" , el número especificado se puede cambiar para una entidad final específica al crearla o posteriormente editándola.

Datos de extensión de certificado personalizado

Al marcar la opción Usar para datos de extensión de certificado personalizado en el perfil de entidad final, se proporciona un área de texto al agregar o editar una entidad final para proporcionar datos de extensión de certificado personalizado.

Los datos de extensión se introducen en el área de texto con el mismo formato que para los archivos de propiedades de Java, es decir, normalmente clave=valor, con una entrada por línea. Los datos de extensión aceptados o requeridos dependen de las extensiones personalizadas seleccionadas en el perfil de certificado como "Extensiones de certificado personalizadas utilizadas" y de su configuración.

Por ejemplo, las extensiones personalizadas del tipo BasicCertificateExtension configuradas con la propiedad dynamic=true aceptan datos de extensión personalizada en el formato 'OID.value=value', donde OID es el OID de la extensión configurada y value es el valor que se colocará en la extensión en la codificación configurada.

Para obtener más información sobre las extensiones y la configuración disponibles, consulte Extensiones de certificado personalizadas .

A continuación se muestra un ejemplo de configuración de una extensión de certificado que toma un valor dinámico en formato codificado hax RAW:

Si la solicitud (Datos de extensión) contiene extensiones que no pueden coincidir con ninguna extensión de certificado personalizado configurada en EJBCA, se rechazará la emisión.

Declaración de control de calidad ETSI PSD2

Si se utilizan declaraciones de control de calidad PSD2, seleccionar la opción "Declaración de control de calidad ETSI PSD2" permite la creación de entidades finales que contienen declaraciones de certificado cualificado PSD2. Además, esta configuración permite la entrada de NCAName, NCAId y roles TPP.

Para obtener más información, consulte Declaración de certificado calificado PSD2 en Campos de perfil de certificado.

Identificador de la organización del foro CA/B

El identificador de organización del foro CA/B también debe estar habilitado en el perfil del certificado para que el campo aparezca en los certificados emitidos. En el perfil de entidad final, al seleccionar este campo se habilita la entrada de datos según lo especificado en las Directrices del foro CA/B para la emisión y gestión de certificados de validación extendida , sección 9.8.2. Se convertirá en una extensión de certificado.

Ejemplos:

• NTRGB-12345678 (esquema NTR, Gran Bretaña, identificador único a nivel de país: 12345678)

• NTRUS+CA-12345678 (Esquema NTR, Estados Unidos - California, el identificador único a nivel estatal es 12345678)

• VATDE-123456789 (Régimen de IVA, Alemania, Identificador único a nivel de país: 12345678)

• PSDBE-NBB-1234.567.890 (Esquema PSD, Bélgica, el identificador de la NCA es NBB, el identificador único de sujeto asignado por la NCA es 1234.567.890)

Número de solicitudes permitidas

Al seleccionar "Usar" para el número de solicitudes permitidas, se habilita la posibilidad de solicitar varios certificados seguidos sin que el estado del usuario se configure como "generado". Normalmente, tras usar un par de nombre de usuario y contraseña para generar un certificado, el estado del usuario cambia de "nuevo" a "generado". Esto invalida la contraseña, implementando así un esquema de contraseñas de un solo uso. Al seleccionar un número mayor que uno para el "número de solicitudes permitidas", el usuario puede solicitar varios certificados antes de que el estado se configure como "generado". Esto permite inscribir varios certificados directamente, por ejemplo, uno de autenticación y otro de firma.

El número de solicitudes permitidas en el perfil de entidad final establecerá el valor predeterminado y máximo disponible al agregar o editar una nueva entidad final. Al editar una entidad final existente y cambiar su estado a nuevo, el número de solicitudes permitidas se ajustará automáticamente al valor predeterminado del perfil. Si el perfil de entidad final utilizado ya no utiliza el número de solicitudes permitidas, el contador de solicitudes de la entidad final se eliminará al editarla.

Permitir renovación antes del vencimiento

Normalmente, EJBCA solo permite la emisión de una entidad final cuando está en estado NUEVO. Con la opción Permitir renovación antes del vencimiento habilitada, los certificados pueden renovarse incluso en estado GENERADO, cuando están a punto de vencer. El campo de texto controla el número de días (medidos en periodos de 24 horas, no días naturales) antes del vencimiento que se debe permitir la renovación.

Tokens disponibles

A continuación se enumeran los diferentes tokens disponibles en EJBCA.

Restricciones de campos del complemento

Los administradores pueden desarrollar más restricciones de campos de usuario personalizados utilizando FieldValidator como se describe en Modificación de EJBCA .