Httpsは証明書がなくても機能しますか？

最近、インフラストラクチャチームが開発チームに、httpsの証明書は必要ないことを伝えました。彼らは、証明書を購入する唯一の利点は、正しいウェブサイトに接続していることを消費者に安心させることであると述べました。

これは、httpsについて想定したすべてに反します。

私はウィキペディアを読みましたが、httpsを構成するには信頼できる証明書または自己署名証明書のいずれかが必要であると述べています。

それは、configureにすることなく、httpsに対応するためにIIS可能である任意の証明書？

いいえ。証明書が必要です。自己署名することもできますが、サーバーとクライアント間でセッション対称鍵を交換してデータを暗号化するには、公開鍵と秘密鍵のペアが必要です。

つまり、システムをどのように展開したいかによって、微妙なケースが存在する可能性があります。

HTTPSはSSL / TLSを介したHTTPであり、証明書なしで、またはX.509以外のタイプの証明書とともに SSL / TLS を使用できます。

• 匿名の暗号スイート：暗号化を提供できますが、認証はありません。セキュリティに関する限り、あまり役に立たない... RFC 4346を引用するには：「匿名のDiffie-Hellmanは、中間者攻撃を防ぐことができないため、強くお勧めしません。」
• 事前共有キー：リモート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に関する外部情報を持っている場合、ホスト名チェックは省略される場合があります。」に該当する可能性があります）。完全にばかげています。そうは言っても、通常のブラウザは一般にTLS Kerberos暗号スイートをサポートしているとは思いません（SPNEGO認証を介してKerberosをサポートできる番号もありますが、それは無関係です）。さらに、これはKerberosの使用が適切な環境でのみ機能します。

「[提供する]消費者が正しいウェブサイトに接続していることを安心させる」は、実際に消費者とサーバー間の通信を保護するための重要な要件の1つです。適切な命名規則（RFC 2818、または最近ではRFC 6125）を使用して、彼らが検証できる証明書を使用してください。

証明書がないとhttpsは使用できません。信頼できる証明書を購入するか、テスト用に自己署名証明書を作成する必要があります。httpsを使用するようにWebサーバーを構成するには、正しいキーファイルを指すようにする必要があります。もちろん、これはiisだけでなくすべてのWebサーバーに適用されます。