[389-users] TLS handshake failure

[Rich Megginson]

On 01/09/2012 03:59 PM, Iain Morgan wrote:
> The error log does not report any issues. It indicates that ns-slapd is
> listening on both port 389 and 636. and it does not indicate any errors
> at connection time.
>
> ds1.root # tail errors
> [09/Jan/2012:13:57:28 -0800] - slapd shutting down - signaling operation
> threads
> [09/Jan/2012:13:57:28 -0800] - slapd shutting down - waiting for 15
> threads to terminate
> [09/Jan/2012:13:57:28 -0800] - slapd shutting down - closing down
> internal subsystems and plugins
> [09/Jan/2012:13:57:28 -0800] - Waiting for 4 database threads to stop
> [09/Jan/2012:13:57:28 -0800] - All database threads now stopped
> [09/Jan/2012:13:57:28 -0800] - slapd stopped.
> [09/Jan/2012:13:57:29 -0800] - 389-Directory/1.2.9.14 B2011.312.195
> starting up
> [09/Jan/2012:13:57:29 -0800] - slapd started.  Listening on Loopback
> port 389 for LDAP requests
> [09/Jan/2012:13:57:29 -0800] - Listening on Loopback port 636 for LDAPS
> requests
> [09/Jan/2012:13:57:29 -0800] - Listening on /var/run/slapd-ds1.socket
> for LDAPI requests
> ds1.root #
>
> I've already compared the dse.ldif from the problem system to the
> dse.ldif from the working system which uses a self-signed certificate.
> The only difference of note was the addition of the
> nsslapd-validate-cert attribute in the problem server. Incidentally,
> changing the value of that attribute from "warn" to "on" or "off" made
> no difference.
>
> And, as mentioned in the original post, using the console GUI is not an
> option.
What happens if you specify the -CAfile filename arguments to openssl 
s_client?
> On Mon, Jan 09, 2012 at 16:41:36 -0600, Marc Sauton wrote:
>> Review the 389 DS errors log file, and the config, it seem like TLS did
>> not start.
>> Use the console UI a first time to review the working configuration,
>> just for a test, and compare with the manual settings.
>> M.
>>
>> On 01/09/2012 02:33 PM, Iain Morgan wrote:
>>> Hello,
>>>
>>> I'm attempting to configure 389 DS v1.2.9.14 on RHEL 6.2 to use TLS with
>>> a certificate issued by a CA. I was previously able to configure TLS
>>> support using a self-signed certificate on a test system using 389 DS
>>> 1.2.8.2, but I am not having any success with the CA-issued certificate.
>>>
>>> Using the GUI is not an option, but I have used certutil to create the
>>> key/certificate databases, generate a CSR, and subsequently install the
>>> CA certificate and the signed SSL certificate.
>>>
>>> The server has been configured to use the certificate and the LDAPS
>>> listener has been enabled. The server starts up without complaint and
>>> the error log shows that it is listening on both port 389 and 636.
>>> However, attempts to connect to the LDAPS port fail:
>>>
>>> ds1.imorgan % openssl s_client -connect localhost:636
>>> CONNECTED(00000003)
>>> 140218505807688: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
>>> ---
>>> ds1.imorgan %
>>>
>>> Unfortunately, there do not appear to be any log messages which indicate
>>> the source of the problem. I've played with the trust flags for the
>>> certificate and have even tried re-importing it; all to no avail.
>>>
>>> Any help would be appreciated.
>>>
>>> Thanks
>>>