- Setting Up the Directory Server and the Certificate Server
- Generating an SSL Server Certificate
- Generating an SSL Client Certificate
- Setting Up the Appropriate Trust Relations
- Enabling SSL for the Sun ONE Directory Server Software
- Setting Up LDAP/SSL Server Authentication
- Setting Up LDAP/SSL Client Authentication
- Successful and Secure Installation
- Acknowledgments
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Setting Up LDAP/SSL Client Authentication
Client authentication is desirable if you want to make sure that only authorized clients can access the directory server. There are two authentication steps:
SSL client authentication
LDAP BIND authentication
For SSL client authentication, the LDAP server checks the validity of the certificate presented by the client. If the SSL client is successfully authenticated, an LDAP BIND operation is performed. The following credentials are accepted for this operation:
BIND DN and BIND PASSWORD (through ldapsearch options -D and -w)
SSL Certificate's subject DN without checking the certificate
SSL Certificate's subject DN with checking the certificate
The following procedures describe how to perform password-based and certificate-based BIND operations together with SSL client authentication.
Performing SSL Client Authentication and Password-Based BIND Operation
Use the LDAP client certificate generated in the section , "Generating an SSL Server Certificate."
To Perform SSL-Client Authentication
Force the LDAP server to trust the CA that signed the client certificate (that is adding iNIT8 CA to the list of trusted certificate issuers).
Double-click on the directory server sunshine.init8.net from the sun ONE console.
Select Manage Certificates from the task list.
Click CA Certs, in the wizard window.
You will see a list of valid CA certificates similar to the list in the Netscape browser. iNIT8 Certificate Manager's certificate is not yet present.
Obtain the certificate by contacting the Sun ONE Certificate Server software at https://sunshine.init8.net
Go to "Retrieval".
Select the Sun ONE Certificate Server software certificate (CN=iNIT8 Certificate Manager, OU=CERT, O=iNIT8, L=Hamburg, ST=HAMBURG, C=DE) and copy the Base64 encoding to the clipboard.
Select Install... from the certificate wizard and paste the Base64 text block into the text box.
Click Next twice. When asked for the intended purpose, select Accepting connections from clients.
The certificate should now be present in the CA Cert list.
Tell the LDAP server to accept/force client authentication.
Go to the Encryption window of the Sun ONE Directory Server software sunshine.init8.net.
Select Require client authentication, and save the settings.
Restart the server from the Solaris OE shell.
Perform SSL client authentication with LDAP BIND based on username/password by issuing:
bash-2.03# /opt/iplanet/server5/shared/bin/ldapsearch -h sunshine.init8.net -p 636 -Z -N "LDAP Client's iNIT8 ID" -K /.netscape/key3.db -P /.netscape/cert7.db -D "cn=Directory Manager" -w "dirmanager" -W manager1 -b "o=init8.net" "uid=*" -v version: 1 dn: uid=EHobbit,ou=People, o=init8.net dn: uid=LHelm,ou=People, o=init8.net dn: uid=steffo,ou=People,o=init8.net
NOTE
The previous example assumes that there is a user with a DN cn=Directory Manager. If you do not have such a user, use another DN. Check the ACIs on the directory subtree, if the previous example fails.
Submitting a bind DN with a password is secure in the above example, since the transmission of the credentials is protected by the encryption mechanisms used during the SSL session.
Performing SSL Client Authentication and Certificate-based BIND Operation
It is assumed that you are able to get successfully authenticated by a password-based BIND operation and an SSL client authentication.
To Use the SSL Client Certificate as Credentials Rather Than a Username/Password Pair For the LDAP BIND Operation
There are two options:
Let the LDAP server grant or deny access based solely on the Subject entry of the SSL certificate.
Let access be granted or denied by comparing the client's certificate, presented during the SSL session initialization, against a certificate which is stored in the client's LDAP entry stored in the directory.
In both cases, the server must be able to map the information stored in the Subject entry of the certificate to an LDAP entry. The mapping is defined in a file called certmap.conf that resides in:
$LDAPHOME/shared/config/certmap.conf
The verifycert parameter controls what options become active. In this example, the file contains the following entry:
certmap init8 CN=iNIT8 Certificate Manager, OU=CERT, O=iNIT8, L=Hamburg, ST=HAMBURG, C=DE init8:DNComps o init8:FilterComps uid #init8:verifycert on #init8:CmapLdapAttr certSubjectDN #init8:library <path_to_shared_lib_or_dll> #init8:InitFn <Init function's name>
It is crucial that the string CN=iNIT8 Certificate Manager, OU=CERT, O=iNIT8, L=Hamburg, ST=HAMBURG, C=DE is identical to the issuer string of the certificate.
NOTE
You must restart the LDAP server after modifying certmap.conf.
For the following examples based on access being granted or denied by comparing the client's certificate against a certificate, the ACIs are modified for the iNIT8-subtree as follows:
ACI for anonymous access is removed.
ACI for a user uid=steffo,ou=People,o=init8.net is added:
(targetattr = "*") (version 3.0; acl "LDAP Client Access"; allow (all) (userdn = "ldap:///uid=steffo,ou=People, o=init8.net") ;)
Perform a BIND operation based solely on the Subject entry:
bash-2.03# ./ldapsearch -h sunshine.init8.net -p 636 -Z -N "LDAP Client's iNIT8 ID" -K /.netscape/key3.db -P /.netscape/cert7.db -W manager1 -b "o=init8.net" "cn=*" version: 1 dn: cn=Directory Administrators, o=iNIT8 objectClass: top objectClass: groupofuniquenames cn: Directory Administrators
NOTE
A successful client authentication depends inherently on the certmap.conf. If you have a slightly different directory information tree, things can look different. Check $LDAPHOME/slapd-sunshine/log/errors and $LDAPHOME/slapd-sunshine/log/access for errors.
The corresponding entries in the access log look as follows:
[04/Apr/2002:14:35:04 -0100] conn=2 op=6 MOD dn="o=init8.net" [04/Apr/2002:14:35:05 -0100] conn=2 op=6 RESULT err=0 tag=103 nentries=0 etime=1 [04/Apr/2002:14:35:11 -0100] conn=3 fd=33 slot=33 SSL connection from 129.157.157.161 to 129.157.157.228 [04/Apr/2002:14:35:11 -0100] conn=3 SSL 128-bit RC4; client E=steffo@init8.net, CN=LDAP Client, UID=steffo, OU=People, O=iNIT8; issuer CN=iNIT8 Certificate Manager, OU=CERT, O=iNIT8, L=Hamburg, ST=HAMBURG, C=DE [04/Apr/2002:14:35:11 -0100] conn=3 SSL client bound as uid=steffo,ou=People,o=init8.net [04/Apr/2002:14:35:11 -0100] conn=3 op=0 BIND dn="" method=sasl version=3 mech=EXTERNAL [04/Apr/2002:14:35:11 -0100] conn=3 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=steffo,ou=People,o=init8.net" [04/Apr/2002:14:35:11 -0100] conn=3 op=1 SRCH base="o=init8.net" scope=2 filter="(cn=*)" attrs=ALL [04/Apr/2002:14:35:11 -0100] conn=3 op=1 RESULT err=0 tag=101 nentries=6 etime=0 [04/Apr/2002:14:35:11 -0100] conn=3 op=2 UNBIND [04/Apr/2002:14:35:11 -0100] conn=3 op=2 fd=33 closed - U1
NOTE
The BIND DN matches the subject of the certificate.
In order to perform an LDAP BIND operation that compares the certificates, the LDAP server must hold the client's certificate in which the public key is stored.
In this example, the user is called LDAP Client.
From the Sun ONE console, add the attribute usercertificate to the user's entry (Sun ONE Console—Directory—Users—LDAP Client—Properties (right mouse button)—Advanced—Add Attribute).
The Add Attribute dialog opens.
To make sure that the transportation mode of the usercertificate attribute is binary, in the Add Attribute dialog, select the subtype Binary.
After adding the attribute, you have to add an attribute value in the Property Editor window. Obtain the value from ~/certs/ldap-client.bin (the file you generated in the section , "Generating an SSL Server Certificate") in the file selector box.
Test whether the certificate can be found by submitting the following LDAP query:
bash-2.03# /opt/iplanet/server5/shared/bin/ldapsearch -h sunshine.init8.net -p 389 -b "o=init8.net" "cn=*"
The output is:
dn: uid=steffo,ou=People,o=init8.net mail: steffo@init8.net objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson givenName: LDAP cn: LDAP Client uid: steffo sn: Client usercertificate;binary::MIIC3TCCAkagAwIBAgIBDDANBgkqhkiG9w0BAQQF ADB0MQswCQYDVQQGEwJERTEQMA4GA1UECBMHSEFNQlVSRzEQMA4GA1UEBxMHSG FtYnVyZzEOMAwGA1UEChMFaU5JVDgxDTALBgNVBAsTBENFUlQxIjAgBgNVBAMT GWlOSVQ4IENlcnRpZmljYXRlIE1hbFnZXIwHhcNMDIwMTEzMTExNjI1WhcNMDM wMTEzMTExNjI1WjCBijELMAkGA1UEBhMCREUxDjAMBgNVBAoTBWlOSVQ4MRYwF AYDVQQLEw1TcGVjaWFsIFVzZXJzMRcwFQYKCZImiZPyLGQBARMHTENsaWVudDE UMBIGA1UEAxMLTERBUCBDbGllbnQxJDAiBgkqhkiG9w0BCQEWFWxkYXAtY2xpZ W50QGluaXQ4Lm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqfgnYy3 XbZfZWNSqEoazLADnsTT55y7q+8GocDrAhSj/XqUXfY0AoztAMA1WCKujE/ bTllxjFvGiTn5zGxMy4d75kZIzk+McixP53RK++q6rIefzOjjGMqXh4qYwzMhW AyeRWy4x8UWfslsECikxZWu3UjlB+wmwqQ3EdV+1Y0CAwEAAaNoMGYwEQYJYIZ IAYb4QgEBBAQDAgWgMA4GA1UdDwEBwQEAwIF4DAfBgNVHSMEGDAWgBQENPvZQV U2jW3BWnOoIVOo+PLJBjAgBgNVHREEGTAXgRVsZGFwLWNsaWVudEBpbml0OC5u ZXQwDQYJKoZIhvcNAQEEBQADgYEANZeAlIYS3TqWOK8YvNNfY71zI5xElzolkd qHqz+cPOCX2pX98YVM1Snx85nKcSddEn67wSnJhhgwhf1KS8Og+4WVCUoepzCK x8ulajciZlqCvUX2OSasVLJ9UHjYbp4qu7sti21EtgkdCLGsKU0jVpHFswil7m ERpaiKq6Kgno=
As in the previous example, map the Subject entry to an LDAP entry by using the file certmap.conf.
Then tell the server to compare the certificate presented during the establishment of the SSL session against the certificate stored in the user's LDAP entry. This is done by setting the verfifycert parameter to on. The following example contains the content of the certmap.conf file.
certmap init8 CN=iNIT8 Certificate Manager, OU=CERT, O=iNIT8, L=Hamburg, ST=HAMBURG, C=DE init8:DNComps o init8:FilterComps uid init8:verifycert on #init8:CmapLdapAttr certSubjectDN #init8:library <path_to_shared_lib_or_dll> #init8:InitFn <Init function's name>
Again, it is crucial that the string CN=iNIT8 Certificate Manager, OU=CERT, O=iNIT8, L=Hamburg, ST=HAMBURG, C=DE is identical to the issuer string of the certificate.
Perform a BIND operation based on the certificate's Subject entry:
bash-2.03# ./ldapsearch -h sunshine.init8.net -p 636 -Z -N "LDAP Client's iNIT8 ID" -K /.netscape/key3.db -P /.netscape/cert7.db -W manager1 -b "o=init8.net" "cn=*" version: 1 dn: cn=Directory Administrators, o=init8.net objectClass: top objectClass: groupofuniquenames cn: Directory Administrators
The server verifies the certificate and access is granted only after successful verification.
The access log looks as follows:
[04/Apr/2002:15:00:09 -0100] conn=1 fd=29 slot=29 SSL connection from 129.157.157.161 to 129.157.157.228 [04/Apr/2002:15:00:09 -0100] conn=1 SSL 128-bit RC4; client E=steffo@init8.net, CN=LDAP Client, UID=steffo, OU=People, O=init8.net; issuer CN=iNIT8 Certificate Manager, OU=CERT, O=iNIT8, L=Hamburg, ST=HAMBURG, C=DE [04/Apr/2002:15:00:09 -0100] conn=1 SSL client bound as uid=steffo,ou=People,o=init8.net [04/Apr/2002:15:00:09 -0100] conn=1 op=0 BIND dn="" method=sasl version=3 mech=EXTERNAL [04/Apr/2002:15:00:09 -0100] conn=1 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=steffo,ou=People,o=init8.net" [04/Apr/2002:15:00:09 -0100] conn=1 op=1 SRCH base="o=iNIT8" scope=2 filter="(cn=*)" attrs=ALL [04/Apr/2002:15:00:09 -0100] conn=1 op=1 RESULT err=0 tag=101 nentries=6 etime=0 [04/Apr/2002:15:00:09 -0100] conn=1 op=2 UNBIND [04/Apr/2002:15:00:09 -0100] conn=1 op=2 fd=29 closed - U1