It turns out that I needed to use the certutil (something I didn't know how to use properly for this problem to diagnose or FIX the problem with) to remove the OLD wsf-LabLDAP.crt, Then I needed to add the NEW wsf-LabLDAP.crt (from the file I had placed on the server in the last week, REMEMBER the other one was over 1 year old).
I did that within the /etc/dirsrv/slapd-E2WAN directory. I got the ldapsearch -d to come back with no (I mean, 0) problems. I feel great again.
I will say that you REALLY helped me to learn instead of solving my problems; thank you sincerely and very much from 12 timezones behind.
Here were the general steps:
1) Run the certutil and figure out what certs are in the chain for the LDAP certificate for the LDAP server itself, not the LDAP-AdminServer:
root@wsf-LabLDAP:/etc/dirsrv/slapd-E2WAN> certutil -L -d /etc/dirsrv/slapd-E2WAN/
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
wsf-LabLDAP.crt u,u,u
wsf-LabCA.crt ,,
2) Remove both of the certificates, if you have the CRT (.crt) files for both:
root@wsf-LabLDAP:/etc/dirsrv/slapd-E2WAN> certutil -D -d /etc/dirsrv/slapd-E2WAN/ -n "wsf-LabCA.crt"
root@wsf-LabLDAP:/etc/dirsrv/slapd-E2WAN> certutil -D -d /etc/dirsrv/slapd-E2WAN/ -n "wsf-LabLDAP.crt"
3) Confirm they are gone from the database:
root@wsf-LabLDAP:/etc/dirsrv/slapd-E2WAN> certutil -L -d /etc/dirsrv/slapd-E2WAN/
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
4) Add back both certificates; you should have recreated both CRT files or at least have a copy of them on the server:
root@wsf-LabLDAP:/etc/dirsrv/slapd-E2WAN> certutil -A -n "wsf-LabCA.crt" -t "CT,," -d /etc/dirsrv/slapd-E2WAN/ -i /etc/pki/CA/certs/wsf-LabCA.crt
root@wsf-LabLDAP:/etc/dirsrv/slapd-E2WAN> certutil -A -n "wsf-LabLDAP.crt" -t "u,u,u" -d /etc/dirsrv/slapd-E2WAN/ -i /etc/pki/CA/certs/wsf-LabLDAP.crt
Notice: Trust flag u is set automatically if the private key is present.
5) Confirm both certificates are 'loaded' into the cert8.db (database):
root@wsf-LabLDAP:/etc/dirsrv/slapd-E2WAN> certutil -L -d /etc/dirsrv/slapd-E2WAN/
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
wsf-LabCA.crt CT,,
wsf-LabLDAP.crt u,u,u
**Pay attention to the "CT,," Trust Attributes for wsf-LabCA.crt; and attention to the "u,u,u" Trust Attributes for the wsf-LabLDAP.crt certificate.
6) Confirm the chain relationship (noting that wsf-LabLDAP.crt should be lower and indented in comparison to the wsf-LabCA.crt certificate:
root@wsf-LabLDAP:/etc/dirsrv/slapd-E2WAN> certutil -O -d /etc/dirsrv/slapd-E2WAN/ -n "wsf-LabLDAP.crt"
"wsf-LabCA.crt" [E=root@wsf-LabCA.lab.aero.org,CN=wsf-LabCA.lab.aero.org,OU=Aerospace,O=Aerospace,L=Chantilly,ST=Virginia,C=US]
"wsf-LabLDAP.crt" [CN=wsf-LabLDAP.lab.aero.org,OU=Aerospace,O=Aerospace,L=Chantilly,ST=Virginia,C=US]
7) Restart the dirsrsv service on your machine:
oot@wsf-LabLDAP:/etc/openldap/cacerts> service dirsrv restart
Shutting down dirsrv:
E2WAN... [ OK ]
Starting dirsrv:
E2WAN...[07/Apr/2016:08:25:49 -0400] - Information: Non-Secure Port Disabled
[ OK ]
8) Ensure the ldapsearch works (using debug might be helpful, in the case things are different on your end):
root@wsf-LabLDAP:/etc/openldap/cacerts> 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 wsf-LabLDAP.lab.aero.org:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 192.168.2.243:636
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: skipping 'wsf-LabCA.lab.aero.org.pem' - filename does not have expected format (certificate hash with numeric suffix)
TLS: loaded CA certificate file /etc/openldap/cacerts/415ee41f.1 from CA certificate directory /etc/openldap/cacerts.
TLS: certificate [CN=wsf-LabLDAP.lab.aero.org,OU=Aerospace,O=Aerospace,L=Chantilly,ST=Virginia,C=US] is valid
TLS certificate verification: subject: CN=wsf-LabLDAP.lab.aero.org,OU=Aerospace,O=Aerospace,L=Chantilly,ST=Virginia,C=US, issuer: E=root@wsf-LabCA.lab.aero.org,CN=wsf-LabCA.lab.aero.org,OU=Aerospace,O=Aerospace,L=Chantilly,ST=Virginia,C=US, cipher: AES-256, security level: high, secret key bits: 256, total key bits: 256, cache hits: 0, cache misses: 0, cache not reusable: 0
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({i) ber:
ber_flush2: 14 bytes to sd 3
ldap_result ld 0xb0a300 msgid 1
<...snip...>
# search result
ldap_parse_result
ber_scanf fmt ({iAA) ber:
ber_scanf fmt (}) ber:
ldap_msgfree
# numResponses: 22
# numEntries: 21
ldap_free_connection 1 1
ldap_send_unbind
ber_flush2: 7 bytes to sd 3
ldap_free_connection: actually freed
It WORKS! Yes! This is such a load off of my chest.
Thanks for helping me,
Warron
--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
No comments:
Post a Comment