Enabling LDAPS?

[Diranged]

I've been having a hell of a time enabling LDAPS on my Zimbra servers... I have a Zimbra OpenSource installation with two slave LDAP servers. I want to enable SSL on all the LDAP servers with the same GoDaddy *.domain.com (wildcard) certificate we have installed in Zimbra for its WebUI and IMAP services. I've been having a hell of a time getting this to work and am now starting to wonder if its even possible... I can easily get LDAP running, but as soon as I set TLSVerifyClient to 'demand', even ldapsearches fail. They validate the certificates just fine, but then have a problem with the SSLv3 encryption.

slapd.conf settings:
TLSCipherSuite HIGH:MEDIUM:+SSLv2
TLSCACertificateFile /etc/certs/ca.pem
TLSCertificateFile /etc/certs/server.crt
TLSCertificateKeyFile /etc/certs/server.key
TLSVerifyClient demand

/etc/openldap/ldap.conf settings:
ssl start_tls
TLS_CACERT /etc/certs/ca.pem
TLS_CACERTDIR /etc/certs
TLSCipherSuite HIGH:MEDIUM:+SSLv2
TLSVerifyClient never


output of an ldapsearch with -ZZ and ldaps://

ldap_initialize( ldaps://localhost )
ldap_create
ldap_url_parse_ext(ldaps://localhost)
ldap_extended_operation_s
ldap_extended_operation
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP localhost:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 127.0.0.1:636
ldap_connect_timeout: fd: 3 tm: -1 async: 0
TLS trace: SSL_connect:before/connect initialization
TLS trace: SSL_connect:SSLv2/v3 write client hello A
TLS trace: SSL_connect:SSLv3 read server hello A
TLS certificate verification: depth: 3, err: 0, subject: /L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=info@valicert.com, issuer: /L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=info@valicert.com
TLS certificate verification: depth: 2, err: 0, subject: /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority, issuer: /L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=info@valicert.com
TLS certificate verification: depth: 1, err: 0, subject: /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=1234, issuer: /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
TLS certificate verification: depth: 0, err: 0, subject: /C=US/ST=California/L=Mountain View/O=My Org, Inc./OU=My Domain/CN=*.domain.com, issuer: /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=1234
TLS trace: SSL_connect:SSLv3 read server certificate A
TLS trace: SSL_connect:SSLv3 read server certificate request A
TLS trace: SSL_connect:SSLv3 read server done A
TLS trace: SSL_connect:SSLv3 write client certificate A
TLS trace: SSL_connect:SSLv3 write client key exchange A
TLS trace: SSL_connect:SSLv3 write change cipher spec A
TLS trace: SSL_connect:SSLv3 write finished A
TLS trace: SSL_connect:SSLv3 flush data
TLS trace: SSL3 alert read:fatal:handshake failure
TLS trace: SSL_connect:failed in SSLv3 read finished A
TLS: can't connect.
ldap_perror
ldap_start_tls: Can't contact LDAP server (-1)
additional info: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure



Any ideas? We're pretty suck here...

[gettyless]

Look over the SSL cert related wiki entries (Search results - Zimbra :: Wiki) -- generally they will tell you to use zmcertmgr to verify your SSL cert chain and deploy it to zimbra.

For me, the cert I used replaced the self-signed certs that were created during installation. In other words, in the Admin UI, in Tools > Certificates, I see my wildcard cert there now.

[Diranged]

As mentioned, I had already done that... but it doesnt appear to work properly out of the 'factory'. When you use the zimbra program it creates a slapd.crt file that has several certificates in it (presumably the CA , root, and server cert) -- but this was not working at all. I switched the config to specifically use the certificate I have and I'm running into issues as well, but I get further along.

All indications from OpenLDAP are that it thinks things are fine... but then when I try to make the actual connection there's an SSL connection problem after it verifies that the certs are good.

[gettyless]

Ok I guess the key thing is this:

TLS: can't connect.
ldap_perror
ldap_start_tls: Can't contact LDAP server (-1)
additional info: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

did you verify you can get to the ldaps port, or:

telnet ldap.example.com 636

firewall checks out ok?

[Diranged]

Yes, telnet works just fine.. furthermore, if I switch the 'demand' line to 'none' but connect to the same port, it works just fine -- but I believe its falling back to nonSSL over port 636 at that point.

[gettyless]

does this help?

RE: sslv3 alert handshake failure

[Diranged]

Thanks for that, I removed the starttls line, but still no luck. I'm not specifying port 636 anywhere specific either.

Here's a more verbose log...
tls_write: want=210, written=210
0000: 16 03 01 00 07 0b 00 00 03 00 00 00 16 03 01 00 ................
0010: 86 10 00 00 82 00 80 81 b0 4b 37 6a 14 c0 ce 10 .........K7j....
0020: 1a cd ac a2 b7 4d 35 e3 10 ca f3 c3 ca 0a b0 6f .....M5........o
0030: 7f ea a5 da 36 73 d2 46 a1 bc c9 5c 22 41 38 0d ....6s.F...\"A8.
0040: 72 64 2a e4 a4 17 1a 04 19 f8 21 84 f0 ab ae f0 rd*.......!.....
0050: ce 01 82 d3 5c 7e 2a c3 48 e7 eb 65 a3 7e 94 5a ....\~*.H..e.~.Z
0060: 7b f0 4f df 48 a6 1d fd 14 cb 65 87 88 cd 75 eb {.O.H.....e...u.
0070: 36 10 2c a0 15 f1 7e 5d 75 94 1e 0b 80 22 b1 bb 6.,...~]u...."..
0080: db 71 ac 93 44 0f c9 f9 28 33 b0 b6 c8 d3 aa 22 .q..D...(3....."
0090: df 61 35 8a 7d 73 50 14 03 01 00 01 01 16 03 01 .a5.}sP.........
00a0: 00 30 17 a1 eb c5 a5 09 ec f3 5f d1 92 8f 4d cc .0........_...M.
00b0: 7c 4a 45 b8 88 66 1f 20 3a 61 7c fb 04 3f b8 50 |JE..f. :a|..?.P
00c0: d5 bd 98 d8 5e 45 1d c1 93 ec 9d 0b 8d 3a a7 9c ....^E.......:..
00d0: 4d b3 M.
tls_read: want=5, got=5
0000: 15 03 01 00 02 .....
tls_read: want=2, got=2
0000: 02 28 .(
TLS: can't connect.
ldap_start_tls: Can't contact LDAP server (-1)
additional info: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
[root@frontend openldap]#

[Diranged]

I did find a post that helped a bit... I guest TLSVerifyClient si only needed if your trying to verify the remote client's authenticity -- in our case, we're not, we just want to encrypt the traffic. Removing that gets us one step further:

TLS trace: SSL_connect:SSLv3 read server certificate A
TLS trace: SSL_connect:SSLv3 read server done A
TLS trace: SSL_connect:SSLv3 write client key exchange A
TLS trace: SSL_connect:SSLv3 write change cipher spec A
TLS trace: SSL_connect:SSLv3 write finished A
TLS trace: SSL_connect:SSLv3 flush data
TLS trace: SSL_connect:SSLv3 read finished A
TLS: hostname (frontend.web.domain.com) does not match common name in certificate (*.domain.com).
ldap_perror
ldap_start_tls: Can't contact LDAP server (-1)
additional info: TLS: hostname does not match CN in peer certificate


The problem now is that we're seeing an error with our certificate... but its a completely valid cert that works fine in Apache, Dovecot and Postfix. Any ideas?

[Diranged]

btw the post that helped me a bit: Re: SSL3_READ_BYTES:sslv3 alert handshake failure

[quanah]

Originally Posted by Diranged

I've been having a hell of a time enabling LDAPS on my Zimbra servers... I have a Zimbra OpenSource installation with two slave LDAP servers. I want to enable SSL on all the LDAP servers with the same GoDaddy *.domain.com (wildcard) certificate we have installed in Zimbra for its WebUI and IMAP services.

output of an ldapsearch with -ZZ and ldaps://

Any ideas? We're pretty suck here...

I think the first thing to do is understand what it is you are doing.

-ZZ implies using startTLS over port 389 which is part of the RFC defined LDAP v3 protocol. ldaps:// implies using a bastardization that Netscape and others decided to use before startTLS existed. They are mutually exclusive options. Therefore, you cannot mix -ZZ and ldaps://.

So, what do you really need? Is what you need to ensure that clients use startTLS when connecting to LDAP, or is it to ensure they use ldaps://? I generally recommend the former, as it's a standard and the latter is not.

For starttls, you can enforce it by adding:

security ssf=128

in your slapd.conf.in file, and then restarting Zimbra. By default, all the ZCS functionality uses startTLS unless ldaps:// is enabled.

--Quanah