SSL 証明書サーバー名解決のデコード
SSL 証明書解決を理解することは、安全な通信を確立するために重要です。質問を検討し、包括的な回答を提供しましょう。
SSL 証明書のサーバー名解決
RFC 2818 および RFC 6125 は、SSL 証明書のホスト名検証を定義しています。 「dNSName」サブジェクト代替名 (SAN) がない場合は、共通名 (CN) フィールドが使用されます。ただし、CN の使用は非推奨であり、SAN が優先されます。
ブラウザの動作と Java のメカニズム
多くの場合、ブラウザは CN ベースのサーバー名を異なる方法で処理し、次のような場合でも接続を許可します。 CN がドメインと一致しません。一方、Java は RFC に厳密に従っており、SAN または一致する CN のみを受け入れます。
Keytool を使用した代替名の追加
Java の keytool には「-」が含まれるようになりました。 ext」オプションを使用して、SAN を証明書に追加します。 「-ext san=dns:www.example.com」または「-ext san=ip:10.0.0.1」を使用して、必要な代替名を含めます。
代替としての OpenSSL
keytool を使用したくない場合は、この目的に OpenSSL を使用できます。 openssl.cnf を変更するか、環境変数「OPENSSL_CONF」を設定することにより、証明書で SAN を要求するように OpenSSL を構成できます。
OpenSSL の構成例
openssl 内。 cnf の場合、「[req]」と「[v3_req]」の下に以下を追加しますセクション:
[req] req_extensions = v3_req [ v3_req ] subjectAltName=IP:10.0.0.1 # or subjectAltName=DNS:www.example.com
別の環境変数のトリック
あるいは、環境変数を設定して SAN を指定することもできます。詳細については、http://www.crsr.net/Notes/SSL.html を参照してください。
以上がSSL 証明書サーバーの名前解決はどのように機能しますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。