STARTTLS failures on 10.6 migrated OD server

[warrens]

We have migrated our 10.5.8 OD server to 10.6.3 via the install DVD’s migration feature. Post-migration LDAP+TLS fails on 10.5 and 10.6 Mac clients, CentOS, Debian and FreeBSD clients.

ldap.conf has TLS_REQCERT set to never.

/etc/openldap/slapd_macosxserver.conf TLS settings:
TLSCertificatePassphraseTool “/usr/sbin/certadmin –get-private-key-passphrase /etc/certificates/gnome.darkhorse.com.794BB9A8C58B9E8517C0E02ABFEC9DF9AB635720.key.pem”
TLSCertificateFile /etc/certificates/gnome.darkhorse.com.794BB9A8C58B9E8517C0E02ABFEC9DF9AB635720.cert.pem
TLSCertificateKeyFile /etc/certificates/gnome.darkhorse.com.794BB9A8C58B9E8517C0E02ABFEC9DF9AB635720.key.pem
TLSCACertificateFile /etc/certificates/gnome.darkhorse.com.794BB9A8C58B9E8517C0E02ABFEC9DF9AB635720.chain.pem

We can verify the trust of the certs via openssl s_client -connect gnome.darkhorse.com:636 -showcerts -state

CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=1 /C=US/ST=Oregon/L=Milwaukie/O=Dark Horse Comics, Inc./OU=Dark Horse Network/CN=DHC MIS Department/[email protected]
verify error:num=19:self signed certificate in certificate chain
verify return:0
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read finished A
—
Certificate chain
0 s:/C=US/ST=Oregon/L=Milwaukie/O=Dark Horse Comics, Inc./OU=MIS/CN=gnome.darkhorse.com/[email protected]
i:/C=US/ST=Oregon/L=Milwaukie/O=Dark Horse Comics, Inc./OU=Dark Horse Network/CN=DHC MIS Department/[email protected]
—–BEGIN CERTIFICATE—–
CLIPPED
—–END CERTIFICATE—–
1 s:/C=US/ST=Oregon/L=Milwaukie/O=Dark Horse Comics, Inc./OU=Dark Horse Network/CN=DHC MIS Department/[email protected]
i:/C=US/ST=Oregon/L=Milwaukie/O=Dark Horse Comics, Inc./OU=Dark Horse Network/CN=DHC MIS Department/[email protected]
—–BEGIN CERTIFICATE—–
CLIPPED
—–END CERTIFICATE—–
—
Server certificate
subject=/C=US/ST=Oregon/L=Milwaukie/O=Dark Horse Comics, Inc./OU=MIS/CN=gnome.darkhorse.com/[email protected]
issuer=/C=US/ST=Oregon/L=Milwaukie/O=Dark Horse Comics, Inc./OU=Dark Horse Network/CN=DHC MIS Department/[email protected]
—
No client certificate CA names sent
—
SSL handshake has read 2640 bytes and written 325 bytes
—
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
Session-ID: 654B7294D9FAAE7FE553E5513172D78F02132946DC61B8FB192CDAB30E87B22C
Session-ID-ctx:
Master-Key: D8354A0742DAFEDB68E27E535FB6F5F998FFD7ED8F39429491D581F84314769811D0E5EACB2230972D52CF4CF360D245
Key-Arg : None
Start Time: 1271264425
Timeout : 300 (sec)
Verify return code: 0 (ok)

Using the check from Apple’s documentation:
ldapsearch -LLL -x -H ldaps://gnome.darkhorse.com -b “dc=darkhorse,dc=com” succeeds.

Using ldapsearch -h gnome.darkhorse.com -ZZZ -x -b “dc=darkhorse,dc=com” ‘(uid=donaldr)’ returns ldap_start_tls: Protocol error (2)

This has been repeatable with the default cert and the migrated self signed cert. The server in question has an ethernet interface with two IPs assigned to it, checkhost name returns no errors.

Any advice on addtional tests and especially pointers to the differences between 10.5/LDAP & 10.6 LDAP handling of TLS would be aprreciated.

Has anyone experienced any SSL/TLS issues post 10.6 OD migration?

[scifiman]

FINALLY! I am having the exact same issue and no one seems to know about it! My server is a completely fresh updated install of 10.6.4 with a new magic triangle. Everything looks right – DNS is right, the cert is showing as valid. It is a GoDaddy cert with the intermediate cert installed on both client and server. From the client I get error 10000 which, according to an Apple KB article (HT4183) states the problem is with the server?!

Please if anyone knows anything about this, throw us a bone!

[warrens]

We took this issue up with Apple, they filed a bug report on the matter. We changed to using ldaps and while not completely happy with having to do so it is working for us. Soon after doing so this article was posted here:

https://www.afp548.com/article.php?story=20100425082436137

Which helped fill in some of the documentation holes that made tracing down the issue a pain for us.

[Author]

Posts