如何从 XMPP (jabber) 服务器下载证书以在本地信任它?

如何从 XMPP (jabber) 服务器下载证书以在本地信任它?

我正在尝试使用 Dino XMPP 客户端以及位于 communications.im 托管的 XMPP 域中的用户凭据进行登录。因此,域中没有 XMPP 服务器。相反,相应的 SRV 记录指向 conversations.im 上的 xmpps-hosting 或 xmpp-hosting。对话 XMPP 客户端通过 PKIX over Secure HTTP (POSH)、RFC 7711 验证连接证书,这是我配置的,但 Dino 尚不支持(第451章)。因此,它在自签名证书上连接失败:

默认情况下,我们的服务器将创建一个自签名证书。首次连接时,系统会要求您手动验证证书。您可以通过将提示的证书的 SHA-256 指纹与下面的指纹进行比较来完成此操作。

7e:9f:aa:ca:cb:2e:21:96:8d:85:8d:68:ef:04:ee:c6
0f:f7:78:44:12:ee:74:4b:a0:31:f8:10:96:03:72:b9

Dino 不支持手动验证证书(第57章,第452章)。因此,在尝试添加帐户时,它会循环并拒绝连接。如果我可以获得该证书并将其添加到系统信任存储中,那就不会有问题。但是,我找不到下载证书的方法。我尝试了类似的方法服务器故障答案,但无法获得证书:

$ nslookup -type=SRV _xmpps-client._tcp.riabenko.com
Server:     127.0.0.53
Address:    127.0.0.53#53

Non-authoritative answer:
_xmpps-client._tcp.riabenko.com service = 1 1 443 xmpps-hosting.conversations.im.

Authoritative answers can be found from:

$ openssl s_client -starttls xmpp -xmpphost riabenko.com -connect xmpps-hosting.conversations.im:443 -debug
CONNECTED(00000003)
write to 0x55db90fcebd0 [0x7fffa67799a0] (117 bytes => 117 (0x75))
0000 - 3c 73 74 72 65 61 6d 3a-73 74 72 65 61 6d 20 78   <stream:stream x
0010 - 6d 6c 6e 73 3a 73 74 72-65 61 6d 3d 27 68 74 74   mlns:stream='htt
0020 - 70 3a 2f 2f 65 74 68 65-72 78 2e 6a 61 62 62 65   p://etherx.jabbe
0030 - 72 2e 6f 72 67 2f 73 74-72 65 61 6d 73 27 20 78   r.org/streams' x
0040 - 6d 6c 6e 73 3d 27 6a 61-62 62 65 72 3a 63 6c 69   mlns='jabber:cli
0050 - 65 6e 74 27 20 74 6f 3d-27 72 69 61 62 65 6e 6b   ent' to='riabenk
0060 - 6f 2e 63 6f 6d 27 20 76-65 72 73 69 6f 6e 3d 27   o.com' version='
0070 - 31 2e 30 27 3e                                    1.0'>
read from 0x55db90fcebd0 [0x55db90f90020] (8192 bytes => 0)
read from 0x55db90fcebd0 [0x55db90f90020] (8192 bytes => 0)
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 117 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
read from 0x55db90fcebd0 [0x55db90f8e010] (8192 bytes => 0)

如何从服务器获取证书?

答案1

如果服务器配置了 STARTTLS,上述方法应该有效。客户端通常但不一定在默认端口 5222 上进行不加密连接,然后继续建立加密连接。然而,就我而言,服务器未配置 STARTTLS,这可能Secure Renegotiation IS NOT supported在输出中由 指示。因此,跳过-starttls有效:

