SMTPサーバーのSSL証明書にはどのホスト名を含める必要がありますか？

サーバーfoo.example.comが192.0.2.1にあります

eximを実行して、いくつかのドメインの電子メールを受信します。

各ドメインには、mx.example.comを指すMXレコードがあり、これは192.0.2.1に解決されます

eximに着信電子メール接続用のTLS暗号化を提供させたい場合、SSL証明書にどのホスト名を入れる必要がありますか？

• foo.example.comは、サーバーがHELOでそれを言うからです。
• mx.example.comは、クライアントが接続するホスト名だからですか？

http://www.checktls.comは後者が正しいことを示唆していますが、決定的な答えは見つかりません。

これは実際にはどこでも明示的に定義されておらず、サーバーを「信頼する」必要があるかどうかは、クライアント（もちろん別のメールサーバー）に接続します。関連するRFC（RFC 2487）から引用：

SMTPクライアントは、認証または
プライバシーのレベルが継続するほど高くないと判断した場合、
TLSネゴシエーションが完了した直後にSMTP QUITコマンドを発行する必要があります。
SMTPサーバーは、認証または
プライバシーのレベルが継続するほど高くないと判断した場合、
クライアントからのすべてのSMTPコマンド（QUITコマンド以外）
に554応答コード（可能なテキスト文字列など）で応答する必要があります（SHOULD ）「
セキュリティの欠如によりコマンドが拒否された」など）。

TLSネゴシエーションで相手の信頼性を信じるかどうかの決定はローカルの問題です。ただし、
決定の一般的な規則は次のとおりです。

- A SMTP client would probably only want to authenticate an SMTP
  server whose server certificate has a domain name that is the
  domain name that the client thought it was connecting to.

これは基本的に意味することは、他の部分に指定された証明書、それは完全に依存受諾または拒否することについての決定を使用するであろう時にサーバーが提供TLS暗号化であり、おそらく可能性が証明書の名前は、それが接続されて同じようにしたいが、一致していなくても非常によく受け入れます。

しかし、待ってください、まだあります。同じRFCから再度引用：

TLSハンドシェイクが完了すると、SMTPプロトコルは
初期状態（サーバーが220
サービス準備完了グリーティングを発行した後のSMTPの状態）にリセットされます。サーバーは 、TLSネゴシエーション自体から取得されなかっ
たEHLOコマンドへの引数など、クライアントから取得された知識を破棄しなければなりません（MUST）
。クライアント
は
、TLS
ネゴシエーション自体から取得されなかったSMTPサービス拡張のリストなど、サーバーから取得された知識を破棄しなければなりません（MUST）。クライアントは
、TLSネゴシエーションが成功した後、最初のコマンドとしてEHLOコマンドを送信する必要があります。

したがって、TLSハンドシェイクの前にHELO / EHLO に応答してサーバーが言っていることは、実際にはまったく問題にならないようです。

私の経験では、自己署名証明書はインターネットに直接接続されたメールサーバーで非常にうまく機能します。つまり、他のメールサーバーはそれらを検証することすら気にせず、発行に関係なく、TLS権限またはサブジェクト名。

ドメインにメールを配信するMTAは、MXレコード（ホスト名を生成する）を検索し、そのホスト名のAレコードを検索します。したがって、接続先のホスト名はMXホスト名であるため、SSL証明書の共通名と照合されます。サーバーは必要なHELOホスト名を提供できるため、HELOホスト名を確認しても意味がありません。追加のセキュリティは提供されません。

ただし、メールを配信するときにSSL証明書を厳密に検証することは、現時点では特に有用ではありません。MTAは（ほとんどの場合）非SSL配信にフォールバックするからです。したがって、SSL証明書が検証するかどうかに関係なく、MXサーバーがSSLを提供する場合、賢明な構成はSSLを使用することです（認証なしの暗号化は暗号化なし、認証なしよりも優れているため）。したがって、この目的のために自己署名証明書を使用することもできます。

サーバー証明書を検証し、サーバーのホスト名と一致することを確認するタスクは、SSL / TLSを使用するプロトコルの場合、純粋にクライアントの役割です。

そのため、証明書のホスト名は、クライアントがアクセスしようとしている名前と一致する必要があります。

SSL / TLS接続が事前に開始される（SMTPS）場合、サーバーは接続が確立される前にHELOメッセージの内容を確認する方法がないため、要求を行った接続を使用する必要があります。

後STARTTLSにSSL / TLSを使用する場合、クライアントはまだ設定されたサーバーと通信しようとしているため、それでもチェックする必要があります。それに失敗すると、MITM攻撃が可能になります。

• C-> S：こんにちは、アリスです。ボブと話したいです。
• S-> C：こんにちは、チャックです。チャックの証明書です。
• C-> S：ああ、そうです、あなたの証明書はChuckにとって本当に有効です。続けましょう。
• ...アリスはボブとの安全な通信を望んでいたので、もちろんそこには欠陥があります。

どちらの場合も、使用する必要があるのはMXアドレスです。

ホスト名の一致ルールは、RFC 6125のプロトコル間で最近収集されましたが、完全に実装しているクライアントはほとんどありません（完全な変更というよりも、ベストプラクティスのRFCであり、まだかなり最近のものです）。

ではその付録、それは（から撮影する前にSMTPについて存在していたものをまとめたもので、RFC 3207およびRFC 4954）。特に、「クライアントは、安全でないリモートソース（たとえば、安全でないDNSルックアップ）から派生したサーバーホスト名の形式を使用してはなりません。」（もちろん、サーバーのバナーに適用されます）。これとは別に、SMTPレガシールールは、サブジェクトの別名（についてもう少しHTTPSよりリラックスしたはずの代わりに、必要があります使用すること）。

最新の方法は、ホスト名をサブジェクトの別名DNSエントリに間違いなく入れることです。ワイルドカードの使用も推奨されません。

実際に行われていることをコピーするのが最善だと思います。http://checktls.comを使用してyahoo.comのメールアドレスをチェックしました。yahoo では、ホスト名とmxドメインに異なるドメインを使用したことを願っています。したがって、ホスト名はyahoo.comであり、mxドメインはyahoodns.netで終わります

dig mx yahoo.com gives mta6.am0.yahoodns.net. among others

checktlsの結果：SSL証明書CN = MXドメイン（* .yahoodns.net）

シスコでも同じことをしましたが、同じ結果になりました。

SSL / TLS暗号化では、クライアントは常にリモートマシン上の「実際の」/「宣言された」ホスト名と証明書に含まれる情報との対応をチェックします。

したがって、おそらくfoo.example.comを設定するか、ワイルドカード証明書を生成する必要があります;-)