MAC OSX provides the ability to access external directories for authentication or contact information via LDAP with the Directory Utility application. With the Tiger release, 10.4, this just seemed to work. With the recent release of Leopard, 10.5, many people have had trouble getting LDAP directory access working over SSL. This article explains how to do it.

I am using Novell eDirectory as the LDAP directory for authentication, but the same principles should apply for any LDAP directory service.

Here’s the problem: the TLS/SSL handshake between the Apple LDAP client and the LDAP directory server is failing and aborting the operation. The Apple Directory Utility Application and the underlying openLDAP/openSSL framework is not honoring the Apple system keychain (the system certificate store).


The Apple Directory Utility application uses openLDAP/openSSL, and these require some extra configuration.

The configuration file for openLDAP is /etc/openldap/ldap.conf. The directive TLS_REQCERT { never | allow | try | demand } was defaulted to “never” for Tiger OS 10.4, which is why it worked. Under Tiger the certificate was not checked, and the operation proceeded without question. In Leopard OS 10.5 the default is “demand”, which will request and check the veracity of the certificate before allowing the operation to proceed.

Setting TLS_REQCERT to ‘never’ or ‘allow’ will make directory access work as it did in OS 10.4, but you shouldn’t need to weaken security to get things to work. To get things working as they should, follow these steps.

1. Import your directory CA certificate as a trusted CA in the openSSL certificate framework.

2. Edit /etc/openldap/ldap.conf to use the openSSL certificate store with the TLS_CACERTDIR directive.

3. Configure your LDAP directory server in DNS and use a DNS based certificate for the LDAP server.

4. Configure the Directory Utility application to use the DNS name of your LDAP server.

WOW – it looks simple when I write it like that, considering the effort required to work it out …

I actually spent the most time stuck at step 3. In my test environment I hadn’t configured DNS for my LDAP server and was using an IP based certificate. The openLDAP documentation states “The DN of a server certificate must use the CN attribute to name the server, and the CN must carry the server’s fully qualified domain name.” usually I would take that to mean ‘or IP address’ but in this case it appears they mean it.


Here are the steps to follow, in more detail:

1. Export the self-signed CA certificate of your LDAP directory (or the CA that signed the server certificate you are using) and convert it to PEM format. I did this by adding the CA cert to the the Apple System Keychain and then exporting the certificate in PEM format.

For the next step, make sure you are at a terminal with root access.

2. Copy ca_cert.pem to the openSSL certificate store:

cp ca_cert.pem /System/Library/OpenSSL/certs

In order for OpenSSL to find the certificate, it needs to be looked up as its hash. Normally, you would create a symbolic link for a meaningful name of the CA to the hash value, rather than renaming the CA certificate. The symbolic link must be for the hashed value above, plus “.0” If you forget the “.0” then OpenSSL won’t detect it.

3. Find the hash value of the certificate:

openssl x509 -noout -hash -in ca_cert.pem

This will output a number which is a hash of the name and serial number of the certificate.

Create a symbolic link to the ca_cert.pem as <hash>.0 (for example, 5432ac1f.0)

ln -s ca_cert.pem 5432ac1f.0

Your LDAP directory CA is now installed as a trusted CA in the openSSL framework.

4. Edit /etc/openldap/ldap.conf to look something like this:

# LDAP Defaults
# See ldap.conf(5) for details
# This file should be world readable but not world writable.
#URIldap:// ldap://
REFERRALS       off
TLS_CACERTDIR /System/Library/OpenSSL/certs
# Specifies the path of a directory that contains Certificate Authority certificates in separate
# individual files. The TLS_CACERT is always used before TLS_CACERTDIR.

5. Configure your LDAP directory server in DNS and use a DNS based certificate for the LDAP server. For Novell eDirectory, make sure the LDAP server object is configured to use the “SSL CertificateDNS”.

6. Configure the Apple Directory Utility application to use the DNS name of your LDAP server that matches the server certificate CN.


  • LDAP Directory access over SSL
  • eDirectory all versions
  • LDAP client MAC OS 10.5 Leopard
0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this post.
Categories: Uncategorized

Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment.  It just worked for at least one person, and perhaps it will be useful for you too.  Be sure to test in a non-production environment.

Leave a Reply

Leave a Comment

  • anonymous says:

    Firstly, this article contains some great information which solved my problem making a Ruby-ldap ssl connection to eDirectory.

    However, it may not be correct concerning the behaviour of Directory Access.

    As far as I can see Directory Access uses the Apple CDSA (Common Data Security Architecture) framework, which is part of Darwin and open source. CDSA uses certificates available in the operative keychains (user and or system). See

    I can make ssl connections to edirectory on Leopard via Directory Assistance or Java without any of the measures in this article, as long as there is an appropriate trusted CA certificate in the keychain.

    Ruby OpenSSL however uses the openssl library, and does need the operations described in the Cool Tip to get it working.

    So perhaps the title and/or keywords for the Tip should be changed.

    Bill Northcott

  • anonymous says:

    Just to mention that step 3 can be accomplished more easily.

    Just cd to the directory containing the certificate and type:

    This invokes a nifty PERL script that creates the symlinks for you.

Nov 21, 2007
8:02 am
Active Directory Authentication Automation Cloud Computing Cloud Security Configuration Customizing Data Breach DirXML Drivers End User Management Identity Manager Importing-Exporting / ICE/ LDIF Intelligent Workload Management IT Security Knowledge Depot LDAP Monitoring Open Enterprise Server Passwords Reporting Secure Access Supported Troubleshooting Workflow