Httpsは証明書がなくても機能しますか？
最近、インフラストラクチャチームが開発チームに、httpsの証明書は必要ないことを伝えました。彼らは、証明書を購入することの唯一の利点は、彼らが正しいウェブサイトに接続していることを消費者に安心させることであると述べました。
これは、httpsについて私が想定したすべてに反します。
私は wikipedia を読み、httpsを構成するには信頼できる証明書または自己署名証明書のいずれかが必要であると述べています。
IISがany証明書なしでhttpsに応答するように構成できますか？
いいえ。証明書が必要です。自己署名することもできますが、サーバーとクライアントの間でセッション対称鍵を交換してデータを暗号化するには、公開鍵と秘密鍵のペアが必要です。
つまり、システムをどのように展開したいかによって、微妙なケースが存在する可能性があります。
HTTPSはSSL/TLSを介したHTTPであり、SSL/TLSを使用できます 証明書なし、またはX.509以外のタイプの証明書付き 。
- 匿名の暗号スイート：暗号化を提供できますが、認証はありません。セキュリティに関する限り、あまり役に立たない...引用するには RFC 4346 ： "anonymous Diffie-Hellmanは、man-in-the-ミドル攻撃。 "
- 事前共有キー ：リモートIDを検証する独自のメカニズムがありますが、キーの共有の性質により、独自の一連の問題が発生します（特に限定的な展開）。
- Kerberos暗号スイート ：クライアントは、Kerberosプリンシパル名に対してサーバーのIDを検証できます。
厳密に言うと、 HTTP over TLS仕様 は次のように述べています。
一般に、HTTP/TLS要求はURIを逆参照することによって生成されます。その結果、サーバーのホスト名はクライアントに認識されます。ホスト名が利用可能な場合、クライアントは中間者攻撃を防ぐために、サーバーの証明書メッセージに示されているサーバーのIDに対してホスト名をチェックする必要があります。
クライアントがサーバーの予期されるIDに関する外部情報を持っている場合、ホスト名チェックは省略される場合があります。 （たとえば、クライアントはアドレスとホスト名が動的であるマシンに接続しているかもしれませんが、クライアントはサーバーが提示する証明書を知っています。）このような場合、許容できる証明書の範囲を可能な限り狭めることが重要です。中間者攻撃を防ぐため。特殊なケースでは、クライアントがサーバーのIDを単に無視することが適切な場合がありますが、これにより接続がアクティブな攻撃に対して開かれたままになることを理解する必要があります。
つまり、X.509証明書での使用を明確に意図しています（RFC 2459を明確に参照し、後でRFC 3280および5280に置き換わりました：X.509証明書を使用したPKI）。
Kerberos暗号スイートを使用している場合、エッジケースが発生する可能性があります。サーバーのKerberosサービスチケットを処理することは、リモートパーティのIDを検証するために、通常のHTTPSのX.509証明書と同じ目的を持っていると想定できる場合があります。 RFC 2818の規則に完全には適合しません（「に該当する可能性があります）。クライアントがサーバーの予期されるIDに関する外部情報を持っている場合、ホスト名チェックは省略できます（MAY）。 "）、しかしそれは完全にばかげたことではないでしょう。そうは言っても、通常のブラウザーは一般にTLS Kerberos暗号スイートをサポートしているとは思いません（数値はSPNEGO認証を介してKerberosをサポートできますが、それは無関係です）。さらに、これはKerberosの使用が適切な環境でのみ機能します。
「[与える]正しいウェブサイトに接続していることを消費者に安心させる」は、実際にそれらの間の通信を保護するための重要な要件の1つです。サーバー。適切な命名規則（RFC 2818、または最近ではRFC 6125）を使用して、彼らが検証できる証明書を使用してください。
証明書がないとhttpsは使用できません。信頼できる証明書を購入するか、テスト用に自己署名証明書を作成する必要があります。 httpsを使用するようにWebサーバーを構成するには、正しいキーファイルを指すようにする必要があります。もちろん、これはiisだけでなくすべてのWebサーバーに適用されます。