Failed inbound s2s EXTERNAL authentication

[97zgxgw]

What version of ejabberd are you using?
17.11

What operating system (version) are you using?
Ubuntu 16.04

How did you install ejabberd (source, package, distribution)?
from ejabberd-17.11-linux-x86_64-installer.run

What did not work as expected? Are there error messages in the log? What
was the unexpected behavior? What was the expected result?
I create SSL cert from gandi.net, create a user and login to jabber and all fine.
I add new contact to jabber from other server and when i try authorize him in log i see this
<0.486.0>@ejabberd_s2s_in:handle_auth_failure:206 (tls|<0.485.0>) Failed inbound s2s EXTERNAL authentication otherserver.im -> myserver.com (::FFFF:144.7.1.2): unable to get local issuer certificate

And all my contact in offline.

[weiss]

Failed inbound s2s EXTERNAL authentication otherserver.im -> myserver.com

So you don't trust the certificate offered by otherserver.im.

Do you have mod_s2s_dialback: {} in your list of modules?

[97zgxgw]

Yes mod_s2s_dialback: {} enabled in modules section of my ejabberd.yml

[97zgxgw]

I add
s2s_cafile: "/etc/ssl/certs/ca-certificates.crt"
and my issue resolved, but i thing it is workaround ...

[zinid]

A workaround to what? How to tame openssl on every platform?

[zinid]

Ah, this is the installer.
The installer will be fixed by release of 17.12.

[97zgxgw]

Why i need to do when 17.12 is released ?

[97zgxgw]

What wrong with 17.11 installer ? I have another way to fix my issue ?

[zinid]

You need nothing to do. The installer will be shipped with CA bundle (from Mozilla), and ca_file would be configured in the default config pointing to the bundle.

[zinid]

No, s2s_cafile is normal workaround to your problem.

[laszlovl]

I ran into this problem on a 18.04 install as well.

How about adding s2s_cafile: "/etc/ssl/certs/ca-certificates.crt" to the https://github.com/processone/ejabberd/blob/master/ejabberd.yml.example example config file?

[zinid]

Our installers have already Mozilla's CA bundle included and configured in ca_file option (and it's used as a fallback if s2s_cafile is not set).
I don't think it's a great idea to set the option in ejabberd.yml.example because the location of the CA bundle is OS specific. It's supposed that you know what you do when building ejabberd from source and you're prepared to configure more.

[laszlovl]

I do use the DEB package, but I copied the config file from a previous install and compared it with https://github.com/processone/ejabberd/blob/master/ejabberd.yml.example to see if anything needed changing.

You're right that the location of ca-certificates.crt may be different, so perhaps add it as commented-out so people can easily see that the option exists? (I came across this bugreport before, but since s2s_cafile isn't mentioned in either ejabberd.yml.example or the documentation, I thought it was no longer relevant after the recent SSL related changes)

[zinid]

so perhaps add it as commented-out so people can easily see that the option exists?

There is already commented ca_file. Since it's used as a default value if s2s_cafile is not set I don't see the reason to set it explicitly once again.

[laszlovl]

Right, I didn't know that. In that case, perhaps update the comment for that configuration option?

If your system provides only a single CA file (CentOS/FreeBSD)

That reads as if you only need to set this option if your system doesn't provide individual CA certificate files in /etc/ssl/certs (CentOS/FreeBSD). But if I understand it correctly now, the option needs to be set on each and every system for s2s ssl validation to work.

[zinid]

But if I understand it correctly now, the option needs to be set on each and every system for s2s ssl validation to work.

No. This depends on your openssl configuration. The problem you're facing is strictly speaking a problem of your openssl library which is configured/compiled incorrectly (its defaults are not set to the location of your OS bundle).

[zinid]

Whatever, it's OK for me to rephrase the comment so it doesn't confuse people.

[laszlovl]

No. This depends on your openssl configuration. The problem you're facing is strictly speaking a problem of your openssl library which is configured/compiled incorrectly (its defaults are not set to the location of your OS bundle).

OK, that's unfortunate. This is on a Ubuntu 18.04 LTS system, so this'll likely affect plenty of other people for a few years to come.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.