ldap_auth_provider - 553 - WARNING - sentinel - Error during LDAP authentication: ("('socket ssl wrapping error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unsuitable certificate purpose (_ssl.c:992)',)",)

[pravi]

Description

ldap authentication abruptly stopped working. This was working for many years and the breakage seems to be after updating to 1.108.0. Strangely same version of synapse on talk-staging.puri.sm can authenticate against the same ldap server. Other services are authenticating correctly with the same ldap server.

I could reproduce the error when cloning the server and with a new blank database and changing server name to talk-troubles.puri.sm in nginx and homeserver.yaml

I tried to clone talk-staging.puri.sm and replace database and server name with talk.puri.sm, but the error is still there.

Steps to reproduce

• this was a working synapse setup
• that broke with an upgrade from Debian bullseye to Debian bookworm and synapse 1.76.0 to 1.108.0

Homeserver

talk.puri.sm

Synapse Version

1.108.0

Installation Method

pip (from PyPI)

Database

PostgreSQL

Workers

Multiple workers

Platform

Digital Ocean cloud VM with Debian GNU/Linux bookworm/stable.

Configuration

using ldap authentication

Relevant log output

2024-06-21 12:52:26,678 - synapse.access.http.8008 - 473 - INFO - GET-0 - 159.65.63.152 - 8008 - {None} Processed request: 0.001sec/0.000sec (0.001sec, 0.000sec) (0.000sec/0.000sec/0) 78B 200 "GET /_matrix/client/v3/login HTTP/1.0" "gomuks/0.3.0 mautrix-go/v0.11.1" [0 dbevts]
2024-06-21 12:52:27,207 - synapse.rest.client.login - 341 - INFO - POST-1 - Got login request with identifier: {'type': 'm.id.user', 'user': '@praveen.arimbrathodiyil:talk.puri.sm'}, medium: None, address: None, user: None
2024-06-21 12:52:27,208 - ldap_auth_provider - 138 - DEBUG - POST-1 - Attempting LDAP connection with ['ldaps://ldap.puri.sm:636']
2024-06-21 12:52:27,208 - ldap_auth_provider - 527 - DEBUG - sentinel - Established LDAP connection in simple bind mode: ldaps://ldap.puri.sm:636 - ssl - user: cn=talk-staging,ou=dsa,dc=puri,dc=sm - not lazy - unbound - closed - <no socket> - tls not started - not listening - SyncStrategy - internal decoder
2024-06-21 12:52:27,592 - ldap_auth_provider - 553 - WARNING - sentinel - Error during LDAP authentication: ("('socket ssl wrapping error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unsuitable certificate purpose (_ssl.c:992)',)",)
2024-06-21 12:52:27,593 - ldap_auth_provider - 658 - WARNING - sentinel - Error during LDAP authentication: ("('socket ssl wrapping error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unsuitable certificate purpose (_ssl.c:992)',)",)
2024-06-21 12:52:27,593 - ldap_auth_provider - 238 - WARNING - sentinel - Error during ldap authentication: ("('socket ssl wrapping error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unsuitable certificate purpose (_ssl.c:992)',)",)
2024-06-21 12:52:27,593 - synapse.storage.database - 912 - WARNING - sentinel - Starting db txn 'get_users_by_id_case_insensitive' from sentinel context
2024-06-21 12:52:27,593 - synapse.storage.database - 978 - WARNING - sentinel - Starting db connection from sentinel context: metrics will be lost
2024-06-21 12:52:27,596 - synapse.handlers.auth - 1435 - WARNING - sentinel - Failed password login for user @praveen.arimbrathodiyil:talk.puri.sm
2024-06-21 12:52:27,596 - synapse.http.server - 130 - INFO - sentinel - <XForwardedForRequest at 0x7fa1f4222010 method='POST' uri='/_matrix/client/v3/login' clientproto='HTTP/1.0' site='8008'> SynapseError: 403 - Invalid username or password

Anything else that would be useful to know?

This was reproduced on 3 servers but one old server was working with same synapse version and ldap server.

[pravi]

Today talk-staging.puri.sm also failed. For now used a work around - replacing tls with an SSH tunnel. SSH tunnel is created from synapse server to ldap server on 389 and in synapse configuration changed connection to localhost:389 and start_tls: false. This is working, new sessions are working.

[pravi]

nodejs/node#27825 (comment) seems to be the issue we have here as well.