[SOLVED] Failed inbound s2s EXTERNAL authentication: certificate not trusted

I run into a problem that a couple of installations with ejabberd (versions 18.12.1 and 19.09.1) fail to authenticate with SASL EXTERNAL reporting that "certificate not trusted".

Certificate works with other servers and checking using openssl seems to be ok:

$ openssl s_client -connect tigase.me:5269 -xmpphost tigase.im < /dev/null -starttls xmpp-server

CONNECTED(00000005)
Can't use SSL_get_servername
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = tigase.im
verify return:1
---
Certificate chain
 0 s:CN = tigase.im
   i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
 1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFVzCCBD+gAwIBAgISBJ+Auz6lTvjxhhhTBpILEz0XMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xOTEyMTcyMjM3MjNaFw0y
MDAzMTYyMjM3MjNaMBQxEjAQBgNVBAMTCXRpZ2FzZS5pbTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAOMmPR+70SfSH7CV86VRMiJG8R7zT29VoctyT9u9
FGzzqkQeENbgCy4FfhmRnnh3j3n+JLKuwBUm7o2L4h3yUcd1h2Qy7qoahmX2Zu67
Ai3/rhnzJ1bnv87TIUVSYa0UEVmlUxmDDqR71D4bMsVgv9ZuEWsX5+EMvZgaT6lH
E1JMdy7qXPViHKYOZ7enM2MpN/9tDM2vrk1AYs4jYJT8v5Yd/ZMP5MwBUkM+nW48
IpasjqqhkYOuXfxB3+we/htd8eVP+VXEurr9aKjXFhfAwPjOTfANdAvztXK9Bt0e
rj1dKT8d4UUUmDw+kURwsTQx/HsVTWc7b9i4+7ElQHvf1NkCAwEAAaOCAmswggJn
MA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIw
DAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQUag62Rz3d3Fs3Boc+dHOs5QskphUwHwYD
VR0jBBgwFoAUqEpqYwR93brm0Tm3pkVl7/Oo7KEwbwYIKwYBBQUHAQEEYzBhMC4G
CCsGAQUFBzABhiJodHRwOi8vb2NzcC5pbnQteDMubGV0c2VuY3J5cHQub3JnMC8G
CCsGAQUFBzAChiNodHRwOi8vY2VydC5pbnQteDMubGV0c2VuY3J5cHQub3JnLzAh
BgNVHREEGjAYggsqLnRpZ2FzZS5pbYIJdGlnYXNlLmltMEwGA1UdIARFMEMwCAYG
Z4EMAQIBMDcGCysGAQQBgt8TAQEBMCgwJgYIKwYBBQUHAgEWGmh0dHA6Ly9jcHMu
bGV0c2VuY3J5cHQub3JnMIIBBAYKKwYBBAHWeQIEAgSB9QSB8gDwAHYAb1N2rDHw
MRnYmQCkURX/dxUcEdkCwQApBo2yCJo32RMAAAFvFjkuLwAABAMARzBFAiEAvEVu
g+CD03wS3bJDEI2as/G95KOoeOtT4j4tArXJNWwCIBzr1sbTFu3fGrBGj4IFJU79
SzEvLjkoHGYhCRSAOGq5AHYAB7dcG+V9aP/xsMYdIxXHuuZXfFeUt2ruvGE6GmnT
ohwAAAFvFjkuMAAABAMARzBFAiBoM0Q0o/wWr8/1kqbmfJxHX+zIRCNF801adrWt
HHIyxQIhAPK5mLW5i1LB0ns6djl3KgcyiL/qKa4u3tIOJzpYBOdcMA0GCSqGSIb3
DQEBCwUAA4IBAQB//VxN3YaU5oUv5P50tdgsireZK3QNIQ5RuC3Shf3F0pjy+Hls
d6wU/iBs+Bvp7iNcHGwChD/lvQFVcNK+a3qwTymHjchehTiCbASdvqkKmKIo5N/9
9hjfxv0Hn6HjYEtzPsIKcxDA0vzhZiQb0SEMm7uUGHPrgk5YB5fdfWGS5TDzVFyj
DoxfEFG3aAoVwkamlZa7F4mxNOla5Y1xxe7ztDKIV/tY4+is+xaAfIhJ0NKkOzHJ
Ndik5KQYI8Y2RoHxBqyJtOWwJFQFcMFN6ioE+lvcB1R8Xrd6QV6dAGjLnLV97nrr
KaTP4ze1DnkB0m8ClBNUJJ86PKvXFQSV+omy
-----END CERTIFICATE-----
subject=CN = tigase.im

issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3

---
No client certificate CA names sent
Client Certificate Types: ECDSA sign, RSA sign, DSA sign
Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:DSA+SHA256:ECDSA+SHA224:RSA+SHA224:DSA+SHA224:ECDSA+SHA1:RSA+SHA1:DSA+SHA1
Shared Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:DSA+SHA256:ECDSA+SHA224:RSA+SHA224:DSA+SHA224:ECDSA+SHA1:RSA+SHA1:DSA+SHA1
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3443 bytes and written 596 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-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    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 97534057D91C9DFBC0032604102359BE6A16CB989ABF3763F5C31DD7A880F2DF
    Session-ID-ctx:
    Master-Key: 4947A730EB482F8D98B2C1AAE46D6A2C897DC65D4210E486848AF3122BACFE0A6CA861E53055AD9EFD763F25951D481D
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1580751412
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: yes
---
DONE

I contacted with one owner of the problematic server and asked him to get ejabberd logs, however it doesn't reveal much:

2020-02-03 12:24:00.337 [info] <0.3151.0> (tls|<0.3151.0>) Received XML on stream = <<"<auth xmlns=\"urn:ietf:params:xml:ns:xmpp-sasl\" mechanism=\"EXTERNAL\">=</auth>">>
2020-02-03 12:24:00.337 [warning] <0.3151.0>@ejabberd_s2s_in:handle_auth_failure:198 (tls|<0.3151.0>) Failed inbound s2s EXTERNAL authentication push.tigase.im -> xmpp.uwpx.org (::ffff:52.13.210.187): certificate not trusted
2020-02-03 12:24:00.338 [info] <0.3151.0> (tls|<0.3151.0>) Send XML on stream = <<"<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><not-authorized/><text xml:lang='en'>certificate not trusted</text></failure>">>
2020-02-03 12:24:00.521 [debug] <0.3151.0>@ejabberd_hooks:safe_apply:231 Running hook s2s_in_closed: ejabberd_s2s_in:process_closed/2

As far as I'm aware, ejabber uses wrapper around openssl, so I also asked owner of the server if he could check certificate directly using openssl and it reported OK:

$ openssl x509 -in cert.pem -text -noout
Repots everything to be OK.

Could anyone shed some light what could be wrong?