On Tue, 2016-04-12 at 01:32 +0000, xinhuan zheng wrote:
Hello Mr. Brown,
TLS: certdb config: configDir='/etc/openldap/certs'
certPrefix='' keyPrefix='' flags=readOnly
TLS: cannot open certdb '/etc/openldap/certs', error -8018:Unknown PKCS #11
TLS: certificate [CN=CAcert] is not valid - error -8172:Peer's certificate
issuer has been marked as not trusted by the user..
TLS: error: connect - force handshake failure: errno 0 - moznss error -8172
TLS: can't connect: TLS error -8172:Peer's certificate issuer has been marked
as not trusted by the user..
[11/Apr/2016:21:14:18 -0400] conn=28 fd=64 slot=64 SSL connection from
192.168.13.26 to 192.168.13.26
[11/Apr/2016:21:14:18 -0400] conn=28 op=-1 fd=64 closed - Peer does not
recognize and trust the CA that issued your certificate.
I think I'll need to delete all certificates then re-create them all from
scratch. One thing I am not sure is the certificate flags, in setupssl2.sh. For
"CA certificate" the flag is "CT,,", while for server certificate, it
"u,u,u", is it correct?
The issue is that you do not have your CA cert in /etc/openldap/certs.
I helped with this same issue in the subject titled:
[389-users] Re: admin and Directory Manager accounts cannot log into 389-console
The answer I gave there:
So you should take the current CA cert from the slapd instance:
certutil -L -d /etc/dirsrv/slapd-E2WAN/ -n wsf-LabCA.lab.aero.org
Then you can make these valid for openldap to use:
This will recreate the hash -> cert symlinks.
From there, re-run your ldap search command:
ldapsearch -d 5 -x -L -b 'dc=lab,dc=aero,dc=org'
You will need to adjust these commands to match your instances, the CA certs, and
your openldap/certs location. Otherwise, that should fix the issue.
Red Hat, Brisbane