LDAP broken after upgrade - certificate verify failed (Hostname mismatch)

I have been using LDAP to connect to active directory on a self hosted gitlab for years and today upgraded from 15.6.7 to 16.1.0 and now LDAP doesn’t work.
I have no idea what is changed/wrong. Possibly a bug?

In the logs I get.

{"severity":"ERROR","time":"2023-06-23T13:41:42.581Z","correlation_id":"01H3M7TG0EKDE857N3J1ABFTXA","message":"(ldapmain) Authentication failure! ldap_error: Net::LDAP::ConnectionError, Unable to connect to any given server: \n  OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 peeraddr=10.4.4.2:389 state=error: certificate verify failed (Hostname mismatch) (DC1.redacted.co.uk:389)\n  OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 peeraddr=10.4.4.3:389 state=error: certificate verify failed (Hostname mismatch) (DC2.redacted.co.uk:389)"}

If I test on the same server using openssl I get no errors.

/opt/gitlab/embedded/bin/openssl s_client -verify_return_error -connect DC1.redacted.co.uk:636

Gives output

redacted....

---
SSL handshake has read 2216 bytes and written 431 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
DONE

Any help would be appreciated.
Thanks

GitLab is trying port 389, but you are trying 636. What kind of encryption are you using? simple_tls or start_tls? Are you trying on the right port?

Ah yes my bad, that was because I tried both port 389 with start_tls and port 636 using simple_tls.
Neither work.
I have been using port 389 with start_tls for years and haven’t changed the config file.

We have had the same problem since updating to 16.1.0. Downgrading to 16.0.5 solved the issue, so it really seems to be a problem with this release.

Same issue after update to 16.1, setting ‘verify_certificates’ to ‘false’ as workaround and reconfiguring with ‘gitlab-ctl reconfigure’ works for me.

I had the exact same problem and did the exact same thing as a workaround.

There is a related issue detailing that this is most likely a bug in the new release, having issues with multiple LDAP servers in the hosts key of the LDAP config.

Yes that is probably it, I have two ldap servers specified.