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
>> [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/184.108.40.206 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
>> [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
>> no difference.
>> And, as mentioned in the original post, using the console GUI is not an
> 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
, and post the link here
>> 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.
>>> On 01/09/2012 02:33 PM, Iain Morgan wrote:
>>>> I'm attempting to configure 389 DS v220.127.116.11 on RHEL 6.2 to use TLS
>>>> 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
>>>> 18.104.22.168, 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
>>>> 140218505807688:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
>>>> 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.