ポート993でSSL接続を使用し、キーネゴシエーションでECDHEを使用してOutlook 2019をCyrus imapdサーバーに接続しようとしています。私が何をしても、imapサーバーが正しく設定されていても動作しません。
これをデバッグするために、 ssldump -a -A -H -i enp0s3サーバー上で実行し、接続しようとしているOutlookの出力を観察しました（簡潔にするために、最初のC - > Sハンドシェイクにほとんどの暗号スイートのリストを残しました）。
New TCP connection #1: odo.lab.example.de(58717) <-> morn.lab.example.de(993)
1 1 0.0019 (0.0019) C>S V3.3(178) Handshake
ClientHello
Version 3.3
random[32]=
65 b1 2e 3c bb 7c 4d 04 03 0e 34 49 62 48 e5 d9
22 c6 c9 c7 22 d4 e5 a0 76 44 64 9b a3 9d d5 bf
cipher suites
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
...
compression methods
NULL
extensions
server_name
host_name: imap.lab.example.de
supported_groups
ec_point_formats
signature_algorithms
session_ticket
extended_master_secret
renegotiation_info
1 2 0.1245 (0.1225) S>C V3.3(69) Handshake
ServerHello
Version 3.3
random[32]=
3c ef 0c 80 c8 c2 35 85 90 20 8e 6f f4 e0 93 fe
78 60 32 23 11 ec 56 df 3f f3 c6 e2 14 2f e5 2b
session_id[0]=
cipherSuite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
compressionMethod NULL
extensions
renegotiation_info
server_name
ec_point_formats
session_ticket
extended_master_secret
1 3 0.1245 (0.0000) S>C V3.3(1291) Handshake
Certificate
1 4 0.1245 (0.0000) S>C V3.3(333) Handshake
ServerKeyExchange
params
Not enough data. Found 327 bytes (expecting 32767)
1 5 0.1245 (0.0000) S>C V3.3(4) Handshake
ServerHelloDone
1 0.1254 (0.0009) C>S TCP FIN
1 0.1257 (0.0002) S>C TCP FIN
ご覧のとおり、クライアントとサーバーは必須パスワード（TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384）に同意します。次に、サーバーはクライアントに証明書を送信するように見えます（自己署名証明書ですが、Windowsの信頼できるルートCAに証明書を追加したため問題ありません）。
しかし、鍵交換に問題があるようです。Not enough data. Found 327 bytes (expecting 32767)ほぼ一日を投資したにもかかわらず、それが意味するものと解決策を生涯知ることはできません。
最初は、これが証明書ファイルに欠けているDHパラメータに関連している可能性があると思いました。ただし、（EC）DHEにはこれらのパラメータは必要ありません。一時バージョンの目的は、パラメータを動的に計算して定期的に置き換えることです。
IMAPサーバーが使用する鍵または証明書に追加情報を追加する必要がありますか？新しく作成する必要がある場合は問題ありません。
opensslCyrus imapdはSSL / TLS暗号化にOpenSSLを使用しているため、この質問にタグを割り当てました。サーバーのOpenSSLバージョンは1.1.1wです。
また、Outlook（Windows側）がTLS 1.2を使用していることを確認しました。これは上記のコンソール出力に反映されます（Version 3.3TLS 1.2を示します）。
ベストアンサー1
@Steffen Ullrichとdave_thompson_085のコメントはすべて正しいです。
メッセージはNot enough data. Found 327 bytes (expecting 32767)サーバーやクライアントではなくssldumpから来ます。私たちがSSL接続を分析するために使用するプログラムにはこのようなバグが含まれているので、私たちを間違ったパスに設定するのは残念です。
この質問は、いくつかの理由で分析するのが難しいです。
まず、schannelロギングは通常Windowsで有効になっておらず、それをオンにしてもイベントビューアでschannelのエントリを見ることはできません。ところで数時間後にこんなメッセージがたくさん出ました。 （これまで何も変えなかったと誓います。）
第二に、「ホーム」と呼ばれるさまざまなソフトウェアコンポーネント（Windowsコンポーネントや他のアプリケーションやサービス）から多数のメッセージがあります。約 1000 個の schannel 項目をスクロールした後、TLS 警告 43、イベント ID 36888 の項目が 1 つ見つかりました。この警告は次のことを意味しますunsupported_certificate（参照ここ30ページ）。
第三に、この表現により、サーバー証明書に特別なキー使用フィールドを追加する必要があると考えられ、最終的に拡張され、これに多くの時間を無駄にしました。
しかし、最終的にOutlook（またはschannel）はサーバー証明書が期限切れになるのが好きではないことに気づきました。しかし、これはThunderbirdでは問題ではありません。 Windowsは実際に問題が何であるかを知ることはできず、代わりに私に合わない役に立たない誤解を招くエラーメッセージを表示します。
要約：
コアコンセンサスに問題はありません。代わりに、ssldump私が使用したバージョンには私を誤解させるバグが含まれていました。問題は、サーバー証明書が期限切れになり、OutlookとWindowsが合理的なエラーメッセージを表示しないことです。