[389-users] TLS handshake failure

[Iain Morgan]

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.

> 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