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 -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
