mod_shared_roster_ldap: In state hello received SERVER ALERT: Fatal - Handshake Failure #3496
Labels
Comments
|
Could you check if there is anything in logs of your ldap server about this? From that error message it seems that this error is generated by your server, so it's hard to tell on client side what causes it. |
|
Will check it, no problem on it, our concerns is that we use other applications that bind also to openldap with ssl over 636 port. So normally we should have a workable solution. Will check and report, thank for your input |
|
in like in ejabber log when I test externally my connectivity to my ldap server I have To be sure that my openldap server get the wide cipher audience, I use in What ciphers and ssl protocol eldap is supposed to use ? |
|
Available ciphers depends mostly on erlang/openssl in your system. Could you running ejabberd debug console: |
Not sure about the trailing dot, I tested the two cases |
|
Yeah, dot is needed, but looks like this version of erlang doesn't recognize this option, i think log_level was added only in most recent version. |
not sure it helps, but erlang cannot connect itself :| |
|
Yes, this is exactly what ldap modules use to communicate over tls, that's why i asked you in first place to try with debug log_level, i was hoping that it show what it tries to negotiate. |
testing to use strong cipher with openldap like you can see with nmap, my slapd server talk only tls1.2 I wanted to see if eldap wanted to talk only with high ciphers however it is the same |
|
Even with a really strict policy, this is a workable bind of dokuwiki for the user admin either my ejabberd configuration is bad, or something doesn't work as expected in ejabberd for openldap :-? this is the dokuwiki configuration |
That list only includes RSA key-exchange ciphers. Erlang/OTP >= 21 disables those by default.
I would expect that to include far more than just the RSA key exchange ciphersuites reported by nmap. What does this report for you, on the same system?:
|
|
I think we run default of centos 7.9 on the server running openldap on the server running ejabberd |
|
On RHEL/CentOS OpenLDAP uses NSS for SSL/TLS, not OpenSSL, so that check wasn't particularly useful, sorry. Do you have a DH Parameter file ( |
|
thank for your help, I do not think we have a dh key for our configuration, I will report it |
|
I think I owe you a beer, when I can pay you something to drink, do you waste time at FOSDEM ? The key is ER21 expect a dh key, I run a default TLS openldap on Centos7 but without dh key |
|
erlang21 expects |
|
I would like to close this issue but I think we could have something to do maybe in the documentation of ejabberd or you think that the documentation already states somewhere for this requirement ? |
|
We closed the issue on our project, let close this one too, thank again for helping us to fix our issue. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Environment
erl +VConfiguration (only if needed): grep -Ev '^$|^\s*#' ejabberd.yml
Errors from error.log/crash.log
No errors from crash.log, only from
/var/log/ejabberd/ejabberd.logBug description
We provide a server configuration for ejabberd with an account provider that you can use locally or remotely based on samba AD or openldap.
We can bind remotely or locally our applications to openldap in plain text or encrypted therefore we have a workable configuration but ejabberd got an error about tls handshake failure when we try to use ldaps over 636, no matter it is local or remote openldap
If I change the account provider on the same server to samba AD I have no error, so it is not a certificate issue
I read in another issue #2344 (comment) and it seems that the downgrade to erlang 19 fixed the issue.
The text was updated successfully, but these errors were encountered: