El campo DN del sujeto junto con los campos de nombre alternativo del sujeto identifican la entidad asociada con la clave pública almacenada en el certificado.

General

Un DN de sujeto puede constar de varios componentes estandarizados, por ejemplo:

Componente	Descripción
Un certificado de firma digital personal	CN=Nombre Apellido,APELLIDO=Apellido,NOMBRE=Nombre,NÚMERO DE SERIE=213243-1234,C=SE
Un certificado de inicio de sesión de la organización	CN=Nombre Apellido,UID=nombreapellido,OU=Finanzas,O=Organización,C=DE
Un certificado de servidor web	CN=www.midominio.com
Un certificado de servidor web de validación extendida (se desaconseja el uso de CN, pero no está prohibido a partir de las Directrices EV 1.6.8, marzo de 2019)	NÚMERO DE SERIE=5566283064, OU=Infra, O=PrimeKey Solutions AB, CÓDIGO POSTAL=17163, DIRECCIÓN POSTAL=Lundagatan 16, CATEGORÍA EMPRESARIAL=Organización privada, L=Solna, País de jurisdicción=SE, C=SE
Un certificado de dispositivo IoT	CN=ID del dispositivo

EJBCA tiene un límite fijo de 400 caracteres para todo el DN del sujeto, incluyendo ciertos caracteres UTF-8 que pueden requerir dos o tres caracteres para su codificación. Si desea cambiar el límite de caracteres, modifique manualmente el tamaño de la columna subjectDN en la tabla CertificateData de la base de datos.

Para ver todos los componentes DN estándar conocidos en EJBCA, revise el archivo src/java/dncomponents.properties.sample o DnComponents,java . Diversas organizaciones crean campos nuevos ocasionalmente y, cuando es necesario, actualizan los componentes compatibles con EJBCA.

Los DN de sujeto deben estar bien formados cuando se ingresan en EJBCA, ya sea a través de una API como un servicio web, o a través de la CLI o la GUI web.

Los siguientes son ejemplos de cadenas DN mal formateadas:

No se permiten comas sin escape en los valores
- C=SE,O=Foo\\, Inc, OU=Foo, Dep, CN=Foo
- No es válido debido a la coma sin escape en 'Foo, Dep' y al carácter '-' sin escape al final.
Los signos más e igual en los valores deben escaparse
- CN=usuario\+nombre\=barra
No se permite el componente DN con una coma final.
- CN=nombre,
Todas las partes del DN deben ser legales
- APELLIDO=Json,=fff,CN=oid
- '=fff' no es válido.
No se permiten OID no válidos en los DN
- CN=NombreComún,3.3.3.3=3333Oid,O=Org
- '3.3.3.3' no es un OID válido
No se permiten componentes DN no válidos en los DN
- CN=NombreComún,K=abc,O=Org
- 'K' no es un componente DN válido

Todavía se permiten componentes DN vacíos.

'CN=' dará como resultado 'CN=' y no dará un error
Una cadena vacía, '', no es un DN válido, pero al convertir una cadena DN vacía en una cadena DN EJBCA (API), se devolverá vacío y está permitido para admitir certificados y CSR sin subjectDN (generalmente solo con un subjectAltName).

Como ejemplo de escape, este es un ejemplo de emisión de un certificado con el signo igual mediante WS. El siguiente comando se puede usar con clientToolBox:

 ./ejbcaClientToolBox.sh EjbcaWsRaCli certreq username "CN=MyName\\=12345" null ManagementCA EMPTY ENDUSER csr.pem PKCS10 PEM NONE .

Tenga en cuenta que el doble escape se debe a Java/Shell. El comando anterior genera una solicitud SOAP con un signo igual escapado:

 <S:Envelope xmlns:S= "http://schemas.xmlsoap.org/soap/envelope/" ><S:Body><ns2:certificateRequest xmlns:ns2= "http://ws.protocol.core.ejbca.org/" ><arg0><caName>ManagementCA</caName><certificateProfileName>ENDUSER</certificateProfileName><clearPwd> false </clearPwd><endEntityProfileName>EMPTY</endEntityProfileName><keyRecoverable> false </keyRecoverable><sendNotification> false </sendNotification><status> 0 </status><subjectDN>CN=MyName\= 12345 </subjectDN><username>username</username></arg0><arg1>-----BEGIN CERTIFICATE REQUEST-----
 <snip>
 -----END CERTIFICATE REQUEST-----
 </arg1><arg2> 0 </arg2><arg4>CERTIFICATE</arg4></ns2:certificateRequest></S:Body></S:Envelope> 

Orden DN del sujeto

En un certificado, el orden de los componentes DN (CN, O, C, etc.) se puede colocar en un orden diferente en el 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

Del primero al último, orden inverso: C=País, O=Organización, CN=Nombre común

