web-dev-qa-db-ja.com

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

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

それは私のドメインのいくつかの電子メールを受信するためにeximを実行します。

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

Eximが受信メール接続にTLS暗号化を提供するようにしたい場合、SSL証明書にどのホスト名を入力する必要がありますか？

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

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

sslsmtpcertificateexim
23
David North

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

SMTPクライアントが認証のレベルまたは
プライバシーはそれを継続するのに十分な高さではありません、それは発行する必要があります
TLSネゴシエーションが完了した直後のSMTP QUITコマンド。
SMTPサーバーが認証レベルまたは
プライバシーは継続するのに十分な高さではないため、返信する必要があります
クライアントからのすべてのSMTPコマンド（QUITコマンド以外）
554応答コード（「コマンド
セキュリティ不足のため拒否されました。」.

の信憑性を信じるかどうかの決定
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の状態
サービス対応の挨拶）。サーバーはすべての知識を破棄する必要があります
EHLOコマンドへの引数など、クライアントから取得
これは、TLSネゴシエーション自体から取得されたものではありません。クライアント
リストなど、サーバーから取得したすべての知識を破棄する必要があります
TLSから取得されなかったSMTPサービス拡張の
交渉自体。クライアントはEHLOコマンドを
TLSネゴシエーションが成功した後の最初のコマンド。

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

私の経験では、自己署名証明書はインターネットに直接接続されたメールサーバーで非常にうまく機能します。つまり、otherメールサーバーはそれらを検証する手間さえしません、発行機関やサブジェクト名に関係なく、TLS暗号化を提供できるものなら何でも喜んで受け入れます。

20
Massimo

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

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

11
mgorven

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

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

SSL/TLS接続が最初に開始されたとき（SMTPS）、サーバーは接続が確立される前にHELOメッセージが何を言っているかを確認する方法がないため、要求を行ったものを使用する必要があります。

STARTTLSの後にSSL/TLSを使用する場合、クライアントは引き続き、それが構成されたサーバーと通信することを意図しているため、確認する必要があります。失敗するとMITM攻撃が可能になります。

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

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

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

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

最新の方法は、ホスト名をサブジェクトの別名DNSエントリに配置することです。 ワイルドカードの使用もお勧めしません 。

8
Bruno

実際に行われていることをコピーするのが最善だと思います。 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）

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

1
Nicolas Guérinet

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

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

0
Dr I