[389-users] TLS handshake failure

Mon Jan 9 23:47:56 UTC 2012

On 01/09/2012 04:39 PM, Iain Morgan wrote:
> On Mon, Jan 09, 2012 at 17:18:30 -0600, Rich Megginson wrote:
>> On 01/09/2012 04:11 PM, Iain Morgan wrote:
>>> On Mon, Jan 09, 2012 at 16:59:33 -0600, Rich Megginson wrote:
>>>> 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
>>> I get the same behaviour with -CAfile set.
>> ok - try this
>>
>> openssl s_client -showcerts -debug -connect localhost:636
>>
>> remove/obscure any sensitive information in the output, paste it to
>> fpaste.org, and post the link here
> Actually, the output is short enough that I might as well post it
> inline:
>
> ds1.imorgan % openssl s_client -showcerts -debug -connect localhost:636
> CONNECTED(00000003)
> write to 0x1d6e090 [0x1e0d8c0] (113 bytes =>  113 (0x71))
> 0000 - 16 03 01 00 6c 01 00 00-68 03 01 4f 0b 78 fa 9c
> ....l...h..O.x..
> 0010 - 87 e5 f9 2f fa 40 6a 63-8b a7 74 23 5e b3 ac 8f
> .../. at jc..t#^...
> 0020 - 53 20 d3 f0 fe 3c 9d 68-57 3f 47 00 00 3a 00 39   S
> ...<.hW?G..:.9
> 0030 - 00 38 00 88 00 87 00 35-00 84 00 16 00 13 00 0a
> .8.....5........
> 0040 - 00 33 00 32 00 9a 00 99-00 45 00 44 00 2f 00 96
> .3.2.....E.D./..
> 0050 - 00 41 00 05 00 04 00 15-00 12 00 09 00 14 00 11
> .A..............
> 0060 - 00 08 00 06 00 03 00 ff-02 01 00 00 04 00 23      ..............#
> 0071 -<SPACES/NULS>
> read from 0x1d6e090 [0x1e12e20] (7 bytes =>  0 (0x0))
> 140434478798664: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
What does the directory server access log show for the connection attempt?
> I can also post to fpast.org if that would be more convenient.
>>>> 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
>>>>>>>