Introduction to LDAP

The Lightweight Directory Access Protocol (LDAP) is a de facto standard protocol for accessing X.500 directories. See https://tools.ietf.org/html/rfc2251 .

An LDAP directory contains hierarchically sorted objects. An object is derived from one or many preconfigured object classes, which determines the set of allowed attributes the object may contain. An object may have children objects or children nodes, that is, other objects sorted hierarchically underneath it.

LDAP queries - search filter syntax

For a complete description of the LDAP search filter syntax, see https://tools.ietf.org/html/rfc2254 .

objectClass

All LDAP objects include an attribute called "objectClass". The value(s) of this attribute tells what set of other attributes (mandatory or optional) you can expect from this particular LDAP object.

This search filter returns all objects that have inherited the object class "pkiCA":

(objectClass=pkiCA)

Wild cards

To return all objects in the directory, the search filter would be (objectClass=*).

Logical operators

You can use logical operators to create a compound search filter:

And: ( & <search filter 1> <search filter 2> ... )
Or: ( | <search filter 1> <search filter 2> ... )

Example:

The following search returns all persons having a name beginning with "Simon", and a telephone number, that directs the call to Sweden or UK:

(&(cn=Simon*)(|(telephonenumber=+46 *)(telephonenumber=+44 *)))

Consult your directory schema to find out the exact abbreviations to use. In the example above, "cn" stands for "common name".

LDAP URL format

For a complete description of the LDAP URL format, see https://tools.ietf.org/html/rfc2255 .

The LDAP URL format looks as follows. Use this in the OCSP configuration file when doing LDAP configurations.

CODE

<protocol>://<host>[:<port>]/<base dn>?<attributes>?<scope>?<filter>?<extensions>

Any of the components to the right of the colon is optional and can be left out.

See this table for description of constants and values:

Constants and values	Description
`<protocol>`	Replace `<protocol>` with ldap or ldaps. When using LDAP over TLS (LDAPS), the directory's server certificate must be successfully validated by Nexus OCSP Responder.
`<host>[:<port>]`	Replace `<host>` with the location of the LDAP server. Replace `<port>` with the non-standard port to which the LDAP server will listen.
`<base dn>`	Replace `<base dn>` with the entry in the directory where to begin the search.
`<attributes>`	Replace `<attributes>` with the attribute(s) to download. For Nexus OCSP Responder, the attributes of interest are revocation lists and certificates. The exact attribute name may vary depending on the configuration of the LDAP server, but these are typically names: certificateRevocationList for full CRLs deltaRevocationList for delta CRLs userCertificate for user certificates
`<scope>`	Specifies how to search and can be set to one of three values: sub base one See https://tools.ietf.org/html/rfc2255 for details.
`<filter>`	Specifies the search filter to use. See "Search filter” above.
`<extensions>`	See https://tools.ietf.org/html/rfc2255 for details.

Example 1

This search returns the attribute telephonenumber from the "John Doe" object in the directory located at "ldap.net".

CODE

ldap://ldap.net/cn=John Doe,o=Nexus,c=SE?telephonenumber

Example 2

This search returns all the CRLs from the Nexus LDAP directory:

CODE

ldap://directory.nexus.com/?certificateRevocationList?sub

Example 3

This search returns all CA certificates from all CAs, whose names include "Nexus".

CODE

ldap://ldaphost/?cACertificate?sub?(&(objectClass=pkiCA)(cn=*Nexus*))

LDAP Certificate patterns

A special syntax called "certificate pattern" is used when referring to a particular certificate in the configuration file (see "Specify keys" in Key management section.) The certificate pattern syntax is based on the LDAP search filter syntax, with the operator placed before the argument list and each argument enclosed in parentheses.

A simple pattern is of the form <key>=<value>. The value may contain wild cards (* or ?). See also Distinguished name matching.

The key refers to a Relative Distinguished Name (RDN) of the subject. If Nexus OCSP Responder is able to find such an RDN, <value> will be matched against this one. Otherwise, the check will result in "false".

For certain keys, the match will be performed as follows:

Key	Certificate information match
`issuer`	`<value>` is matched against the full Issuer Distinguished Name.
`subject`	`<value>` is matched against the full Subject Distinguished Name.
`dn`	Equivalent to "`subject`".
`serialNumber`	`<value>` is compared to the certificate serial number. You may use decimal or hexadecimal notation. Hexadecimal notation shall begin with 0x.
`keyUsage`	`<value>` is compared by name to the flags that are set in the certificate's Key Usage extension. The names of the flags are: `digitalSignature` `nonRepudiation` `keyEncipherment` `dataEncipherment` `keyAgreement` `keyCertSign` `cRLSign` `encipherOnly` `decipherOnly`

Several patterns can optionally be grouped together to produce complex patterns. The following operators are supported:

Operator	Example
And	&(<pattern 1>)(<pattern 2>) ...
Or	\|(<pattern 1>)(<pattern 3>)...
Not	<pattern4>)

Example 1:

Find all certificates issued to John Doe:

CODE

cn=John Doe

Example 2:

Find John Doe's certificate(s) issued by Acme CA:

CODE

&(cn=John Doe)(issuer=cn=Acme CA,o=Acme Inc.,c=NL)

Example 3:

The following two searches are equivalent:

CODE

&(cn=JohnDoe)(|(keyusage=keyencipherment)(keyusage=dataencipherment))
&(subject=*cn=John Doe,*)(keyusage=*cipherment)

Related information

Configure Nexus OCSP Responder
Nexus OCSP Responder
RFC 2251 Lightweight Directory Access Protocol (v3):
- https://tools.ietf.org/html/rfc2251
RFC 2254 The String Representation of LDAP Search Filters:
- https://tools.ietf.org/html/rfc2254
RFC 2255 The LDAP URL Format:
- https://tools.ietf.org/html/rfc2255