CERTMAP.CONF(5)

💖 CERTMAP.CONF(5) — the file formats manual glow-up 💖

okay bestie, so this is the manual page for /etc/dirsrv/config/certmap.conf — a File Formats Manual situation, and honestly it's giving "tiny config file, huge responsibility." Let's get into it. 🦋

---

✨ NAME ✨

/etc/dirsrv/config/certmap.conf — the configuration file for TLS client authentication in 389 Directory Server.

Like, that's it. That's the whole name. Short, sweet, does exactly what it says on the tin. 👑

---

✨ SYNOPSIS ✨

/etc/dirsrv/config/certmap.conf

no args, no flags, just a path. it's a file. she just exists. 💅

---

✨ DESCRIPTION ✨

so certmap.conf is the file that configures how a certificate is mapped to an LDAP entry. that's the whole vibe.

if you want the deep lore, the actual documentation says to go here:

https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/configuration_command_and_file_reference/configuration_file_reference#certmap_conf

(ngl bestie, that's a long URL, but it's the one they gave us so we're keeping it exactly. 📎)

---

✨ SYNTAX ✨

here's the format of the file, fr fr:

certmap <name> <issuerDN>
<name>:<prop1> [<val1>]
<name>:<prop2> [<val2>]

now the notes, because there are four of them and we are not skipping a single one, periodt:

1. Mapping can be defined per issuer of a certificate. If mapping doesn't exist for a particular issuerDN, then the server uses the default mapping. (so it's like, if your specific fit isn't in the closet, you borrow the default one. 🎀)
2. There must be an entry for <name>=default and issuerDN "default". This mapping is the default mapping. no default entry = we have a problem.
3. '#' can be used to comment out a line. yes queen, comment your heart out.
4. DNComps & FilterComps are used to form the base DN and filter responsible for performing an LDAP search while mapping the certificate to a user entry. those two are the main characters of this whole file, iykyk.

---

✨ OPTIONS ✨

🫶 DNComps

The DNComps parameter determines how Directory Server generates the base DN used to search for a user in the directory. This setting accepts a comma separated list of attributes to form a DN. However — and this is the important part — the order of the attributes in the DNComps parameter must match the order in the subject of the certificate.

For example, if your certificate's subject is "e=user_name@example.com,cn=user_name,o=Example Inc.,c=US", and you want Directory Server to use "cn=user_name,o=Example Inc.,c=US" as the base DN when searching for the user, set the DNComps parameter to "cn, o, c".

Comment out or do not set this parameter if either the subject field of the certificate matches exactly the DN of the user in Directory Server, or if you want to use the setting from the CmapLdapAttr parameter.

If the value is empty, it will search the entire LDAP tree by using the FilterComps parameter. (whole tree?? okay she's thorough. 🌈)

🫶 FilterComps

This parameter sets which attributes from the subject field of the certificate Directory Server uses to generate the search filter to locate the user.

Set this parameter to a comma-separated list of attributes used in the certificate's subject. Directory Server will use these attributes in an AND operation in the filter.

Note — Certificate Subjects use the e attribute for the email address, which does not exist in the default Directory Server schema. For this reason, Directory Server automatically maps this attribute to the mail attribute. This means, if you use the mail attribute in the FilterComps parameter, Directory Server reads the value of the e attribute from the subject of the certificate.

For example, if the subject of a certificate is "e=user_name@example.com,cn=user_name,dc=example,dc=com,o=Example Inc.,c=US" and you want to dynamically generate the "(&(mail=username@domain)(cn=user_name))" filter, set the FilterComps parameter to "mail, cn".

If the parameter is commented out or set to an empty value, the (objectclass=*) filter will be used. (that's the "search literally everything" filter, lowkey iconic 💀)

🫶 verifycert

Directory Server always verifies if the certificate has been issued by a trusted Certificate Authority (CA). However, if you additionally set the verifycert parameter to on, Directory Server additionally verifies that the certificate matches the Distinguished Encoding Rules (DER)-formatted certificate stored in the userCertificate binary attribute of the user.

If you do not set this parameter, verifycert is disabled.

🫶 CmapLdapAttr

If your user entries contain an attribute that stores the subject DN of the user certificate, set the CmapLdapAttr to this attribute name. Directory Server will use this attribute and the subject DN to locate the user. In this case, no filter is generated based on the attributes in the FilterComps parameter.

---

✨ EXAMPLES ✨

here's the moment you've been waiting for, the actual example block, verbatim bestie, no edits:

certmap default         default
default:DNComps         cn, o, c
#default:FilterComps    e, uid
#default:verifycert     on
#default:CmapLdapAttr   certSubjectDN

certmap example         o=Example Inc.,c=US
example:DNComps

see how the # lines are just... vibing there, commented out? that's note 3 in action. slay. 🧚

---

✨ AUTHOR ✨

certmap.conf was written by the 389 Project. legends only. 👑

---

✨ REPORTING BUGS ✨

found a bug? (rude of it, honestly.) report bugs to:

https://github.com/389ds/389-ds-base/issues/new

go tell them, they'll fix it. 🐛

---

✨ COPYRIGHT ✨

Copyright © 2018 Red Hat, Inc.

---

and that's the whole page, bestie!! this was the File Formats Manual entry for CERTMAP.CONF(5), dated Jun 26, 2018, brought to you with love from the 389 Project. go map some certs. you're gonna do amazing. mwah 💋✨🦋🎀💖