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>