On Wed, Jun 03 2020 at 00:16:31 -0000, phei@isc.upenn.edu scribbled in "ssl certificate chain":
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.
Thanks,
Peter
relevant bits: #slapd.conf # TLS/ssl TLSCACertificatePath /etc/openldap/certs TLSCertificateFile DirectoryLdap
#sudo certutil -d /etc/openldap/certs -L
Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI
intermediate-2024 ,, PennGroupsLdap
Hi,
Firstly a caveat: we don't make use of NSS for any of our directory systems, so I have no experience of using OpenLDAP with NSS.
Given that, the question I have is rather simple, but I wanted to check nonetheless -- is there a typo in the information you've provided above? The TLSCertificateFile option has the value "DirectoryLdap", but by my understanding should, going by the output from `certutil`, possibly rather be configured with a value of "PennGroupsLdap"?
That doesn't really answer the question about where the wrong certificate is appearing from, but I don't know how libnss will behave if given an undefined TLSCertificateFile value to select from.
Cheers.
Dameon.