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