Wednesday, April 6, 2016

[389-users] Re: admin and Directory Manager accounts cannot log into 389-console

On Wed, 2016-04-06 at 12:03 +0000, wrote:
> Good morning Mr. Brown,
> Here is the results of your first query; executing the certutil command as you
> presented it (with adding my instance):
> certutil -L -d /etc/dirsrv/slapd-E2WAN/
> Certificate Nickname                                         Trust Attributes
>                                                              SSL,S/MIME,JAR/XPI
>                                       CT,, 
> wsf-LabLDAP.crt                                              u,u,u
> /////////
> Here is the answer to your question about a CA referenced in my
> /etc/openldap/ldap.conf; I executed:
> root@wsf-LabLDAP:~> cat /etc/openldap/ldap.conf 
> #
> # LDAP Defaults
> #
> # See ldap.conf(5) for details
> # This file should be world readable but not world writable.
> #BASE dc=example,dc=com
> #URI ldap:// ldap://
> #DEREF never
> TLS_CACERTDIR /etc/openldap/cacerts
> URI ldaps://
> BASE dc=lab,dc=aero,dc=org
> MY QUESTION is why do I need to reference anything with OpenLDAP, if I am using
> 389-ds, is it simply a place to put things without creating a separate
> directory structure?   I do not know if my CA certificate is in the correct
> place; perhaps it is not because I knew I wasn't using OpenLDAP, I am using
> 389-ds, and I didn't understand the implementation steps properly and so I 'did
> it my way.'

389-ds is the server component.

However, the ldapsearch utility comes from openldap and has it's OWN ca store.

This is why you need to configure both parts. 

> I store my certs up under /etc/pki/CA/certs; as shown below:
> root@wsf-LabLDAP:/etc/pki/CA/certs> ls
> wsf-LabCA.crt  wsf-LabLDAP-AdminServer.crt  wsf-LabLDAP.crt
> I am running CentOS-6.6; can I still get support here in this website?
> Mr. Brown, I can produce the output of an ldapsearch command and something that
> I believe confirms your suspicion; but I don't know what to do to fix the
> problem (in my VMs or on my REAL server).  Here is the ldapsearch I executed
> and the results:
> root@wsf-LabLDAP:/> ldapsearch -d 5 -x -L -b 'dc=lab,dc=aero,dc=org'
> ldap_create
> ldap_sasl_bind
> ldap_send_initial_request
> ldap_new_connection 1 1 0
> ldap_int_open_connection
> ldap_connect_to_host: TCP
> ldap_new_socket: 3
> ldap_prepare_socket: 3
> ldap_connect_to_host: Trying
> ldap_pvt_connect: fd: 3 tm: -1 async: 0
> attempting to connect: 
> connect success
> TLS: certdb config: configDir='/etc/openldap/cacerts'
> tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly
> TLS: cannot open certdb '/etc/openldap/cacerts', error -8018:Unknown PKCS #11
> error.
> TLS: loaded CA certificate file /etc/openldap/cacerts/415ee41f.0 from CA
> certificate directory /etc/openldap/cacerts.
> TLS: skipping 'authconfig_downloaded.pem' - filename does not have expected
> format (certificate hash with numeric suffix)
> TLS: certificate [CN=wsf-
>,OU=Aerospace,O=Aerospace,L=Chantilly,ST=Virginia,C=US] is
> not valid - error -8181:Peer's Certificate has expired..
> TLS: error: connect - force handshake failure: errno 0 - moznss error -8157
> TLS: can't connect: TLS error -8157:Certificate extension not found..
> ldap_err2string
> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
> Can you please lead me down the path of solving this?  I noticed you are a Red
> Hat Software Engineer; I hope that means you will still be able to support me
> on CentOS (but I guess RedHat owns CentOS now).

This is a public mailing list, so my corporate affiliation means little in terms
of whether I help you or not! 

For this, it looks like it's not able to find the ca. Look at these lines:

TLS: cannot open certdb '/etc/openldap/cacerts', error -8018:Unknown PKCS #11
> error.> TLS: loaded CA certificate file /etc/openldap/cacerts/415ee41f.0 from
> certificate directory /etc/openldap/cacerts.> TLS: skipping
'authconfig_downloaded.pem' - filename does not have expected
> format (certificate hash with numeric suffix)> TLS: certificate [CN=wsf-,OU=Aerospace,O=Aerospace,L=Chantilly,ST=Virginia,C=US] is
> not valid - error -8181:Peer's Certificate has expired..

So you should take the current CA cert from the slapd instance:

certutil -L -d /etc/dirsrv/slapd-E2WAN/ -n -a >

Then you can make these valid for openldap to use:

cd /etc/openldap/cacerts

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'

If you still fail with: 

not valid - error -8181:Peer's Certificate has expired..> 

You have bigger problems than ldap.

Otherwise, I hope this works for you.


William Brown
Software Engineer
Red Hat, Brisbane

No comments:

Post a Comment