[389-users] TLS handshake failure

Tue Jan 10 00:23:57 UTC 2012

On Mon, Jan 09, 2012 at 17:47:56 -0600, Rich Megginson wrote:
> 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?

Doh! I had looked at this before, but had overlooked the critical
message:

[09/Jan/2012:15:08:19 -0800] conn=5 fd=64 slot=64 SSL connection from
127.0.0.1 to 127.0.0.1
[09/Jan/2012:15:08:19 -0800] conn=5 op=-1 fd=64 closed - No certificate
authority is trusted for SSL client authentication.
[09/Jan/2012:15:32:10 -0800] conn=6 fd=64 slot=64 SSL connection from
127.0.0.1 to 127.0.0.1
[09/Jan/2012:15:32:10 -0800] conn=6 op=-1 fd=64 closed - No certificate
authority is trusted for SSL client authentication.
ds1.root # 

I had the trust flags on the CA file set to "C,," rather than "CT,,".
After changing the trust flags, it now works!

Thanks for your help.

-- 
Iain

> > 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
> >>>>>>>
> 

-- 
Iain Morgan