Update to v2.4.3 breaks ldap connection
Unfortunately the upgrade to v2.4.3 broke the ldap connection.
I have configured an ldap connection like this:
ldap_uris = ldaps://xxx.com
ldap_auth_dn = uid=xxx,ou=general accounts,dc=xxx,dc=com
ldap_auth_dn_password = xxx
ldap_base = dc=xxx,dc=com
passdb ldap {
ldap_bind = yes
[...]
}
v2.4.3 cannot connect and says:
auth: Error: ldap(ldaps://xxx.com636): Can't connect to server: ldaps://xxx.com
Ldap server logs:
ACCEPT from IP=[XXX]:45674 (IP=[::]:636)
TLS established tls_ssf=256 ssf=256 tls_proto=TLS1.3 tls_cipher=AES-256-GCM
closed (connection lost)
Downgrade to dovecot v2.4.2 makes it work again.
Was there any ldap change in v2.4.3 that required a config change?
Using ubuntu 24.04 with the dovecot ppa, now forced version 2.4.2 by using https://repo.dovecot.org/ce-2.4.2/ubuntu/noble
On 30/03/2026 13:15 EEST markus-dovecot--- via dovecot <dovecot@dovecot.org> wrote:
Unfortunately the upgrade to v2.4.3 broke the ldap connection.
I have configured an ldap connection like this:
ldap_uris = ldaps://xxx.com ldap_auth_dn = uid=xxx,ou=general accounts,dc=xxx,dc=com ldap_auth_dn_password = xxx ldap_base = dc=xxx,dc=com passdb ldap { ldap_bind = yes [...] }v2.4.3 cannot connect and says:
auth: Error: ldap(ldaps://xxx.com636): Can't connect to server: ldaps://xxx.comLdap server logs:
ACCEPT from IP=[XXX]:45674 (IP=[::]:636) TLS established tls_ssf=256 ssf=256 tls_proto=TLS1.3 tls_cipher=AES-256-GCM closed (connection lost)Downgrade to dovecot v2.4.2 makes it work again.
Was there any ldap change in v2.4.3 that required a config change?
Can you please turn on
log_debug=category=auth
and
ldap_debug_level=9
Aki
Hi Markus, hi list,
On 2026-03-30 12:15:15, markus-dovecot--- via dovecot wrote:
Unfortunately the upgrade to v2.4.3 broke the ldap connection.
I have configured an ldap connection like this:
ldap_uris = ldaps://xxx.com ldap_auth_dn = uid=xxx,ou=general accounts,dc=xxx,dc=com ldap_auth_dn_password = xxx ldap_base = dc=xxx,dc=com passdb ldap { ldap_bind = yes [...] }v2.4.3 cannot connect and says:
auth: Error: ldap(ldaps://xxx.com636): Can't connect to server: ldaps://xxx.comLdap server logs:
ACCEPT from IP=[XXX]:45674 (IP=[::]:636) TLS established tls_ssf=256 ssf=256 tls_proto=TLS1.3 tls_cipher=AES-256-GCM closed (connection lost)Downgrade to dovecot v2.4.2 makes it work again.
Was there any ldap change in v2.4.3 that required a config change?
I had a similar error. In my case, dovecot was missing the CA certificate for the cert of the LDAP server, as it was not included in the OS' ca-certificates bundle. I fixed it in my case with:
ssl_client_ca_file = /path/to/ldapservers-ca-certificate.crt
Seems like dovecot did not check the CA signing the LDAP server's certificate before 2.4.3.
Best,
Patrick Cernko <pcernko@mpi-klsb.mpg.de> +49 681 9325 5815 Joint Scientific IT and Technical Service Max-Planck-Institute für Informatik & Softwaresysteme
Yes, thank you, that seems to be my problem, too:
auth: Error: ldap_create
auth: Error: ldap_url_parse_ext(ldaps://xxx.com)
auth: Error: ldap_sasl_bind
auth: Error: ldap_send_initial_request
auth: Error: ldap_new_connection 1 1 0
auth: Error: ldap_int_open_connection
auth: Error: ldap_connect_to_host: TCP xxx.com:636
auth: Error: ldap_new_socket: 33
auth: Error: ldap_prepare_socket: 33
auth: Error: ldap_connect_to_host: Trying xxx 636
auth: Error: ldap_pvt_connect: fd: 33 tm: 5 async: 0
auth: Error: ldap_ndelay_on: 33
auth: Error: attempting to connect:
auth: Error: connect errno: 115
auth: Error: ldap_int_poll: fd: 33 tm: 5
auth: Error: ldap_is_sock_ready: 33
auth: Error: ldap_ndelay_off: 33
auth: Error: ldap_pvt_connect: 0
auth: Error: ldap_int_tls_start: ldap_int_tls_connect needs read
auth: Error: ldap_int_tls_start: ld 0x5cebfad42c70 4 s 999914 us to go
auth: Error: ldap_int_poll: fd: 33 tm: 4
auth: Error: ldap_is_sock_ready: 33
auth: Error: ldap_ndelay_off: 33
auth: Error: TLS: peer cert untrusted or revoked (0x42)
auth: Error: TLS: can't connect: (unknown error code).
auth: Error: ldap(ldaps://xxx.com:636): Can't connect to server: ldaps://xxx.com
Server uses a normal letsencrypt certificate that is valid (checked with openssl).
So look like v2.4.3 broke using the default system's CAs?
On 30/03/2026 13:28 EEST Patrick Cernko via dovecot <dovecot@dovecot.org> wrote:
Hi Markus, hi list,
On 2026-03-30 12:15:15, markus-dovecot--- via dovecot wrote:
Unfortunately the upgrade to v2.4.3 broke the ldap connection.
I have configured an ldap connection like this:
ldap_uris = ldaps://xxx.com ldap_auth_dn = uid=xxx,ou=general accounts,dc=xxx,dc=com ldap_auth_dn_password = xxx ldap_base = dc=xxx,dc=com passdb ldap { ldap_bind = yes [...] }v2.4.3 cannot connect and says:
auth: Error: ldap(ldaps://xxx.com636): Can't connect to server: ldaps://xxx.comLdap server logs:
ACCEPT from IP=[XXX]:45674 (IP=[::]:636) TLS established tls_ssf=256 ssf=256 tls_proto=TLS1.3 tls_cipher=AES-256-GCM closed (connection lost)Downgrade to dovecot v2.4.2 makes it work again.
Was there any ldap change in v2.4.3 that required a config change?
I had a similar error. In my case, dovecot was missing the CA certificate for the cert of the LDAP server, as it was not included in the OS' ca-certificates bundle. I fixed it in my case with:
ssl_client_ca_file = /path/to/ldapservers-ca-certificate.crt
Seems like dovecot did not check the CA signing the LDAP server's certificate before 2.4.3.
Best,
Patrick Cernko <pcernko@mpi-klsb.mpg.de> +49 681 9325 5815
It did check the CA cert validity before, but in 2.4.3 the code interacting with libldap TLS settings was improved which changed this. So dovecot did check LDAP certs but the way it was enabling these with libldap was clearly not 100% correct.
Aki
Thanks for the information.
Ubuntu has the trusted CAs stored in /etc/ssl/certs/ (afaik), so dovecot has to be told to use this directory and trust those CAs?
Or is this actually a bug that you have to manually specify the trusted CAs and it is not using the system wide's by default?
On 30/03/2026 13:50 EEST Wendy Norm via dovecot <dovecot@dovecot.org> wrote:
Thanks for the information.
Ubuntu has the trusted CAs stored in
/etc/ssl/certs/(afaik), so dovecot has to be told to use this directory and trust those CAs?Or is this actually a bug that you have to manually specify the trusted CAs and it is not using the system wide's by default?
This is actually a bug, as you stated.
Aki
participants (4)
-
Aki Tuomi
-
markus-dovecot＠doits.de
-
Patrick Cernko
-
Wendy Norm