Marcos Ares Troubleshooting Weblog

I recently played around with a DPS6/DS6 topology consisting in:

* 1 DPS 6.0 instance
* 2 DS 6.0 instances (DS1 and DS2)
* SSL ports defined for the DPS and DS.
* DPS configured to ALWAYS use SSL to connect to the DS.
* Suffix "o=Test" created in both DS.
* Default Connection Handler used. No new connection handler defined.
* Data Sources, Data Source Pool and Data View defined.

Immediately after setting this topology up, I got my first suite of unpleasant messages on the DS backend access logs (they do not necessarly cause a service disruption, they can be simply informational, but they are indicators of an unfinished configuration):

[17/May/2007:11:13:12 +0200] conn=0 op=-1 msgId=-1 - fd=23 slot=23 LDAPS connection from 129.157.192.152:58321 to 129.157.192.152
[17/May/2007:11:13:12 +0200] conn=0 op=-1 msgId=-1 - SSL 128-bit RC4; client CN=beyonce:3000; issuer CN=beyonce:3000
[17/May/2007:11:13:12 +0200] conn=0 op=-1 msgId=-1 - SSL failed to map client certificate to LDAP DN (No such object)

What these messages do exactly mean?
They mean that the DS could not check the certificate sent by the SSL client (in our scenario, that would be the DPS)

Why is this check required?
When a server receives a request from a client, it can ask for the client's certificate before proceeding. The client sends its certificate to the server. After checking that a client certificate chain ends with a trusted CA, a Directory Server can optionally determine which user is identified by the client certificate and then look up that user's entry in the directory. The server authenticates the user by comparing the information in the certificate with the data in the user's directory entry. After the server finds a matching entry and certificate in the directory, it can determine the appropriate kind of authorization for the client. For example, some servers use information from a user's entry to determine group membership, which in turn can be used during evaluation of ACIs to determine what resources the user is authorized to access. You can also configure client authentication between an instance of Administration Server and another iPlanet Directory Server.

Where can I learn more about certificate mapping?
http://sunsolve.holland.sun.com/search/printfriendly.do?assetkey=1-9-77262-1

So what did I do to remove the "mapping failure" messages?
1) First, I created a new self-signed certificate inside the DPS with the following subject DN:

CN=beyonce:3000,O=test

this can be done using dpadm or the DSCC console. Then configured the DPS to use this new certificate for all connections towards the DS backends.

2) Second, I exported the new certificate from the DPS certificate DB:

# pwd
/opt/SUNWdsee/dps6/bin
# dpadm show-cert -F ascii /data/PTS/DPS/6.0/ mapped-default > /tmp/dpsCert

3) Import the exported certificate inside both the DS backends (note how the Subject DN will change to "CN=beyonce:3000,O=test" after the import is executed):

# pwd
/opt/SUNWdsee/ds6/bin
# dsadm list-certs -C /data/PTS/DS/6.0 | grep beyonce
defaultCert 2007/05/14 19:39 2007/08/14 19:39 n CN=beyonce,CN=2345,CN=Directory Server,O=Sun Microsystems Same as issuer
dpsCert 2007/05/17 12:35 2009/05/16 12:35 n CN=beyonce:3000 Same as issuer
# dsadm remove-cert /data/PTS/DS/6.0 dpsCert
# dsadm add-cert -C /data/PTS/DS/6.0 dpsCert /tmp/dpsCert
# dsadm list-certs -C /data/PTS/DS/6.0 | grep beyonce
defaultCert 2007/05/14 19:39 2007/08/14 19:39 n CN=beyonce,CN=2345,CN=Directory Server,O=Sun Microsystems Same as issuer
dpsCert 2007/05/17 14:10 2009/05/16 14:10 n CN=beyonce:3000,O=test Same as issuer
#
# dsadm list-certs -C /var/opt/SUNWdsee/dsins1 | grep beyonce
defaultCert 2007/05/14 18:30 2007/08/14 18:30 n CN=beyonce,CN=1636,CN=Directory Server,O=Sun Microsystems Same as issuer
dpsCert 2007/05/17 12:35 2009/05/16 12:35 n CN=beyonce:3000 Same as issuer
# dsadm remove-cert /var/opt/SUNWdsee/dsins1 dpsCert
# dsadm add-cert -C /var/opt/SUNWdsee/dsins1 dpsCert /tmp/dpsCert
# dsadm list-certs -C /var/opt/SUNWdsee/dsins1 | grep beyonce
defaultCert 2007/05/14 18:30 2007/08/14 18:30 n CN=beyonce,CN=1636,CN=Directory Server,O=Sun Microsystems Same as issuer
dpsCert 2007/05/17 14:10 2009/05/16 14:10 n CN=beyonce:3000,O=test Same as issuer

4) Add the following entry in both DS backends (the attribute userCertificate contains the binary value of the certificate exported in step 2 above):

# cat cert.ldif
dn: cn=beyonce:3000,o=test
objectclass: extensibleObject
usercertificate:: MIIBvjCCAScCBEZMRigwDQYJKoZIhvcNAQEEBQAwJjENMAs[..skipped..]
#
# ./ldapmodify -a -D "cn=Directory Manager" -w secret12 -p 1234 -f cert.ldif
adding new entry cn=beyonce:3000,o=test
#
# ./ldapmodify -a -D "cn=Directory Manager" -w secret12 -p 1389 -f cert.ldif
adding new entry cn=beyonce:3000,o=test

5) Change certmap.conf to reflect the proper mapping. The certmap.conf final content should look like this in my case:

# pwd
/data/PTS/DS/6.0/alias
# tail -10 certmap.conf
#
certmap default default
default:DNComps cn, o
default:verifycert on
#default:DNComps
#default:FilterComps e, uid
#default:verifycert on
#default:CmapLdapAttr certSubjectDN
#default:library
#default:InitFn

6) Restart DS backends servers and verify the access log does no longer report the certificate mapping failure!