communications.imでホストされているXMPPドメインにあるDino XMPPクライアントとユーザーの資格情報を使用してログインしようとしています。したがって、ドメインにXMPPサーバーがありません。代わりに、対応するSRVレコードは、会話.imのxmpps-hostingまたはxmpp-hostingを指します。インタラクティブXMPPクライアントは、私が設定したがまだDinoでサポートされていないセキュアHTTP（POSH）、RFC 7711を介してPKIX経由で接続証明書を検証します（第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.