Tenga en cuenta que al usar la representación de cadenas de DN, el orden real no suele mostrarse. Este orden depende de la herramienta utilizada y puede ser inverso al orden binario real. Para ver el orden binario real, se puede usar una herramienta de análisis asn1, como OpenSSL. En la práctica, el orden de los DN puede ser importante, ya que las comparaciones se realizan a menudo mediante compilaciones de cadenas, donde el valor de la cadena puede depender 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 por defecto el orden del último al primero (CN, O, C). Puede elegir el orden de DN que desea usar en los campos del perfil del certificado .

RDN multivalor

A partir de EJBCA 7.0.0, los nombres distinguidos relativos (RDN) multivalor se gestionan internamente en EJBCA. Sin embargo, los RDN multivalor no se permiten en las validaciones de perfiles de entidad final de forma predeterminada y deben configurarse para que se permitan para su uso.

Utilice RDN multivalor solo cuando tenga una razón sólida para hacerlo (requisitos de políticas de certificación o nombres únicos). Normalmente, los gobiernos federales utilizan RDN multivalor debido a sus estrictas políticas de certificación. Se recomienda evitar su uso a menos que tenga un requisito específico para implementarlo y comprenda las consecuencias.

Para limitar el riesgo de daños causados por RDN de múltiples valores, solo se permite el uso de los siguientes componentes DN en construcciones de múltiples valores, incluso si ha permitido el uso de RDN de múltiples valores en el perfil de entidad final:

Nombre común (CN)
Número de serie (SN)
Apellido (APELLIDO)
Identificador único (UID)
Nombre de pila (GIVENNAME)
Calificador DN (DN_QUALIFIER)

Sin embargo, si necesita utilizar RDN de múltiples valores, a continuación se muestran ejemplos de uso.

El primer paso es configurar el perfil de entidad final para permitir RDN de múltiples valores y agregar los campos necesarios.

Permitir RDN de múltiples valores: Verdadero
Agregue al menos CN y UID como atributos de DN del sujeto. Solo los campos disponibles en el perfil de entidad final se pueden usar en un RDN multivalor.

Si no ha habilitado los RDN de múltiples valores o no agregó los atributos DN utilizados, por ejemplo UID, recibirá uno de estos mensajes de error:

 Los datos de usuario proporcionados no cumplen con el perfil de entidad final. : El DN del sujeto tiene RDN de múltiples valores, lo cual no está permitido.

 Los datos de usuario proporcionados no cumplen con el perfil de entidad final. : Número incorrecto de campos UID en el DN del sujeto.

Emisión de certificados con RDN multivalor

Actualmente no es posible registrar entidades finales (es decir, inscribir) con las interfaces web para RDN multivalor. Si agrega una entidad final mediante, por ejemplo, la CLI, puede finalizar la inscripción (descargar el certificado) en la interfaz web, pero no podrá realizar el registro desde allí.

Puede emitir certificados con RDN de múltiples valores utilizando la mayoría de las API.

Interfaz de línea de comandos

 bin/ejbca.sh ra addendentity --username multirdn1 --dn "CN=Tomas+UID=12345,O=PK,C=SE" --caname "ManagementCA" --type 1 --token PEM
 bin/ejbca.sh ra setclearpwd multirdn1 foo123
 bin/ejbca.sh batch multirdn1
 openssl asn1parse -in p12/pem/Tomas.pem -i
:d= 3 hl= 2 l= 35 cons: SET
:d= 4 hl= 2 l= 12 cons: SEQUENCE
:d= 5 hl= 2 l= 3 prim: OBJECT :commonName
:d= 5 hl= 2 l= 5 prim: UTF8STRING :Tomas
:d= 4 hl= 2 l= 19 cons: SEQUENCE
:d= 5 hl= 2 l= 10 prim: OBJECT :userId
:d= 5 hl= 2 l= 5 prim: UTF8STRING : 12345
:d= 3 hl= 2 l= 11 cons: SET
:d= 4 hl= 2 l= 9 cons: SEQUENCE
:d= 5 hl= 2 l= 3 prim: OBJECT :organizationName
:d= 5 hl= 2 l= 2 prim: UTF8STRING :PK
:d= 3 hl= 2 l= 11 cons: SET
:d= 4 hl= 2 l= 9 cons: SEQUENCE
:d= 5 hl= 2 l= 3 prim: OBJECT :countryName
:d= 5 hl= 2 l= 2 prim: PRINTABLESTRING :SE 

API de servicio web

Un comando de clientToolBox para emitir un certificado con RDN de múltiples valores es:

 ./ejbcaClientToolBox.sh EjbcaWsRaCli certreq multirdn4 "CN=Tomas+UID=12345,O=PK,C=SE" null ManagementCA User Client csr.pem PKCS10 PEM NONE .

Lo que produce el siguiente código SOAP:

<?xml version= "1.0" ?><S:Envelope xmlns:S= "http://schemas.xmlsoap.org/soap/envelope/" ><S:Body><ns2:certificateRequest xmlns:ns2= "http://ws.protocol.core.ejbca.org/" ><arg0><caName>ManagementCA</caName><certificateProfileName>Client</certificateProfileName><clearPwd> false </clearPwd><endEntityProfileName>User</endEntityProfileName><keyRecoverable> false </keyRecoverable><sendNotification> false </sendNotification><status> 0 </status><subjectDN>CN=CN=Tomas+UID= 12345 ,O=PK,C=SE</subjectDN><username>multirdn4</username></arg0><arg1>
 ...<snip>...
 </arg1><arg2> 0 </arg2><arg4>CERTIFICATE</arg4></ns2:certificateRequest></S:Body></S:Envelope> 

