How to troubleshoot 'SSLHandshakeFailed' when trying to connect to LDAP

Getting advice
,
1

Hi all,

Since last weekend, ldap users, from a specific “user federation” had their login denied.
Presumably because of security update of our OpenSSL.
OpenSSL 3.0.13 30 Jan 2024 (Library: OpenSSL 3.0.13 30 Jan 2024)
Ubuntu 24.04.3 LTS
Keycloak - Version 26.5.2

When testing the connection we now get

Error when trying to connect to LDAP: 'SSLHandshakeFailed'

On the other hand: I can do a CLI handshake:

openssl s_client -connect friendlyserver.friendlydomain:636

results in 

SSL handshake has read 5401 bytes and written 634 bytes
Verification: OK




New, TLSv1.2, Cipher is AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.2
Cipher    : AES256-GCM-SHA384
Session-ID: 42A13C4D7038C9B5E6F8DA551105C47A564123CD9C566E4F900BB18E439A7CF6
Session-ID-ctx:
Master-Key: B2658B9D123695A6195BDD797131047B325B0A71AD3B1312478665E31A1E1CCBADB637BB322D439CB1C6CA29EF218B22
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 75 61 b6 51 06 c5 eb 6c-51 9e 01 27 48 08 9c 98   ua.Q…lQ..'H…
0010 - 4d 64 3d 7c d8 6c 78 7b-f3 c2 01 87 8d 47 7e 89   Md=|.lx{…G~.
0020 - b4 49 b1 83 02 5b 33 e9-1b c1 f0 d2 a4 85 8e 3e   .I…[3…>
0030 - 6c 2d d0 fa cd f3 72 34-c1 ab d3 0a fa d2 c4 8d   l-…r4…
0040 - 7e 8e ce 4a 40 6f 4b fb-98 a4 70 6e 67 9f 47 05   ~..J@oK…png.G.
0050 - bf e5 bd 1a 6e 33 d5 04-89 61 bb 16 ef 88 3c 8e   …n3…a…<.
0060 - 39 f8 90 16 4a 06 c4 f7-f7 5f ca bc 06 ac f5 7d   9…J…_…}
0070 - 0b 6f 80 51 93 4f 07 68-37 9e 25 24 80 93 2a 4b   .o.Q.O.h7.%$..*K
0080 - 0d 4b b9 70 25 8b 03 32-d2 c2 39 d6 86 25 b8 b7   .K.p%..2..9..%..
0090 - b9 7a 6b 12 30 e0 d1 9e-4c 69 fc 70 e5 85 ec 03   .zk.0…Li.p…
00a0 - 0d a8 7d a2 45 db 70 6a-af c2 08 62 b2 bf 0c 9f   ..}.E.pj…b…

Start Time: 1770238308                                            
Timeout   : 7200 (sec)                                            
Verify return code: 0 (ok)                                        
Extended master secret: no

(I have not included the certificate details for security/privacy reasons)

What would be the best way to proceed?
Given that I have no control over the LDAP server, I can only suggest them to upgrade their OpenSSL to a recent version with secure current key-exchange and cipher protocols.

Thanks,

Joost

2

Hi Joost,

do have any solution in the meantime? I Have the same environment an get the same failure.

regards Thomas

3

Alas not.

I think the way to go is to force keycloak to use the “AES256-GCM-SHA384” cipher which can do a successfull handshake via “openssl s_client -connect”

We tried putting that in the keycloak conf files in a couple ways but were unsuccesfull until now.

4

what’s the part directly above the VERIFICATION OK ?

SSL handshake has read 3087 bytes and written 376 bytes

I don’t think there’s anything wrong with AES256-GCM-SHA384. But it might be that the server is using RSA for key exchange instead of edch.

example using github.com :
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits

SSL handshake has read 3087 bytes and written 376 bytes
Verification: OK
(rsa alone for key exchange and signing is considered weak).

5

I see that github uses “sigalg: ecdsa-with-SHA256”

The ldap/identity provider uses "sigalg:sha256WithRSAEncryption"
This is rejected by keycloak?

i:C=GR, O=Hellenic Academic and Research Institutions CA, CN=GEANT TLS RSA 1
a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
v:NotBefore: Dec 9 12:12:26 2025 GMT; NotAfter: Dec 9 12:12:26 2026 GMT
1 s:C=GR, O=Hellenic Academic and Research Institutions CA, CN=GEANT TLS RSA 1
i:C=GR, O=Hellenic Academic and Research Institutions CA, CN=HARICA TLS RSA Root CA 2021
a:PKEY: RSA, 3072 (bit); sigalg: sha256WithRSAEncryption
v:NotBefore: Jan 3 11:15:00 2025 GMT; NotAfter: Dec 31 11:14:59 2039 GMT
2 s:C=GR, O=Hellenic Academic and Research Institutions CA, CN=HARICA TLS RSA Root CA 2021
i:C=GR, O=Hellenic Academic and Research Institutions CA, CN=HARICA TLS RSA Root CA 2021
a:PKEY: RSA, 4096 (bit); sigalg: sha256WithRSAEncryption
v:NotBefore: Feb 19 10:55:38 2021 GMT; NotAfter: Feb 13 10:55:37 2045 GMT

6

I have the impression that ECDSA key exchange is still rare for SSL/TSL
(askubuntu has I just saw)
gmail/google is still RSA

Certificate chain
0 s:CN=``www.gmail.com
i:C=US, O=Google Trust Services, CN=WR2
a:PKEY: EC, (prime256v1); sigalg: sha256WithRSAEncryption
v:NotBefore: May 25 08:38:39 2026 GMT; NotAfter: Aug 17 08:38:38 2026 GMT
1 s:C=US, O=Google Trust Services, CN=WR2
i:C=US, O=Google Trust Services LLC, CN=GTS Root R1
a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
v:NotBefore: Dec 13 09:00:00 2023 GMT; NotAfter: Feb 20 14:00:00 2029 GMT
2 s:C=US, O=Google Trust Services LLC, CN=GTS Root R1
i:C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA
a:PKEY: RSA, 4096 (bit); sigalg: sha256WithRSAEncryption
v:NotBefore: Jun 19 00:00:42 2020 GMT; NotAfter: Jan 28 00:00:42 2028 GMT

7

Are you sure about this? would I be able to test this with an alternative test ldap server?