Anyone of these issues could be responsible? Just checking
OpenLDAP 2.4.46 Release (2018/03/22) Fixed libldap connection delete callbacks when TLS fails to start (ITS#8717) Fixed libldap to not reuse tls_session if TLS hostname check fails (ITS#7373)
Thanks
On Wed, Jun 22, 2022 at 7:51 AM Quanah Gibson-Mount quanah@fast-mail.org wrote:
--On Tuesday, June 21, 2022 11:29 PM -0700 radiatejava radiatejava@gmail.com wrote:
I raised the issue https://bugs.openldap.org/show_bug.cgi?id=9869 but it has been set to verified/invalid state now. However, I do not know which version addresses the issue. Can anyone tell me which version would still verify the hostname when doing LDAP over TLS.
The OpenLDAP 2.4 series is historic, no bug reports for it will be considered.
No changes have been made to OpenLDAP 2.4 series to disable hostname verification by the OpenLDAP project. If you are using libraries provided by downstream distributions, they may have made unauthorized changes to how libldap functions in regards to TLS. Additionally, if you were using an OpenSSL linked libldap and are now using a GnuTLS linked libldap, then some behaviors are different as documented in the man pages.
Generally I'd advise starting with a supported version of OpenLDAP.
Regards, Quanah
--On Thursday, June 23, 2022 4:47 AM -0700 radiatejava radiatejava@gmail.com wrote:
Anyone of these issues could be responsible? Just checking
No. I would also note that while you said the CN in your cert was "test.ldap.com" you didn't mention what any subjectAltName values in your cert would be. You've also not noted what TLS_REQCERT values are set nor what TLS_REQSAN options have been configured. There are any number of factors that may have disabled hostname checks on the client side that are being picked up by your application (A global ldap.conf, a user one, etc).
--Quanah
openldap-technical@openldap.org
-
Quanah Gibson-Mount -
radiatejava