SSL and LDAP in Leopard

Be careful what you wish for, you just might get it... 

Starting with Leopard the OS X LDAP client is much more restrictive about which SSL certificates it trusts. It will adamantly refuse to use any cert you have explicity told it is ok. Technically this is a deeper issue with anything using OpenSSL, but chances are you'll notice it first, and hardest, with LDAP. 

Making this even more complicated is the idea that the new behavior is more secure than the old 10.4 behavior, so it's rather hard to get too angry about the change. However, things not working makes an admin cranky regardless of the bigger picture.

Read on for how to troubleshoot this and then how to work with it or around it. 

The Change

The difference between 10.4 and 10.5 lies entirely in /etc/openldap/ldap.conf. Where before it used to say

TLS_REQCERT = never

now it says

TLS_REQCERT = demand

This change means that the underlying ldap client will only use SSL certificates that it thinks are valid dropping the connection attempt if it thinks the cert is bad. So, what constiutes a valid cert?

Out of the box... nothing. The LDAP client trusts no one. Even if you actually paid for your SSL certificate and you have no issues when you use it to secure a website, the LDAP client will still refuse it. Annoyingly the GUI, in this case Directory Utility, will happily show you a green dot next to your server, it's just that it won't actually be used. If you require binding and SSL, that should fail as well.

While this is annoying if you didn't expect it, I find it hard to argue that it was a bad move. Without validating a site against its own certificate left the client systems open to something as simple as a DNS poisoning attack. So I do feel that this is a good thing, but it cetainly does take a bit more work to get things functioning. 

Test via the CLI

The easiest way to test what exactly is going on is to use the ldapsearch command to verify if you're able to connect or not. This assumes that you've first set up OD and enabled SSL for LDAP, either using the default certificate on the server or one you've configured yourself.

ldapsearch -v -x -H ldaps://biggie.afp548.com -b "dc=biggie,dc=afp548,dc=com"

Substituting in your correct server FQDN and search domain. This should fail on a stock 10.5 install with this error.

ldap_bind: Can't contact LDAP server (-1)

    additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Fairly self-explanatory, at least to what the error is. So now how to fix it.

Get the Cert

You're going to need to feed the cert to the LDAP client so that it knows to trust it. While it's possible to do this via exporting the cert from the server itself it's typically easier to use the "openssl s_client" to snarf the cert.

openssl s_client -connect biggie.afp548.com:636

Which should come back with a deluge of information for you. Within that is going to be a dozen or more lines that are blocked off by:

-----BEGIN CERTIFICATE-----

and

-----END CERTIFICATE-----

Take that text, including the begin certificate and end certificate lines and paste them into a text file. A CLI text editor would be best for this to ensure that you don't accidentally save it as a .rtf or something funky like that.

For purposes of demonstration we'll assume that you've saved the cert to /tmp/ssl.cert.

Note: you should get an error number 18 or 19 when using the s_client. This refers to either a self-signed certificate, 18, or a self-signed certificate in the chain, 19. Keep this in mind as the next step should clear this out.

BTW, control-c to get out of the s_client connection.

Test the Cert

Now that you have the cert sequestered into a text file you can test again with s_client manually specifying the certificate.

openssl s_client -connect biggie.afp548.com:636 -CAfile /tmp/ssl.cert

Which should display similar output to before, however, with a significant change to the last line:

Verify return code: 0 (ok)

Instead of either the 18 or 19 that you were getting before. This means that you've successfully managed to get openssl to be happy with the certificate that you're using on the remote server. So now to make LDAP as happy...

Edit ldap.conf

You are going to need to add a new line to /etc/openldap/ldap.conf that points to the certificate you've just pulled down. I tend to keep things tidy here and create a /etc/openldap/certs folder and then just copy the text file that we got before into there. Here we'll assume you renamed the file the name of the server and put it into this location.

After moving the cert you can add one line into /etc/openldap/ldap.conf

TLS_CACERT    /etc/openldap/certs/biggie.afp548.com

Now retest with the ldapsearch command and see if it works.

ldapsearch -v -x -H ldaps://biggie.afp548.com -b "dc=biggie,dc=afp548,dc=com"

Should actually return an LDIF of your whole LDAP setup, so this may take a while. Trim down the search if you want.

Ensuring OD Works

At this point you should be able to join and use an SSL-secured OD setup via Directory Utility. So please do that at this time. You may need to kick Directory Services if you had already attempted to setup the LDAP server.

sudo killall DirectoryService

Securing a Collection of Certs

The method above will only allow that one specific server, with that one specific cert to be trusted. If you have multiple LDAP servers you're working with you're going to need to specify those individually, or put them all in the same directory and point ldap.conf towards them. Here's how to do the later.

• Grab all of the certs as before using openssl s_client.

• Now you're going to have to use another OpenSSL utility to get the certs into a hashed format.For each cert you will run the it through c_hash which will give you a name that you'll need to rename the cert file to.
  

	/System/Library/OpenSSL/misc/c_hash /etc/openldap/certs/biggie.afp548.com

	03be8eb2.0 => /etc/openldap/certs/biggie.afp548.com

            In this example you'd rename your existing cert file to 03be8eb2.0

• Then you can add

	TLS_CACERTDIR     /etc/openldap/certs/

            to your /etc/openldap/ldap.conf file.

• Probably best to remove any earlier TLS_CACERT directives you have in ldap.conf at this time as well.
  

On the Other Hand

You could revert the ldap.conf file back to the 10.4 behavior and be done with all this...

Keychains

Note that while it would certainly make most of the pain go away, OpenSSL and therefor the LDAP libraries have no concept of what a keychain is. So, no, importing the certs into your keychain won't do anything for the LDAP issue. 

Other Notes

You will never be able to use the default certificate that comes with OS X Server  without changing TLS_REQCERT back to never. The default certificate isn't configured with a hostname so it will never pass an integrity check.

As mentioned by Mr. McCune in the comments, you may also want to investigate pointing ldap.conf to the default trusted root store that is included with curl on OS X.

TLS_CACERT /usr/share/curl/curl-ca-bundle.crt

Which should allow you to use a purchased certificate without having to do additionaly mods to ldap.conf.