$ openssl s_client -servername riabenko.com -connect xmpps-hosting.conversations.im:443
CONNECTED(00000003)
depth=1 C = DE, ST = Berlin, L = Berlin, O = Conversations, OU = Hosting, CN = Conversations CA
verify error:num=19:self-signed certificate in certificate chain
verify return:1
depth=1 C = DE, ST = Berlin, L = Berlin, O = Conversations, OU = Hosting, CN = Conversations CA
verify return:1
depth=0 CN = riabenko.com
verify return:1
---
Certificate chain
 0 s:CN = riabenko.com
   i:C = DE, ST = Berlin, L = Berlin, O = Conversations, OU = Hosting, CN = Conversations CA
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Aug 15 00:00:00 2021 GMT; NotAfter: Aug 15 00:00:00 2023 GMT
 1 s:C = DE, ST = Berlin, L = Berlin, O = Conversations, OU = Hosting, CN = Conversations CA
   i:C = DE, ST = Berlin, L = Berlin, O = Conversations, OU = Hosting, CN = Conversations CA
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Dec 13 11:54:28 2016 GMT; NotAfter: Dec 13 11:54:28 2026 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFwzCCA6ugAwIBAgICAowwDQYJKoZIhvcNAQELBQAwdDELMAkGA1UEBhMCREUx
DzANBgNVBAgMBkJlcmxpbjEPMA0GA1UEBwwGQmVybGluMRYwFAYDVQQKDA1Db252
ZXJzYXRpb25zMRAwDgYDVQQLDAdIb3N0aW5nMRkwFwYDVQQDDBBDb252ZXJzYXRp
b25zIENBMB4XDTIxMDgxNTAwMDAwMFoXDTIzMDgxNTAwMDAwMFowFzEVMBMGA1UE
AwwMcmlhYmVua28uY29tMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA
5Zn0YXgZOVxsHDDCNSrQlkM7llK2E1BiUKQ8JBPEeBjIP0WcfsrhXxVsiVg95TJK
H7sEFf9qPL1MSlT+4yM8luOOfb20XiFUsaZ4H4PUzi7w2xe11tQ5WZkZ3/eurY20
WeHjtkF6Tk50cHsRhrfR7LQVfAQjmozscw2QdfiEcAWV875wJn1TzdYOlD5ajsLU
h8zj/673mBrbz/e2NyUiQl9gbOvFn3vHOsU4Jbloq0frkwtdpjGSi4MkliWfrnb5
a5YBcVop8tigZIFH0DessnmUHLc4romH3dAg1PRS71tZLA/YC1zzw/7D+8jSXF7a
kVDcZcqqz2sjYnFPlwfc+O8rlUa0fdjpLpKlxs/YWgIlMdJibNVuonb3Q3CM/ZZp
hCMTYpObogOiYNZoq6EXaIBdskVSoXapLUOl+he4kNgWHZ/tNWQrEvnmwsBph6CZ
+yksHS6PZDFMrUMFzaeOnKFlvMJTVnElb8tvF6HUHNZVOQcqNIR4k+OjCWp824a8
o+UsYCM7BIqifEGsJRd6EI1nKtu5RUA2b2UTQVySfjcpVe0NSCsEoNXg4SONt2EU
40ieY31t/SDPEWMpORLseKBnnM4OVYgw3ui1j7PxYCrb/BRgADebUhsRv1Bjmp7o
u+RYbH5lRGST8duWDs2Tsk/3tIS++J8TpD3qt5817ZcCAwEAAaOBuzCBuDAMBgNV
HRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYI
KwYBBQUHAwIwHwYDVR0jBBgwFoAUMmRtKstGotqp53IyjFxGWuSeOY4wWAYDVR0R
BFEwT4IMcmlhYmVua28uY29tghdjb25mZXJlbmNlLnJpYWJlbmtvLmNvbYIScHJv
eHkucmlhYmVua28uY29tghJzaGFyZS5yaWFiZW5rby5jb20wDQYJKoZIhvcNAQEL
BQADggIBAJDwyHwJ2ddHGsRqQmBaRvKTzBt7nqIGevzIr6ezSMfXoutjzrQ0W4GV
e2hzaE4cjXYMvf/sDGZ89g0bSMKPUZzZVCiLTDDbdOAey+ECrrYI62CcPC8zJDIZ
Vy0oUfEzb9aeEIVmVYFqqfIp4Ecqs/WbzbK+DSV1Yrh/JA8NNG5Y3esh3LXfUaJP
lQyyedGjVC4TvDWiQocH6EbSEGLAIcjBX2XcXKHjn0/EjMxjsVMlxgUz01A3gn/2
8Tv8EypHl56inIuiu738G6gHaTQEDYVWakoNN/bJSCYlMp+KrBhi3FF3SsQllxoy
II/4WhPNngQxVgg54SBElGyXt6gyQ1VqJvHSiESr3XmU7riUofC3drmrX7PSzIX3
rLlQA+uT4AHg3DXQrwcXg001vI84QxWnkwnKbgE+9MgLy2CAKsE9/DwJoMakYNn9
LOumoOZOPguXppKboojRNHVRaac8X4/7SR6J0CFNGdcsb4bOtAioVqURSRE+PTQq
mlPWMi/PHqDrpQMvinBJZEjdMOGEweaesbcYMwpQtbGg4r1BA8gEEuiRVOeW1ykC
FxFxSrnDlvfhR08RywfPOhwf+rOs8G8QCiCZAaLKoNUPexigWUo20TsbigHwg69U
RralB5FBzrM01+4y0UV+umNRlEK8IhQDDl5Ap8LZGV/g8QMTk5+0
-----END CERTIFICATE-----
subject=CN = riabenko.com
issuer=C = DE, ST = Berlin, L = Berlin, O = Conversations, OU = Hosting, CN = Conversations CA
---
No client certificate CA names sent
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:ECDSA+SHA1:RSA+SHA224:RSA+SHA1:DSA+SHA224:DSA+SHA1:DSA+SHA256:DSA+SHA384:DSA+SHA512
Shared Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:RSA+SHA224
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3703 bytes and written 421 bytes
Verification error: self-signed certificate in certificate chain
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 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: 
    Session-ID-ctx: 
    Master-Key: CAA294AB238F342CAB537680C748895158A7D0ECC9292A467A816857F33FD454C35A4A2E374E3D0BDF29BACA0FE5DFCC
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1657319079
    Timeout   : 7200 (sec)
    Verify return code: 19 (self-signed certificate in certificate chain)
    Extended master secret: yes
---

^C

Ctrl我用+终止了连接C,将证书(以 开头-----BEGIN CERTIFICATE-----和结尾-----END CERTIFICATE-----)保存到文件中,然后按照发行版的说明将其添加到信任存储中,对于 Fedora 来说,信任存储是:

$ cat /etc/pki/ca-trust/source/README
This directory /etc/pki/ca-trust/source/ contains CA certificates and 
trust settings in the PEM file format. The trust settings found here will be
interpreted with a high priority - higher than the ones found in 
/usr/share/pki/ca-trust-source/.

=============================================================================
QUICK HELP: To add a certificate in the simple PEM or DER file formats to the
            list of CAs trusted on the system:

            Copy it to the
                    /etc/pki/ca-trust/source/anchors/
            subdirectory, and run the
                    update-ca-trust
            command.

            If your certificate is in the extended BEGIN TRUSTED file format,
            then place it into the main source/ directory instead.
=============================================================================

Please refer to the update-ca-trust(8) manual page for additional information.

相关内容