At the moment, I still update LDAP certificates by hand. All previous certs used "C = US, O = Internet2, CN = InCommon RSA Server CA 2" but on May 4th, moved to "C = US, O = "InCommon, LLC", CN = InCommon RSA OV SSL CA 3". I had to generate a new cert after that date... so I added in the new CA certs into my CACert file on both ends. But replication is failing with the new cert, works fine with the old cert:
May 13 13:26:21 HOSTNAME slapd[4076661]: slap_client_connect: URI=ldap://master_vip_name/ ldap_sasl_interactive_bind_s failed (-1) May 13 13:26:21 HOSTNAME slapd[4076661]: do_syncrepl: rid=101 rc -1 retrying
Tried changing tls_reqcert to never in ldap.conf and in the syncrepl and that didn't change anything. If I move back to the old cert (expires tomorrow) replication works again so probably not a password issue.
Any suggestions for debugging this further?
thanks, ds
steiner@rutgers.edu wrote:
At the moment, I still update LDAP certificates by hand. All previous certs used "C = US, O = Internet2, CN = InCommon RSA Server CA 2" but on May 4th, moved to "C = US, O = "InCommon, LLC", CN = InCommon RSA OV SSL CA 3". I had to generate a new cert after that date... so I added in the new CA certs into my CACert file on both ends. But replication is failing with the new cert, works fine with the old cert:
May 13 13:26:21 HOSTNAME slapd[4076661]: slap_client_connect: URI=ldap://master_vip_name/ ldap_sasl_interactive_bind_s failed (-1) May 13 13:26:21 HOSTNAME slapd[4076661]: do_syncrepl: rid=101 rc -1 retrying
Tried changing tls_reqcert to never in ldap.conf and in the syncrepl and that didn't change anything. If I move back to the old cert (expires tomorrow) replication works again so probably not a password issue.
Any suggestions for debugging this further?
Try to connect to the server using ldapsearch -d-1 using the new cert and examine the debug output.
thanks, ds
ldapsearch doesn't seem to have any issues. I went from master to consumer, consumer to master, and consumer to consumer. Returns data. Here's the TLS lines from debugging:
TLS trace: SSL_connect:before SSL initialization TLS trace: SSL_connect:SSLv3/TLS write client hello TLS trace: SSL_connect:SSLv3/TLS write client hello TLS trace: SSL_connect:SSLv3/TLS read server hello TLS trace: SSL_connect:TLSv1.3 read encrypted extensions TLS trace: SSL_connect:SSLv3/TLS read server certificate request TLS certificate verification: depth: 3, err: 0, subject: /C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority, issuer: /C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority TLS certificate verification: depth: 2, err: 0, subject: /C=GB/O=Sectigo Limited/CN=Sectigo Public Server Authentication Root R46, issuer: /C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority TLS certificate verification: depth: 1, err: 0, subject: /C=US/O=InCommon, LLC/CN=InCommon RSA OV SSL CA 3, issuer: /C=GB/O=Sectigo Limited/CN=Sectigo Public Server Authentication Root R46 TLS certificate verification: depth: 0, err: 0, subject: /C=US/ST=New Jersey/O=Rutgers, The State University of New Jersey/CN=idm-ldap-abusec101-prod-asb.ei.rutgers.edu, issuer: /C=US/O=InCommon, LLC/CN=InCommon RSA OV SSL CA 3 TLS trace: SSL_connect:SSLv3/TLS read server certificate TLS trace: SSL_connect:TLSv1.3 read server certificate verify TLS trace: SSL_connect:SSLv3/TLS read finished TLS trace: SSL_connect:SSLv3/TLS write change cipher spec TLS trace: SSL_connect:SSLv3/TLS write client certificate TLS trace: SSL_connect:SSLv3/TLS write finished TLS trace: SSL_connect:SSL negotiation finished successfully TLS trace: SSL_connect:SSL negotiation finished successfully TLS trace: SSL_connect:SSLv3/TLS read server session ticket TLS trace: SSL_connect:SSL negotiation finished successfully TLS trace: SSL_connect:SSL negotiation finished successfully TLS trace: SSL_connect:SSLv3/TLS read server session ticket TLS trace: SSL3 alert write:warning:close notify
Nothing odd in the rest of the output. The only thing that is failing is replication.
Also, tls_reqcert settings are similar, either demand or try in both slapd.conf and ldap.conf.
-ds
steiner@rutgers.edu wrote:
ldapsearch doesn't seem to have any issues. I went from master to consumer, consumer to master, and consumer to consumer. Returns data. Here's the TLS lines from debugging:
Now run slapd with -d-1 and look at the corresponding output.
Are you sure you set the new CA in the consumer's TLS config?
TLS trace: SSL_connect:before SSL initialization TLS trace: SSL_connect:SSLv3/TLS write client hello TLS trace: SSL_connect:SSLv3/TLS write client hello TLS trace: SSL_connect:SSLv3/TLS read server hello TLS trace: SSL_connect:TLSv1.3 read encrypted extensions TLS trace: SSL_connect:SSLv3/TLS read server certificate request TLS certificate verification: depth: 3, err: 0, subject: /C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority, issuer: /C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority TLS certificate verification: depth: 2, err: 0, subject: /C=GB/O=Sectigo Limited/CN=Sectigo Public Server Authentication Root R46, issuer: /C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority TLS certificate verification: depth: 1, err: 0, subject: /C=US/O=InCommon, LLC/CN=InCommon RSA OV SSL CA 3, issuer: /C=GB/O=Sectigo Limited/CN=Sectigo Public Server Authentication Root R46 TLS certificate verification: depth: 0, err: 0, subject: /C=US/ST=New Jersey/O=Rutgers, The State University of New Jersey/CN=idm-ldap-abusec101-prod-asb.ei.rutgers.edu, issuer: /C=US/O=InCommon, LLC/CN=InCommon RSA OV SSL CA 3 TLS trace: SSL_connect:SSLv3/TLS read server certificate TLS trace: SSL_connect:TLSv1.3 read server certificate verify TLS trace: SSL_connect:SSLv3/TLS read finished TLS trace: SSL_connect:SSLv3/TLS write change cipher spec TLS trace: SSL_connect:SSLv3/TLS write client certificate TLS trace: SSL_connect:SSLv3/TLS write finished TLS trace: SSL_connect:SSL negotiation finished successfully TLS trace: SSL_connect:SSL negotiation finished successfully TLS trace: SSL_connect:SSLv3/TLS read server session ticket TLS trace: SSL_connect:SSL negotiation finished successfully TLS trace: SSL_connect:SSL negotiation finished successfully TLS trace: SSL_connect:SSLv3/TLS read server session ticket TLS trace: SSL3 alert write:warning:close notify
Nothing odd in the rest of the output. The only thing that is failing is replication.
Also, tls_reqcert settings are similar, either demand or try in both slapd.conf and ldap.conf.
-ds
Thanks! I'll have to get the SysAdmin to run it as I don't have root privs to do so. Hopefully they're still around today.
Yes, all the CA certs are in a single file and I just added the new ones. No change to TLSCACertificateFile necessary.
-ds
I think this is a cipher issue but not sure what's the best way to fix it. Here's the relevant parts of the debug log:
6a06270d.1893657b 0x7fdd70a32700 TLS trace: SSL_connect:before SSL initialization 6a06270d.189599e9 0x7fdd70a32700 TLS trace: SSL_connect:SSLv3/TLS write client hello 6a06270d.1895c248 0x7fdd70a32700 TLS trace: SSL_connect:error in SSLv3/TLS write client hello 6a06270d.1895e146 0x7fdd70a32700 ldap_int_tls_start: ldap_int_tls_connect needs read 6a06270d.1895f650 0x7fdd70a32700 ldap_int_tls_start: ld 0x7fdd64000db0 29 s 999743 us to go 6a06270d.18960cd2 0x7fdd70a32700 ldap_int_poll: fd: 13 tm: 29 6a06270d.19506ebf 0x7fdd70a32700 ldap_is_sock_ready: 13 6a06270d.195101f9 0x7fdd70a32700 ldap_ndelay_off: 13 6a06270d.1951816b 0x7fdd70a32700 TLS trace: SSL_connect:SSLv3/TLS write client hello 6a06270d.19559d12 0x7fdd70a32700 TLS trace: SSL_connect:SSLv3/TLS read server hello 6a06270d.1956362d 0x7fdd70a32700 TLS trace: SSL_connect:TLSv1.3 read encrypted extensions 6a06270d.1957837a 0x7fdd70a32700 TLS trace: SSL_connect:SSLv3/TLS read server certificate request 6a06270d.195af125 0x7fdd70a32700 TLS certificate verification: depth: 2, err: 0, subject: /C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority, 6a06270d.195b3872 0x7fdd70a32700 issuer: /C=US/ ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority 6a06270d.195ce954 0x7fdd70a32700 TLS certificate verification: depth: 1, err: 0, subject: /C=US/O=Internet2/CN=InCommon RSA Server CA 2,6a06270d.195d0666 0x7fdd70a32700 issuer: /C=US/ST=Ne w Jersey/L=Jersey City/O=The USERTRUST Network/C N=USERTrust RSA Certification Authority 6a06270d.195e1da8 0x7fdd70a32700 TLS certificate verification: depth: 0, err: 0, subject: /C=US/ST=New Jersey/O=Rutgers, The State University of New Jersey/CN=ldap-master-vip.rutgers.edu,6a 06270d.195e3afd 0x7fdd70a32700 issuer: /C=US/O= Internet2/CN=InCommon RSA Server CA 2 6a06270d.195e72e0 0x7fdd70a32700 TLS trace: SSL_connect:SSLv3/TLS read server certificate 6a06270d.195f2c6d 0x7fdd70a32700 TLS trace: SSL_connect:TLSv1.3 read server certificate verify 6a06270d.19600f87 0x7fdd70a32700 TLS trace: SSL_connect:SSLv3/TLS read finished 6a06270d.196035f3 0x7fdd70a32700 TLS trace: SSL_connect:SSLv3/TLS write change cipher spec 6a06270d.1965f8fe 0x7fdd70a32700 TLS trace: SSL_connect:SSLv3/TLS write client certificate 6a06270d.19748f81 0x7fdd70a32700 TLS trace: SSL_connect:SSLv3/TLS write certificate verify 6a06270d.19753ca0 0x7fdd70a32700 TLS trace: SSL_connect:SSLv3/TLS write finished 6a06270d.19762de6 0x7fdd70a32700 ldap_sasl_interactive_bind: user selected: EXTERNAL 6a06270d.19765125 0x7fdd70a32700 ldap_int_sasl_bind: EXTERNAL 6a06270d.19dfb970 0x7fdd70a32700 ldap_int_sasl_open: host=ldap-master-vip.rutgers.edu 6a06270d.19e14381 0x7fdd70a32700 ldap_sasl_bind 6a06270d.19e17d67 0x7fdd70a32700 ldap_send_initial_request 6a06270d.19e18fdd 0x7fdd70a32700 ldap_send_server_request 6a06270d.19e1a390 0x7fdd70a32700 ber_scanf fmt ({it) ber: 6a06270d.19e1b59c 0x7fdd70a32700 ber_scanf fmt ({i) ber: 6a06270d.19e1c0fb 0x7fdd70a32700 ber_flush2: 26 bytes to sd 13 6a06270d.19e22270 0x7fdd70a32700 ldap_free_request (origid 2, msgid 2) 6a06270d.19e23937 0x7fdd70a32700 ldap_free_request_int: lr 0x7fdd64135380 msgid 2 removed 6a06270d.19e24c5a 0x7fdd70a32700 ldap_do_free_request: asked to free lr 0x7fdd64135380 msgid 2 refcnt 0 6a06270d.19e260d2 0x7fdd70a32700 ldap_free_connection 0 0 6a06270d.19e2710d 0x7fdd70a32700 ldap_free_connection: refcnt 1 6a06270d.19e27b7d 0x7fdd70a32700 ldap_msgfree 6a06270d.19e29251 0x7fdd70a32700 slap_client_connect: URI=ldap://ldap-master-vip.rutgers.edu/ ldap_sasl_interactive_bind_s failed (-1) 6a06270d.19e340f0 0x7fdd70a32700 ldap_free_connection 1 1 6a06270d.19e363a1 0x7fdd70a32700 ldap_send_unbind 6a06270d.19e3710a 0x7fdd70a32700 ber_flush2: 7 bytes to sd 13 6a06270d.19e3fc48 0x7fdd70a32700 ldap_free_connection: actually freed 6a06270d.19e52801 0x7fdd70a32700 do_syncrepl: rid=101 rc -1 retrying (9 retries left)
and if you look at the certs, in the old one I see
Signature Algorithm: sha384WithRSAEncryption
and the new one (just a renewal) is
Signature Algorithm: sha256WithRSAEncryption
steiner@rutgers.edu wrote:
I think this is a cipher issue but not sure what's the best way to fix it. Here's the relevant parts of the debug log:
and if you look at the certs, in the old one I see
Signature Algorithm: sha384WithRSAEncryption
and the new one (just a renewal) is
Signature Algorithm: sha256WithRSAEncryption
Did you set an SSF based on the older cert, and the new one isn't "strong" enough?
Hum, haven't changed the SSF settings (generally 127) since we migrated to OpenLDAP over 10 years ago. I'll have to investigate further.
-ds
We also have the following set, which I would think would include both those algorithms.
TLSCipherSuite HIGH:MEDIUM
steiner@rutgers.edu wrote:
We also have the following set, which I would think would include both those algorithms.
TLSCipherSuite HIGH:MEDIUM
No, pretty sure those suite specifiers don't apply to TLSv1.3. So this is probably your problem. You'll have to read the OpenSSL docs to be certain.
Hi!
Don't you use a olcAuthzRegexp somewhere?
Kind regards, Ulrich Windl
-----Original Message----- From: steiner@rutgers.edu steiner@rutgers.edu Sent: Thursday, May 14, 2026 12:09 AM To: openldap-technical@openldap.org Subject: [EXT] Re: issue with new cert (now using CN = InCommon RSA OV SSL CA 3)
Sicherheits-Hinweis: Diese E-Mail wurde von einer Person außerhalb des UKR gesendet. Seien Sie vorsichtig vor gefälschten Absendern, wenn Sie auf Links klicken, Anhänge öffnen oder weitere Aktionen ausführen, bevor Sie die Echtheit überprüft haben.
Thanks! I'll have to get the SysAdmin to run it as I don't have root privs to do so. Hopefully they're still around today.
Yes, all the CA certs are in a single file and I just added the new ones. No change to TLSCACertificateFile necessary.
-ds
Hi!
I have a related question: I replaced our certificate with a refreshed one (keeping the key and filename). Does OpenLDAP cache the certificate, or does it read it anew every time it's needed (i.e.: do I have to restart the server?)? I'm using cn=config, just in case.
Kind regards, Ulrich Windl
-----Original Message----- From: steiner@rutgers.edu steiner@rutgers.edu Sent: Wednesday, May 13, 2026 7:32 PM To: openldap-technical@openldap.org Subject: [EXT] issue with new cert (now using CN = InCommon RSA OV SSL CA 3)
At the moment, I still update LDAP certificates by hand. All previous certs used "C = US, O = Internet2, CN = InCommon RSA Server CA 2" but on May 4th, moved to "C = US, O = "InCommon, LLC", CN = InCommon RSA OV SSL CA 3". I had to generate a new cert after that date... so I added in the new CA certs into my CACert file on both ends. But replication is failing with the new cert, works fine with the old cert:
May 13 13:26:21 HOSTNAME slapd[4076661]: slap_client_connect: URI=ldap://master_vip_name/ ldap_sasl_interactive_bind_s failed (-1) May 13 13:26:21 HOSTNAME slapd[4076661]: do_syncrepl: rid=101 rc -1 retrying
Tried changing tls_reqcert to never in ldap.conf and in the syncrepl and that didn't change anything. If I move back to the old cert (expires tomorrow) replication works again so probably not a password issue.
Any suggestions for debugging this further?
thanks, ds
Windl, Ulrich wrote:
Hi!
I have a related question: I replaced our certificate with a refreshed one (keeping the key and filename). Does OpenLDAP cache the certificate, or does it read it anew every time it's needed (i.e.: do I have to restart the server?)? I'm using cn=config, just in case.
The behavior depends on the particular TLS library being used. Pretty sure that OpenSSL caches the file. You don't need to restart the server, just ldapmodify the setting in cn=config. You can replace it with the same name as before, if you just want it to reload the same file.
Kind regards, Ulrich Windl
-----Original Message----- From: steiner@rutgers.edu steiner@rutgers.edu Sent: Wednesday, May 13, 2026 7:32 PM To: openldap-technical@openldap.org Subject: [EXT] issue with new cert (now using CN = InCommon RSA OV SSL CA 3)
At the moment, I still update LDAP certificates by hand. All previous certs used "C = US, O = Internet2, CN = InCommon RSA Server CA 2" but on May 4th, moved to "C = US, O = "InCommon, LLC", CN = InCommon RSA OV SSL CA 3". I had to generate a new cert after that date... so I added in the new CA certs into my CACert file on both ends. But replication is failing with the new cert, works fine with the old cert:
May 13 13:26:21 HOSTNAME slapd[4076661]: slap_client_connect: URI=ldap://master_vip_name/ ldap_sasl_interactive_bind_s failed (-1) May 13 13:26:21 HOSTNAME slapd[4076661]: do_syncrepl: rid=101 rc -1 retrying
Tried changing tls_reqcert to never in ldap.conf and in the syncrepl and that didn't change anything. If I move back to the old cert (expires tomorrow) replication works again so probably not a password issue.
Any suggestions for debugging this further?
thanks, ds
Yes, unfortunately, using openssl does not re-read the certificate files while slapd is running. I wonder: If an ldapmodify can trigger a refresh, can't slapd check (like once per day) whether the mtime of the certificate file had changed and then trigger re-reading it. Or at least start doing so once the cached certificate had expired 😉
Kind regards, Ulrich Windl
-----Original Message----- From: Howard Chu hyc@symas.com Sent: Wednesday, May 20, 2026 7:46 PM To: Windl, Ulrich u.windl@ukr.de; steiner@rutgers.edu; openldap- technical@openldap.org Subject: [EXT] Re: [EXT] issue with new cert (now using CN = InCommon RSA OV SSL CA 3)
Windl, Ulrich wrote:
Hi!
I have a related question: I replaced our certificate with a refreshed one
(keeping the key and filename).
Does OpenLDAP cache the certificate, or does it read it anew every time it's
needed (i.e.: do I have to restart the server?)? I'm using cn=config, just in case.
The behavior depends on the particular TLS library being used. Pretty sure that OpenSSL caches the file. You don't need to restart the server, just ldapmodify the setting in cn=config. You can replace it with the same name as before, if you just want it to reload the same file.
Kind regards, Ulrich Windl
-----Original Message----- From: steiner@rutgers.edu steiner@rutgers.edu Sent: Wednesday, May 13, 2026 7:32 PM To: openldap-technical@openldap.org Subject: [EXT] issue with new cert (now using CN = InCommon RSA OV SSL
CA
At the moment, I still update LDAP certificates by hand. All previous certs used "C = US, O = Internet2, CN = InCommon RSA Server CA 2" but on May 4th, moved to "C = US, O = "InCommon, LLC", CN = InCommon RSA OV SSL
CA
3". I had to generate a new cert after that date... so I added in the new CA certs into my CACert file on both ends. But replication is failing with the
new
cert, works fine with the old cert:
May 13 13:26:21 HOSTNAME slapd[4076661]: slap_client_connect: URI=ldap://master_vip_name/ ldap_sasl_interactive_bind_s failed (-1) May 13 13:26:21 HOSTNAME slapd[4076661]: do_syncrepl: rid=101 rc -1 retrying
Tried changing tls_reqcert to never in ldap.conf and in the syncrepl and
that
didn't change anything. If I move back to the old cert (expires tomorrow) replication works again so probably not a password issue.
Any suggestions for debugging this further?
thanks, ds
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
openldap-technical@openldap.org
-
Howard Chu -
steiner＠rutgers.edu -
Windl, Ulrich