Subject Distinguished Names

The subject DN field together with the subject alternative name fields identifies the entity associated with the public key stored in the certificate. A subject DN can consist of a number of standardized components, for example:

Component

Description

A personal digital signature certificate

CN=Firstname Lastname,SURNAME=Lastname,GIVENNAME=Firstname,SERIALNUMBER=213243-1234,C=SE

An organization login certificate

CN=Firstname Lastname,UID=firstnamelastname,OU=Finance,O=Organization,C=DE

A web server certificate

CN=mydomain.com

An extended validation web server certificate

CN=www.primekey.com,SERIALNUMBER=5566283064,OU=Infra,O=PrimeKey Solutions AB,POSTALCODE=17163,STREETADDRESS=Lundagatan 16,BUSINESSCATEGORY=Private Organization,L=Solna,jurisdictionCountry=SE,C=SE

An IoT device certificate

CN=DeviceID

To view all known, standard, DN components in EJBCA, inspect the file src/java/dncomponents.properties.sample or DnComponents,java. New fields are occasionally invented by various organizations, and when needed the supported components in EJBCA are updated.

Subject DNs must be well formed when entered into EJBCA, whether it is via an API such as Web Service, or via the CLI, or Web GUI.

The following display examples of badly formatted DN strings:

  • Non-escaped commas are not allowed in values

    • C=SE,O=Foo\\, Inc, OU=Foo, Dep, CN=Foo

    • Is not valid due to the non-escaped comma in 'Foo, Dep' and the non-escaped '-character in the end.'

  • Plus- and equal signs in values must be escaped

    • CN=user\+name\=bar

  • DN component with a trailing comma is not allowed.

    • CN=name,

  • All parts of the DN must be legal

    • SURNAME=Json,=fff,CN=oid

    • '=fff' is not valid.

  • Invalid OIDs are not allowed in DNs

    • CN=CommonName,3.3.3.3=3333Oid,O=Org

    • '3.3.3.3' is not a valid OID

  • Invalid DN components are not allowed in DNs

    • CN=CommonName,K=abc,O=Org

    • 'K' is not a valid DN component

Empty DN component parts are still allowed.

  • 'CN=' will result in 'CN=' and not give an error

  • An empty string, '', is not a valid DN, but when converting an empty DN string to an EJBCA DN String (API), it will return empty, and is allowed in order to support certificates and CSRs with no subjectDN (usually only with a subjectAltName).

Multi-value RDNs

As of EJBCA 7.0.0, multi-value RDNs are handled internally in EJBCA. However, multi-value RDNs are not allowed in End Entity Profile validations by default and must be configured to be allowed in order to be used.

Do not use multi-value RDNs unless you have a strong legacy reason to do so. There is generally no reason to use multi-value RDNs and they can cause issues in your systems. It is recommended to avoid using multi-value RDNs, even if you think it is a neat idea.

If you nevertheless have to use multi-value RDNs, the following displays a usage example:

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
135:d=3 hl=2 l= 35 cons: SET
137:d=4 hl=2 l= 12 cons: SEQUENCE
139:d=5 hl=2 l= 3 prim: OBJECT :commonName
144:d=5 hl=2 l= 5 prim: UTF8STRING :Tomas
151:d=4 hl=2 l= 19 cons: SEQUENCE
153:d=5 hl=2 l= 10 prim: OBJECT :userId
165:d=5 hl=2 l= 5 prim: UTF8STRING :12345
172:d=3 hl=2 l= 11 cons: SET
174:d=4 hl=2 l= 9 cons: SEQUENCE
176:d=5 hl=2 l= 3 prim: OBJECT :organizationName
181:d=5 hl=2 l= 2 prim: UTF8STRING :PK
185:d=3 hl=2 l= 11 cons: SET
187:d=4 hl=2 l= 9 cons: SEQUENCE
189:d=5 hl=2 l= 3 prim: OBJECT :countryName
194:d=5 hl=2 l= 2 prim: PRINTABLESTRING :SE

To limit the risk of damage, only the following DN components are allowed to be used in multi-value constructs, even if you have allowed usage of multi-value RDNs in the end entity profile:

  • Common Name (CN)

  • Serial number (SN)

  • Surname (SURNAME)

  • Unique Identifier (UID)

  • Given name (GIVENNAME)

  • DN Qualifier (DN_QUALIFIER)

Subject DN Order

In a certificate, the order of the DN components (CN,O,C etc) can be placed in a different order in the binary encoded certificate.

  • Last-to-first, forward (historically called LDAP DN Order in EJBCA): CN=Common Name, O=Organization, C=Country

  • First-to-last, reverse order: C=Country, O=Organization, CN=Common name

Note that when using string representation of DNs, the actual order is usually not displayed. The order displayed is determined by the tool being used and may be the reverse of the real binary order. To see the actual binary order, an asn1 parsing tool can be used, such as OpenSSL. In practice, the DN order can be important because comparisons are often made using string compilations, where the string value may be dependent on the order.

The most common order is first-to-last (i.e. C,O,CN), but for historical reasons EJBCA by default uses last-to-first (CN,O,C). You can choose which DN Order to use in the Certificate Profile.