Mr. Brown, you sort of lead me down the path; thank you. 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=r...@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=r...@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