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