This RedHat 6, their openldap-servers rpm is built to use the nss certificate database.
Changing CA provider is not an option due to policy.
In following this article from the openldap faq
https://www.openldap.org/faq/data/cache/1514.html (this section may need updating, as the certutil now requires the secmod and password dbs to be present. So just linking to the shared object file doesn't work, you get the famously unhelpful "SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, unsupported format error").
I'm able to see the modules; can see the certs in the private but not the generic:
[root@dev-pnldap1 certs]# certutil -d $PWD -U
slot: NSS User Private Key and Certificate Services token: NSS Certificate DB uri: pkcs11:token=NSS%20Certificate%20DB;manufacturer=Mozilla%20Foundation;serial=0000000000000000;model=NSS%203
slot: NSS Internal Cryptographic Services token: NSS Generic Crypto Services uri: pkcs11:token=NSS%20Generic%20Crypto%20Services;manufacturer=Mozilla%20Foundation;serial=0000000000000000;model=NSS%203
[root@dev-pnldap1 certs]# certutil -d $PWD -L -h "NSS Generic Crypto Services"
Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI
[root@dev-pnldap1 certs]# certutil -d $PWD -L -h "NSS Certificate DB"
Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI
DirectoryTestLdap u,u,u intermediate-2024 ,,
________________________________ From: Bill MacAllister bill@ca-zephyr.org Sent: Wednesday, June 3, 2020 1:27 AM To: Heinemann, Peter G phei@isc.upenn.edu Cc: openldap-technical@openldap.org openldap-technical@openldap.org Subject: Re: ssl certificate chain
On 2020-06-02 17:16, phei@isc.upenn.edu wrote:
Not sure if this is an openldap issue but have to examine everything we can.
We revised our nss certificate store as part of addressing the expiration of our root cert.
It now has two certs, the end service cert and the intermediate. Basic client operations (ldapsearch) work fine; using -d1 shows that the appropriate service certificate is loaded and the the search is successful.
But if we run an 'openssl s_client -showcerts' against the host and port 636, we continue to see the expired root certificate even though it's not in the nss store configured chain. This is causing issues for some applications (mainly java based) so we're just trying to understand where the expired root would be coming from if it's not in the openldap server configuration.
To put it mildly, it is unlikely that it is openldap. It is most likely that it will be the underlying SSL support that you need to understand. You don't tell us whether you are using a distribution build, which distribution, or whether you are using GNUTLS or OpenSSL. As I remember with GNUTLS you have to put everything in one file. Just don't put the bad CA cert in the file. With OpenSSL it can be a bit tricky if you are just pointing to the cert directory. You would need to make sure that you purge the cert directory of any bad/expired certs.
A warning about my SSL advice. It has been awhile since I actually tested SSL client connections to OpenLDAP, I use GSSAPI/Kerberos for authentication and connection privacy.
I got bit by this on some of my web servers. I was able to solve it by downloading a new root cert bundle from the CA for my web servers. (https://www.ssls.com/) But, I never could get the new cert chain to work on my webkdc. I think it was because of a limitation of the perl LWP module. But, it also might have been because the expired root CA was in the ca-certificates package on debian/ubuntu and it was not an option to delete that package. (That package has since been patched. If you are on a debian system you might try just installing the ca-certificates update.)
It was never clear what the problem was and the support was abysmal. If its not a web server they just don't have a clue.
In the end I solved my problem by abandoning that CA and just going to https://letsencrypt.org/ and getting a free cert from them. I spend a couple hours on a chat with support and never resolved the issue. I spent about 15 minutes getting and installing a cert from Let's Encrypt which solved my problem.
I would recommend that you drop that CA. They handled this transition extremely poorly.
Bill
-- Bill MacAllister bill@ca-zephyr.org