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