入站 s2s 外部身份验证失败：证书不受信任
Failed inbound s2s EXTERNAL authentication: certificate not trusted
我 运行 遇到一个问题，即使用 ejabberd（版本 18.12.1 和 19.09.1）的几个安装无法通过 SASL EXTERNAL 报告 "certificate not trusted".
进行身份验证
证书适用于其他服务器，使用 openssl 检查似乎没问题：
$ 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
我联系了有问题的服务器的一位所有者并要求他获取 ejabberd 日志，但是它并没有透露太多信息：
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
据我所知，ejabber 在 openssl 周围使用了包装器，所以我也询问了服务器的所有者是否可以直接使用 openssl 检查证书并且它报告 OK:
$ openssl x509 -in cert.pem -text -noout
Repots everything to be OK.
任何人都可以阐明可能出了什么问题吗？
在这种特殊情况下，服务器的所有者在其 ejabberd 配置中包含了自定义 CA 包的配置（选项 ca_file: 不应 NOT/MUST 不使用！）它几乎是空的，导致失败验证我们的证书，这反过来会导致 "invalid certificate" 验证结果。
通常不应使用 ca_file（因此它甚至不包含在配置文档中）。
我 运行 遇到一个问题，即使用 ejabberd（版本 18.12.1 和 19.09.1）的几个安装无法通过 SASL EXTERNAL 报告 "certificate not trusted".
进行身份验证证书适用于其他服务器，使用 openssl 检查似乎没问题：
$ 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
我联系了有问题的服务器的一位所有者并要求他获取 ejabberd 日志，但是它并没有透露太多信息：
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
据我所知，ejabber 在 openssl 周围使用了包装器，所以我也询问了服务器的所有者是否可以直接使用 openssl 检查证书并且它报告 OK:
$ openssl x509 -in cert.pem -text -noout
Repots everything to be OK.
任何人都可以阐明可能出了什么问题吗？
在这种特殊情况下，服务器的所有者在其 ejabberd 配置中包含了自定义 CA 包的配置（选项 ca_file: 不应 NOT/MUST 不使用！）它几乎是空的，导致失败验证我们的证书，这反过来会导致 "invalid certificate" 验证结果。
通常不应使用 ca_file（因此它甚至不包含在配置文档中）。