CMP

Un ejemplo que utiliza el cmpclient EJBCA trabajando con un alias CMP en modo RA:

 java -jar cmpclient.jar crmf --dn "CN=Tomas+UID=12345,O=PK,C=SE" --url http: //127.0.0.1:8080/ejbca/publicweb/cmp --authparam password --reqnewkeyspec RSA2048 

API REST

Para utilizar la API REST de administración de certificados, primero se debe crear un CSR con el RDN multivalor adecuado.

 openssl req -newkey rsa: 2048 -subj "/CN=Tomas+UID=12345/O=PK/C=SE" -multivalue-rdn -nodes -out csr.pem

Y luego realiza la solicitud de API REST:

 curl -X POST "https://localhost:8443/ejbca/ejbca-rest-api/v1/certificate/pkcs10enroll" -H "accept: application/json" -H "Content-Type: application/json" --insecure --cert cert-superadmin.pem --key key-superadmin.pem -d "{ \"certificate_request\": \"-----BEGIN CERTIFICATE REQUEST-----\nMIIChDCCAWwCAQAwPzEjMAwGA1UEAwwFVG9tYXMwEwYKCZImiZPyLGQBAQwFMTIz\nNDUxCzAJBgNVBAoMAlBLMQswCQYDVQQGEwJTRTCCASIwDQYJKoZIhvcNAQEBBQAD\nggEPADCCAQoCggEBANH1SrgN3q/yt7Ebf9HIeJQHtxhIO6zdLbQIHhXkp3BWT2Lb\ncxOhejt2oN6FGab1vB4xHFkXpDQDfX+3Rx5hboDBd2hfsDMK6HGEihrc0gtq9jpr\nAWtbeXeR/sKLol9cVT7/tGKzWM7cyac/aotaaeXpQlrq+fV4wKqLEs4ivrKZb8yy\nd6BYLX18alnoRTZO18YlwrseaoGsWjoECTbu9Jc4vSbXKTxoxRRHBpp7zdFmY2x3\neFA6w8T5dwwEDa3Xo2hbz9diKZ+sicJMMrKgBnkv9OsK4qs2YX1gq6Ii1yrCLSf9\nFvj3goawmQlZjOcX+z89otW2dVC1Ha5oW5yn3QUCAwEAAaAAMA0GCSqGSIb3DQEB\nCwUAA4IBAQBD3MFg0e31gFn/+whfqU7uVgIQLl1M8X32wQ0ouyb0pbA/OSnHbZQF\nsAQi6aIaEBDT1ZLMVNOjBKy7GdBrBpyvApIKMIaghB9Xi8BEL7wvS9oG370XxG4k\nIrVWMdfbdAvKZXpvnu2VrlCZsqt+G0gLvI2gpRMiamdkc/luhzCmCeGOQGKEJ/36\nzuz1ATLry7kPA118G0j7YZj78LImGlJTv3nWd9AA/VgC5vPauutfHN/3Cho3ghUH\ndgPgHiQMz57cQv4VVwkj5IOWrhgcm+d4scJNyRdYWQ1SaB0AA+iSzZxVGB6Oe0ww\nVQEmeF9s5sNmHiZrFDJTvOOK3Q5OBY4f\n-----END CERTIFICATE REQUEST-----\", \"certificate_profile_name\": \"Client\", \"end_entity_profile_name\": \"User\", \"certificate_authority_name\": \"ManagementCA\", \"username\": \"multirdn5\", \"password\": \"foo123\"}"

Uso de RDN multivalor para administradores

Puede usar certificados con RDN multivalor como certificados de administrador en EJBCA de forma estándar, donde los componentes se contabilizan por separado. Por ejemplo, para agregar el certificado con el DN "CN=Tomas+UID=123456" a un rol, puede usar:

Coincide con: CN
Valor de coincidencia: Tomás
o
coincide con: UID
valor de coincidencia: 12345

Uso de un subconjunto de DN de sujeto con RDN de múltiples valores

La emisión de certificados mediante la función "Subconjunto de DN de sujeto" en los perfiles de certificado podría no funcionar correctamente al usar RDN multivalor. Al usar esta función, el RDN multivalor se divide en RDN de un solo valor. Si envía un RDN "CN=Tomas+UID=12345", el resultado será:

Cuando solo se selecciona CN como Asunto del Asunto DN: CN=Tomas
Cuando solo se selecciona UID como Asunto del DN del Asunto: UID=12345
Cuando se seleccionan tanto CN como UID como Sujeto del Sujeto DN: CN=Tomas, UID=12345 (este ya no es un RDN multivalor)

Publicación de RDN multivalor en LDAP

No se ha probado la publicación LDAP con RDN de múltiples valores.