I am unable to connect with my openserver system using SSL/TLS connection.

There are no issues communicating without SSL on port 389 and can connect and retrieve directory information without issue.

However, when using port 636 and expecting secure communications the connection fails to connect.

The below openssl connection attempt details the trace which would indicate that no ssl connection is being established.

Example output from openssl attempting to connect

The following image is from ServerAdmin indicating that SSL is enabled and a certificate has been provided for the server connection.

ServerAdmin Configuration

The port 636 is open on the ldap server, and no firewall is between the two hosts.

sauce:Java frank$ netstat -an | grep 636
tcp6       0      0  *.636                  *.*                    LISTEN
tcp4       0      0  *.636                  *.*                    LISTEN

A telnet connection to port 636 on the server succeeds indicating that there are no firewall issues in play.

Can anybody provide any additional items to check to identify and correct the cause of this issue?

  • What is the Server OS and what is the client's OS you are using?
    – Andrew U.
    Commented May 6, 2014 at 11:02
  • Server OS is snow-leopard, client os for test purposes is linux
    – sweetfa
    Commented May 6, 2014 at 23:28
  • SSL handshake has read 0 bytes and written 319 bytes : this seems like it might be a firewall issue. Check that the port is open, and try disabling the firewall. You can also check which ports are open by using netstat -na. Commented May 7, 2014 at 7:14
  • Another thought: Apple's well known TCP and UDP ports lists TCP port 625 as "Open Directory Proxy (ODProxy)", which "maintains incoming proxy connections to the local opendirectoryd(8) daemon", whatever that means. Maybe try port 625 instead? Commented May 7, 2014 at 7:18

1 Answer 1


The following were the steps I took to resolve this issue:

Reboot the server in safe mode (hold down shift key whilst restarting)

Let it idle for a while (apparently it is cleaning out caches in this mode)

Stop the existing slapd server

 sudo launchctl unload /System/Library/LaunchDaemons/org.openldap.slapd.plist

Set the correct certificate GUID in the file /etc/openldap/slapd_macosxserver.conf. This can be ascertained from the contents of the /etc/certificates directory

sudo sed -e 's/oldguid/newguid/' /etc/openldap/slapd_macosxserver.conf >/tmp/conffile
sudo mv /tmp/conffile /etc/openldap/slapd_macosxserver.conf

Remove the configured TLS certificate values from the file /etc/openldap/slapd.d/cn=config.ldif

sudo vi /etc/openldap/slapd.d/cn=config.ldif
remove any lines beginning with olcTLSCertificate

Start the slapd server again

 sudo launchctl load /System/Library/LaunchDaemons/org.openldap.slapd.plist

Reboot the server again into standard mode.

Then from a client computer with linux or mac osx check that you can connect via SSL and that the certificates are correct using the command

openssl s_client -connect ldap.yourdomain:636 -showcerts

If successful you will get a dump of your server certificates as well as a connection detail description:

No client certificate CA names sent
SSL handshake has read 5209 bytes and written 807 bytes
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: C8E0F4A4ED24021DB4D98ACF5A9ACDC2293BC3961BF2AE90026115D899369E73
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket:
    Start Time: 1400140597
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)

Some other notes:

  1. Apple suggests that you can use self-signed and own certificate chains (http://support.apple.com/kb/ht3745). I use a self signed chain and it is successful.
  2. Port 636 is the standard ldaps port and is the port used by OpenDirectory (slapd)
  3. TLS1 is supported as can be seen from the openssl connection test
  4. Differing DNS names and host names do not matter (I tried both ways with a reboot between)
  5. Differing reverse DNS does not matter (I tried both ways with a reboot between)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .