Okay — this seemed like a lot harder than it should have been. At the very least, it took piecing together information from a number of places in order to make it happen. The goal is to use a Go Daddy Turbo SSL Secure Certificate (the $19.95/year one) to secure an OpenLDAP server. On the surface, this shouldn’t be so hard. The tricky part comes because the requested SSL cert is not signed by a recognized Certificate Authority root; instead, Go Daddy uses an intermediary certificate and the tricky part is making sure the whole chain of SSL certificates line up properly. There is a wealth of documentation for using intermediary certificates with web servers, but I found very little for OpenLDAP servers. I hope by posting this into the blogosphere you will find it useful someday, too.
The servers are running the Gentoo distribution of Linux. The critical bits out of portage are OpenLDAP (version 2.3.24-r1), OpenSSL (version 0.9.8c), nss_ldap (version 249), and pam_ldap (version 180). On Monday I’m going to ask OhioLINK’s resident Redhat Fedora Core expert to try the equivalent on that distribution. (I’ve put him through so much trouble already that I hope this process goes smoothly from here on out.) You’ll need to get all of those and their prerequisites installed and configured on your machine. There is a and another on the Debian Wiki plus other documents out there to help you get started. When you’ve had enough fun beating your head up against that wall and have got basic LDAP-based account management to work, you can come back here.
I picked the Go Daddy Turbo SSL Secure Certificate because, well, it’s cheap. As their own marketing literature says — why pay a couple hundred dollars for something when Go Daddy will give you the equivalent thing for $19.95? To be completely fair, Go Daddy offers two types of certificates: the Turbo SSL one that we’ll be using and the High-Assurance Secure Certificate. The difference is in the verification process. The former verifies only the domain name and control of that domain name by sending e-mail to the WHOIS administrative contact to confirm that the certificate request is legitimate. The latter is a manual verification process that looks at the domain name and control of that domain name as well as verifies identity of requesting person or company and the authority to make request. The latter is probably overkill for our uses and costs $89.99.
So go through the modestly convoluted process of generating the Certificate Signing Request (CSR), giving Go Daddy your $19.95, requesting the certificate, have the request approved by your DNS zone administrator, receive the e-mail of the signed certificate from Go Daddy, and then come back here.
OpenLDAP’s ‘slapd.conf’ Server Setup
So here is the really tricky part (where “tricky” is defined as the piece that took me the longest to figure out). As I said in the introduction, Go Daddy uses an intermediary certificate to form a chain from one of the highly-trusted root certificates. The key to making this work becomes getting the intermediary certificate into the evaluation chain at the right time so the client can see it an trust the server. It is possible to install the intermediary certificate on all of the clients who might someday make use of our server’s certificate, but we would, ideally, like the server to offer the client the certificate and let the client do all of the cryptology to determine whether the server can be trusted. This section describes what it takes to make that happen.
First, one has to go to the Go Daddy Secure Certificate Services Repository. Many of the directions I found for getting the intermediary certificate working with web servers said to download the intermediate certificate alone (or, as Go Daddy calls it, the
sf_issuing.crt file). I found this didn’t work — rather, the “Root Bundle” (or
ca_bundle.crt file) is what is needed.
[Updated 20070904T1104 : It looks like Go Daddy changed their certificate chain last month. What you need now is called "gd_bundle.crt" from the Go Daddy certificate repository -- you'll find it under the heading "New Go Daddy Certificate Chain" (at least that is where you'll find it today).]
Then add this to your
TLSCipherSuite HIGH:MEDIUM:+SSLv2# Your signed CSR that you got back from Go DaddyTLSCertificateFile /etc/ssl/certs/ldap.ohiolink.crt# The private key file for the certificateTLSCertificateKeyFile /etc/ssl/certs/ldap.ohiolink.key# The "Root Bundle" file from Go Daddy's Certificates RepositoryTLSCACertificateFile /etc/ssl/certs/ca_bundle.crt
Next, move onto the client side. (Your LDAP server also has the client libraries installed — you’ll likely want to start there.)
OpenLDAP’s ‘ldap.conf’ Client Setup
In case you haven’t discovered it by now, there are two — count ‘em, two —
ldap.conffiles on your box. One is read by tools derived from the OpenLDAP package and the other is for the pam_ldap/nss_ldap combination. And to make things even more interesting — the syntax of the files are not the same! Boy, sometimes I really dislike the profession I’m in…
So let’s start with OpenLDAP’s
ldap.conf file; you’ll likely find this in the
/etc/openldap directory. (At least that is where you’ll find it with Gentoo — YMMV.) In that file, you’ll want to put these pieces:
You’ll, of course, want to replace the BASE and URI parameters with the ones most appropriate for your installation. I’ve found that third line to be somewhat unexpectedly important, however. The OpenLDAP libraries need to know where to go to find the trusted root certificates, and so you need to specify the path where they exist on your system. These got installed with OpenSSL, which you needed back in “The Certificate” stage when you generated the CSR. Again, these are in
/etc/ssl/certs on a typically-configured Gentoo box; you might find them elsewhere in other distributions.
NSS/PAM’s ‘ldap.conf’ Client Setup
This is the other
ldap.conffile, and on a Gentoo system you’re likely to find it in the
/etcdirectory. Remember — the file name is the same but the directives are different. You’ll use much of the knowledge from the previous section here…you’ll just need to change the preceding labels:
See the similarity?
sslpath, and so forth. There will likely be much more in this file —
nss_base_passwd, and more. Follow a more comprehensive set of directions to get those pieces right.
To test to see if the SSL certificate is really securing the connection, you can use the
-ZZparameter (to force an SSL/TLS interaction with the server) on
ldapsearchwith the debugging level set in order to see some of the protocol interaction. I find that this command is most instructive:
ldapsearch -d 9 -ZZ -h ...ldap.server.address.net...
You can scroll back and make sure that the SSL/TLS-secured connection was, in fact being used. You can also turn up debugging on the server and look at the server log files to verify the same thing.
So there you go. I hope you find this useful. I also hope that if you find it in error, you’ll let me know. (Although, at the moment, this does seem to be working for us. Perhaps it only works because I have faith that it will work. If so, please be gentle when you tell me I’ve made an error… )
The text was modified to update a link from http://wiki.debian.org/OpenLDAPSetup to http://wiki.debian.org/LDAP/OpenLDAPSetup on January 19th, 2011.(This post was updated on 27-Aug-2012.)