[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: SSL handshake failure

To: "openldap-technical@openldap.org" <openldap-technical@openldap.org>
Subject: RE: SSL handshake failure
From: Bryce Powell <Bryce.Powell@TELUS.COM>
Date: Wed, 29 Feb 2012 13:29:59 -0700
Accept-language: en-US
Acceptlanguage: en-US
Cc: "richm@stanfordalumni.org" <richm@stanfordalumni.org>
Content-language: en-US
Domainkey-signature: s=donder.nssi; d=telus.com; c=nofws; q=dns; h=X-IronPort-Anti-Spam-Filtered: X-IronPort-Anti-Spam-Result:X-IronPort-AV:Received: Received:From:To:CC:Date:Subject:Thread-Topic: Thread-Index:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-cr-hashedpuzzle:x-cr-puzzleid: acceptlanguage:Content-Type:Content-Transfer-Encoding: MIME-Version; b=hcEqzmQoJyfHSYgMfEdjP/KjoanIqDyAcj/GnJ+Qm4wM1Oo7gL+jPUmi JsRE7te85CtypzMzg4KkC8uSwLn5tI3E9Pr/A+mFXbyj/VAOlsVXv5qqK RPphk0TINZcfm4c0kvUGJzn4B24awoklN0esTcnXtm/DZuMAjebkbJ850 o=;
In-reply-to: <4F46D5DE.1010105@gmail.com>
References: <8F1ABAA31FF0374287B2983E3E43167728A14FB95E@WP41072.corp.ads> <4F46A9B6.8040000@symas.com> <8F1ABAA31FF0374287B2983E3E43167728A14FBA1C@WP41072.corp.ads> <4F46D5DE.1010105@gmail.com>
Thread-index: AczyiU/aRmDhWMLeSwyldLQ3rMAkdwEijQ/w
Thread-topic: SSL handshake failure

I managed to get this working, mostly by following directions in:
http://www.openldap.org/doc/admin24/tls.html
http://www.openldap.org/faq/data/cache/1514.html

Note that these steps work for my combination of OS and OpenLDAP package, as detailed in my initial posting.

My server and CA certificates were in PEM format, along with a password protected private key:

cso_root_ca.pem
cso_functional_ca.pem
cso_issuing_ca.pem
FQHostName.cert.pem
FQHostName.cert.keysecure.pem

* Decrypt the private key:
openssl rsa -in FQHostName.keysecure.pem -out FQHostName.key.pem

When prompted, enter the pass phrase for the private key.

* Convert the server cert/key pair to PKCS format:
openssl pkcs12 -export -inkey FQHostName.key.pem -in FQHostName.cert.pem -out FQHostName.cert.p12 -nodes -name 'FQHostName'

When prompted, enter a blank Export Password by hitting ENTER.

* Create the certutil certificate database:
certutil -N -d /etc/openldap/cacerts

When prompted, enter a new password for the key database.

* Remove the key database password:
certutil -d /etc/openldap/cacerts -W

When prompted, enter the current password for the key database.
e.g. Enter Password or Pin for "NSS Certificate DB":

When prompted, press ENTER to specify a blank new password.
Enter new password:
Re-enter password:
Password changed successfully.

* Import the CA chain:
certutil -A -d /etc/openldap/cacerts -n "CSO Root CA" -t CT,, -a -i cso_root_ca.pem
certutil -A -d /etc/openldap/cacerts -n "CSO Functional CA" -t CT,, -a -i cso_functional_ca.pem
certutil -A -d /etc/openldap/cacerts -n "CSO Issuing CA" -t CT,, -a -i cso_issuing_ca.pem

* Add the server certificate/key pair:
pk12util -i FQHostName.cert.p12 -d /etc/openldap/cacerts

When prompted, enter blank password by pressing ENTER.

* list all the certificates, to confirm the imports:
certutil -d /etc/openldap/cacerts -L

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

FQHostName                                      			u,u,u
CSO Root CA                                                  CT,,
CSO Functional CA                                            CT,,
CSO Issuing CA                                               CT,,


* Ensure the correct permissions and ownership are set:
ll /etc/openldap/cacerts

-rw-r-----. 1 root ldap 65536 Feb 28 11:44 cert8.db
-rw-r-----. 1 root ldap 16384 Feb 28 11:44 key3.db
-rw-r-----. 1 root ldap 16384 Feb 24 15:46 secmod.db

chmod and/or chown as necessary.

* modify /etc/openldap/slapd.conf (I'm not using cn=config as defined in the slapd folder):
TLSCACertificatePath    /etc/openldap/cacerts
TLSCertificateFile      FQHostName

Note that the certificate file specified above is the name of the server certificate 'Nickname' (the certificate Common Name) in the NSS certificate database.
As a result, the following warning will be displayed after a slapd restart:

$ sudo service slapd restart
Stopping slapd:                                            [  OK  ]
FQHostName is not readable by "ldap"                       [WARNING]
Starting slapd:                                            [  OK  ]

I believe this WARNING can safely be ignored. The OpenLDAP documentation for the TLSCertificateFile setting states:
"When using Mozilla NSS, if using a cert/key database (specified with TLSCACertificatePath), this directive specifies the name of the certificate to use."

I suspect there is still some code that is looking for the existence of an actual certificate file, and is not looking in the cert/key database.

* Modify the ldap.conf file:
TLS_CACERTDIR /etc/openldap/cacerts

* Test connectivity using TLS:
$ ldapsearch -x -ZZ -H ldap://FQHostName

The ldap log file should contain entries that indicate a successful TLS connection:

Feb 28 14:18:21 HostName slapd[18833]: conn=1016 op=0 STARTTLS
Feb 28 14:18:21 HostName slapd[18833]: conn=1016 op=0 RESULT oid= err=0 text=
Feb 28 14:18:21 HostName slapd[18833]: conn=1016 fd=26 TLS established tls_ssf=256 ssf=256

Or,
$ ldapwhoami -x -ZZ -H ldap://FQHostName
anonymous

Feb 28 14:31:48 HostName slapd[18833]: conn=1017 op=0 STARTTLS
Feb 28 14:31:48 HostName slapd[18833]: conn=1017 op=0 RESULT oid= err=0 text=
Feb 28 14:31:48 HostName slapd[18833]: conn=1017 fd=42 TLS established tls_ssf=256 ssf=256




-----Original Message-----
From: Rich Megginson [mailto:rich.megginson@gmail.com] 
Sent: February 23, 2012 4:12 PM
To: Bryce Powell
Cc: openldap-technical@openldap.org
Subject: Re: SSL handshake failure

On 02/23/2012 04:36 PM, Bryce Powell wrote:
> Thanks, Howard. Would you know how I can find a suitable package that uses openssl?
>
> I also tried moving the CA certificate chain file to the /etc/openldap/cacerts/ folder, splitting the file into 3 separate certificates, and running c_rehash to generate the hashed links. After modifying ldap.conf to use the cacerts folder instead of the ca file:
>
> TLS: file cso_root_ca.pem does not end in [.0] - does not appear to be a CA certificate directory file with a properly hashed file name - skipping.
> TLS: loaded CA certificate file /etc/openldap/cacerts/5de054ac.0 from CA certificate directory /etc/openldap/cacerts.
> TLS: loaded CA certificate file /etc/openldap/cacerts/241dd1a5.0 from CA certificate directory /etc/openldap/cacerts.
> TLS: loaded CA certificate file /etc/openldap/cacerts/95df54c4.0 from CA certificate directory /etc/openldap/cacerts.
> TLS: file cso_functional_ca.pem does not end in [.0] - does not appear to be a CA certificate directory file with a properly hashed file name - skipping.
> TLS: file cso_issuing_ca.pem does not end in [.0] - does not appear to be a CA certificate directory file with a properly hashed file name - skipping.
> TLS: error: connect - force handshake failure: errno 0 - moznss error -5938
> TLS: can't connect: TLS error -5938:Encountered end of file.
> ldap_err2string
> ldap_start_tls: Connect error (-11)
>          additional info: TLS error -5938:Encountered end of file
>
> So I guess I'm stuck until I compile from scratch using openssl, or find a package that doesn't use Mozilla NSS.
If you want to try to get it working with Mozilla NSS, I'm here to help.
Can you provide the output from running the server with the -d 1 arguments?
> Thanks
>
> -----Original Message-----
> From: Howard Chu [mailto:hyc@symas.com]
> Sent: February 23, 2012 1:04 PM
> To: Bryce Powell
> Cc: openldap-technical@openldap.org
> Subject: Re: SSL handshake failure
>
> Bryce Powell wrote:
>> Hi,
>> I can't get slapd to respond successfully to TLS or SSL connections using an
>> RSA 2048-bit PEM certificate:
> You're using Mozilla NSS, so the fact that OpenSSL tools accept your cert
> doesn't help you.
>
> While a lot of good work has gone into the Mozilla NSS support, I would still
> say the MozNSS design is braindead and is not well suited for anything besides
> the Netscape/Mozilla browser codebase and should be avoided. Rebuild OpenLDAP
> using OpenSSL and I suspect these problems will disappear.
>
>> $ ldapsearch -x -ZZ -d1 -H ldap://FQDNhostname
>> TLS: loaded CA certificate file /etc/openldap/cacerts/FQDNhostname.cacert.pem.
>> TLS: error: tlsm_PR_Recv returned 0 - error 21:Is a directory
>> TLS: error: connect - force handshake failure: errno 21 - moznss error -5938
>> TLS: can't connect: TLS error -5938:Encountered end of file.
>> ldap_err2string
>> ldap_start_tls: Connect error (-11)
>> additional info: TLS error -5938:Encountered end of file
>> $ openssl s_client -connect FQDNhostname:636 -CAfile
>> /etc/openldap/cacerts/FQDNhostname.cacert.pem
>> CONNECTED(00000003)
>> 140457427965768:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
>> failure:s23_lib.c:184:
>> ---
>> no peer certificate available
>> ---
>> No client certificate CA names sent
>> ---
>> SSL handshake has read 0 bytes and written 113 bytes
>> ---
>> New, (NONE), Cipher is (NONE)
>> Secure Renegotiation IS NOT supported
>> Compression: NONE
>> Expansion: NONE
>> ---
>> The following packages are installed on CentOS 6.2:
>> openldap-servers-2.4.23-20.el6.x86_64
>> openldap-2.4.23-20.el6.x86_64
>> openldap-clients-2.4.23-20.el6.x86_64
>> openssl-1.0.0-20.el6_2.1.x86_64
>> openssl-devel-1.0.0-20.el6_2.1.x86_64
>> gnutls-2.8.5-4.el6.x86_64
>> gnutls-devel-2.8.5-4.el6.x86_64
>> nss-pam-ldapd-0.7.5-14.el6_2.1.x86_64
>> The /etc/openldap/ldap.conf file contains:
>> TLS_CACERT /etc/openldap/cacerts/FQDNhostname.cacert.pem
>> , which contains a chain of three certificates (root CA,
>> intermediate/functional, and issuing).
>> The /etc/openldap/slapd.conf file contains:
>> TLSCipherSuite HIGH:+SSLv3
>> TLSCertificateFile /etc/openldap/FQDNhostname.cert.pem
>> TLSCertificateKeyFile /etc/openldap/FQDNhostname.key.pem
>> The server is acting as a proxy to an Active Directory, and therefore I only
>> have one LDAP database defined. My intention is to use LDAPS for communication
>> between the client and LDAP proxy servers:
>> database ldap
>> suffix "dc=abc,dc=local"
>> rebind-as-user
>> uri "ldap://IPaddress1/ ldap://IPaddress2/ ldap://IPaddress3/ ldap://IPaddress4/";
>> chase-referrals yes
>> noundeffilter yes
>> use-temporary-conn yes
>> The certificate and private key are located in /etc/openldap/, with the
>> following permissions :
>> -r--r-----. 1 ldap ldap 2076 Feb 21 15:30 FQDNhostname.cert.pem
>> -r--r-----. 1 ldap ldap 1675 Feb 21 15:35 FQDNhostname.sdi.key.pem
>> The CN of the certificate matches the FQDN host name of the LDAP server.
>> The private key is not password protected.
>> Everything checks out OK by testing the certificate using openssl:
>> $ openssl verify -purpose sslserver -CAfile
>> /etc/openldap/cacerts/FQDNhostname.cacert.pem /etc/openldap/FQDNhostname.cert.pem
>> /etc/openldap/FQDNhostname.cert.pem: OK
>> OpenSSL client/server connections work fine too:
>> openssl s_server -cert /etc/openldap/FQDNhostname.cert.pem -key
>> /etc/openldap/FQDNhostname.key.pem -cipher 'HIGH:+SSLv3
>> openssl s_client -connect FQDNhostname:4433 -CAfile
>> /etc/openldap/cacerts/FQDNhostname.cacert.pem
>> *Bryce Powell*
>

Follow-Ups:
- Re: SSL handshake failure
  - From: Rich Megginson <rich.megginson@gmail.com>

References:
- SSL handshake failure
  - From: Bryce Powell <Bryce.Powell@TELUS.COM>
- Re: SSL handshake failure
  - From: Howard Chu <hyc@symas.com>
- RE: SSL handshake failure
  - From: Bryce Powell <Bryce.Powell@TELUS.COM>
- Re: SSL handshake failure
  - From: Rich Megginson <rich.megginson@gmail.com>

Prev by Date: Re: LDAP_OPT_X_TLS_xxx option in SSL/TLS connection
Next by Date: Re: SSL handshake failure
Index(es):
- Chronological
- Thread