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