私はそれを短く維持しようとします。 beta.example.comに私のサーバーをメールサーバーとして使用させたいと思います。私はdovecotとpostfixが証明書に1行しかないことを見ています。だから私はmail.example.comに対して完全に有効な証明書を作成しました。 Thunderbirdを使用してメールサーバー（beta.example.com）に接続しようとしましたが、証明書がmail.example.comに属しているという誤ったドメイン警告が表示されました。私はどこで混乱しましたか？ mxレコードにはmail.example.comがあるので、証明書がmail.example.comのものであることを知る必要はありませんか？例外を追加しましたが、まだ失敗します（パスワードの入力を求められた後）。私のサーバーを見てみると、Thunderbirdが間違った証明書データを提供しているので、dovecotが接続を拒否しているようです。
答え1
証明書の真の目的、mail.example.comつまり予期したものとは異なるサーバーへの偶発的な接続を防ぐことですbeta.example.com。接続するドメインに対して発行された証明書を構成する必要があります。メールクライアントが接続している場合は、beta.example.com証明書が必要ですbeta.example.com。
別の証明書を取得するか、beta.example.comそれをサブジェクト代替名として使用するか、mail.example.comIPを指しますbeta.example.com。
答え2
クライアントがに接続するように設定されていますmail.example.com。
（証明書から）クレームに接続するサーバーbeta.example.com。
mail.example.comとは同じではないため、beta.example.com顧客は不一致について不平を言います。これは完全に意図的に設計されています。
動作させるには、クライアントが指すホスト名と一致するサブジェクト代替名を含む証明書を提供するようにメールサーバーを構成する必要があります。ホスト名が最終的にIPアドレスに解決される方法は重要ではありません。
以前は、証明書の「一般名」フィールドにホスト名を入力しましたが、この方法は廃止されました。必要に応じてホスト名を証明書のCNとして使用できますが、最適な互換性を得るには次のものが必要です。返品SANだと思います。 CSRが直接これを実行しない場合、ほとんどのCAはCNをSANとしてサービスとして提供すると思いますが、一部は証明書を検証しない可能性があります。
必ず使用する必要がある場合同じ証明書PostfixとDovecotの場合、何らかの理由で必要な場合別のホスト名両方（たとえば、smtp.example.comおよびpop.example.com）を公開するには、関連する両方のホスト名に有効な証明書が必要です。これは、マルチホスト名証明書またはワイルドカード（*.example.com）証明書を使用して実行できます。
返品、MX（メール交換）DNS RRは、実際には特定のドメインのメールを処理するメールサーバーへの着信SMTP接続にのみ関連します。ここで、リモートメールサーバーは最初は受信者ドメインのみを知っています。たとえば、これは完全に有効です。
example.com. MX 0 mail.example.com.
mail.example.com. CNAME beta.example.com.
beta.example.com. A 192.0.2.123
実際には推奨されませんが、RRを非正規のRRとして指定すると、一部のパーサーをブロックできます。ただし、リモートシステムのパーサーがこれを受け入れると（ほとんどの場合）、上記は実際にはユーザーが持っているものと同じです。
example.com. MX 0 mail.example.com.
mail.example.com. A 192.0.2.123
どちらの場合も、リモートMTA（メール転送エージェント、現代では他のメールサーバーとSMTP通信を行うメールサーバー）がmail.example.com（RRで指定されたMXホスト名であるため）に接続するため、有効なmail.example.comにの証明書が必要です。
MUAはMXレコードを照会しません。とにかくわからない。受信（POP / IMAP）または送信（SMTP）で指定されたホスト名のアドレスを照会します。AこれはAAAAまれですが、A6 RRは使用されなくなりましたが、IPv6ではしばらく使用されます。A6メールサーバーを記録します。