メールサーバーで自己署名SSL証明書を使用すると、通信が妨げられますか？
このArsTechnicaの記事 によると、メールサーバーで自己署名証明書を使用することは悪い考えです。
前のシリーズでWebサーバーをセットアップしたとき、SSL/TLSを機能させることは推奨されましたが、オプションのステップでした。ただし、このガイドではこれはオプションではありません。メールサーバー用の有効なSSL/TLS証明書が必要です。ここで「有効」とは、自己署名されたものではなく、「認定された認証局（CA）によって発行されたもの」を意味します。 他のメールサーバーに対して自分のメールサーバーを識別するために自己署名証明書を使用することは、他のメールサーバーにメッセージの配信を拒否させるための優れた方法です。次に、他のサーバーのどれもそれと話したくないのでメールサーバーは孤独です、そしてそれは悲しいでしょう。サーバーを悲しませたくないのですか？
これは本当ですか？他のメールサーバーは、本当に自己署名SSL証明書を使用するメールサーバーとの対話を拒否しますか？もしそうなら、どれですか？または、これはほとんどすべての一般的なメールサーバーに当てはまりますか？
自己署名証明書で問題ありません。
数年にわたる私の経験では、メールサーバーの自己署名証明書に問題はありませんでした。私は最終的に StartSSL で署名されたものに切り替えましたが、相互運用性に識別可能な違いはありませんでした。
ServerFaultに関するこの投稿 も参照してください。
要するに、STARTTLSは認証ではなく暗号化に関するものです。認証を実行するためにロックダウンできますが、ほとんど（すべてではない）のSMTPサーバーのデフォルトは 便宜的暗号化 です。 SMTPはデフォルトでプレーンテキストであり、認証に必要な暗号化よりも暗号化が必要なので、強調しました。
接続をロックダウンすることは可能です。たとえば、Ironportが、既知のCAが署名した有効な証明書を要求するように構成されていることを確認しました（この場合、Entrustは好きですが、Comodoは好きではないため、証明書を変更してしまいました。他の人のIronportをデバッグするよりも簡単でした）。しかし、これはパートナーの暗号化を確実にしたい特定のドメインをロックダウンするためのものであり、日和見的な暗号化でそれを行う人を見たことがありません。
SSLによる暗号化は、次の手順で構成されます。
- 証明書を使用してピアを識別します。
- 次の通信用の鍵を作成して交換します。
- 以前に交換された鍵で暗号化された交換データ。
誰かが接続を聞いていると思うので、通常は暗号化を採用しています。このパッシブリスニングの小さなステップは、SSLが検出できる接続のアクティブな操作です。ただし、このためにはピアを適切に識別する必要があります。そうしないと、中間の誰かが適切なサーバーであると主張する可能性があります。
自己署名証明書では、誰でもあなたと同じ資格情報でそのような証明書を作成できるため、適切な識別は不可能です。つまり、自己署名証明書を単独で信頼するべきではありません。自己署名証明書は、別の方法で検証できる場合にのみ信頼する必要があります。この別の方法は、サーバー側での手動設定（通常、送信者が受信者を直接知っている場合を除いては当てはまりません）または [〜＃〜] dane [〜＃〜] による証明書の検証です。ここで、ドメインの所有者は、信頼されたDNSレコード内に証明書またはフィンガープリントを提供します（ DNSSec が必要）。
信頼されていない証明書を検出したときにサーバーが実際に行うことは異なります。証明書を受け入れてverify=NOはメールのReceivedヘッダーにありますが、他のユーザーは接続が安全でないと見なしてプレーンテキストにダウングレードするか、まったく接続しないため、SSLでの接続を拒否する可能性があります。送信サーバーの settings によって異なります。
現在、おそらくほとんどのメールサーバーは、証明書を検証できない場合でも、他のサーバーに正常に接続します。しかし、ますます「実際の」（検証可能な）証明書を使用しています。 Facebookからのレポートを 2014年5月 から 2014年8月 に比較すると、検証可能な証明書の使用がわずか4か月で30％から95％に移行することがわかります。つまり、近い将来、より多くのサーバーで実際の証明書の使用が必要になる可能性があります。
これは、よく知られたCAによって署名された証明書を使用する方が、自己署名証明書を使用するよりも間違いなく優れていることを意味します。しかし、それでもあなたが達成しようとしているセキュリティを提供しないかもしれません。オペレーティングシステムによって信頼されている100番目のCAのいずれかがそのような証明書を発行できるため、攻撃者がドメインの証明書も取得しようとする可能性があります。ただし、攻撃者はCAをハッキングするか、メールドメインを制御してCAが識別プロセス内で使用するメールをキャプチャする必要があるため、これは少なくとも別の自己署名証明書を作成するよりもはるかに困難です。
アクティブな中間者攻撃のもう1つの攻撃は、DNSを攻撃してメールを再ルーティングすることです。送信メールサーバーからドメインを担当するサーバーにメールをルーティングするには、送信サーバーがDNSルックアップを行う必要があります。メールサーバーの名前を含むドメインのMXレコード。送信サーバーの近くにいるアクティブな攻撃者は、このDNSルックアップを攻撃し、自分のサーバーを指す偽のMXレコードを提供する可能性があります。 TLSはここではもう役に立ちません。代わりに、DNSSecを使用してDNSレコードを保護する必要があり、送信者はこのレコードを確認する必要があります。
それとは別に、TLSはメールにエンドツーエンドのセキュリティを提供せず、ホップバイホップです。中間のメールサーバーはプレーンメールにアクセスできるため、完全に信頼する必要があります。エンドツーエンドの暗号化を取得するには、S/MIMEまたはPGPを使用する必要があります。このため、TLSは適切に実装されていても、TLSがメールに実際の（エンドツーエンドの）セキュリティを提供しないため、一部のサーバー管理者は適切なTLSをまったく気にしません。
証明書の信頼性は、信頼できる当事者の公開鍵を使用して検証されます。証明書スプーファーは、作成した任意の証明書に必要なデータを入力できますが、信頼できる当事者の秘密（署名）キーを持たないため、証明書に署名できません。信頼できる当事者のパブ、または検証鍵が間違った秘密（署名）鍵で使用された場合、署名は偽造されたものと見なされます。
これまでのところ、CA署名付き証明書と自己署名付き証明書のどちらでも違いはありません。
ただし、公開鍵の配布には問題があります。これは、アプリにインストールする比較的少数の主要なアプリケーションプロバイダーに安全に送信するだけで、公開鍵をより多くの人々に安全に配布できるため、証明書「権限」がExcelで機能する場所です。 「ブラウザベンダー」、メールサーバープロバイダーなど。したがって、自分の署名を検証するために使用される公開鍵は「確実に」自分のものであり、実際に何かに署名したかどうかを確認するために安全に使用できます。つまり、証明書。
自己署名者が公開鍵を安全に配布できる場合、つまり、ユーザーが自分の署名であることをユーザーが確実に知っている方法で配布し、したがって、自己署名証明書は、同一性が優れていることを考慮して、より優れていなくても同じくらい優れています他のCAと同様に、CA証明書リクエスタID検証よりもキー配布を通じて保証されます。
この観点から、問題はどのようにして安全かつコスト（または時間）効率的にpub keyを他のメールサーバーに配布およびインストールできるか、そして何がそうするようにあなたを駆り立てているかについては、より良いセキュリティ、CA $ upport aversionまたはその他それに値する。
これはもう本当ではありません。一部の電子メールサーバーは、提供された証明書の信頼チェーンを検証し、通過しない場合は接続を拒否し始めました。これにより、メールの送受信を防ぐことができます。
私たちのケースでは、メールガンを使用しており、デフォルトで受信サーバーに適切な証明書が必要な構成インターフェースに小さなスイッチがあります。