A.4. HTTPS 証明書の特別な要件

HTTPS 仕様では、HTTPS クライアントがサーバーの ID を検証できる必要があることが義務付けられています。これにより、X.509 証明書の生成方法に影響を及ぼす可能性があります。サーバー ID を検証するメカニズムは、クライアントのタイプによって異なります。一部のクライアントは、特定の信頼できる CA によって署名されたサーバー証明書のみを受け入れることによってサーバー ID を確認する場合があります。さらに、クライアントはサーバー証明書の内容を検査し、特定の制約を満たす証明書のみを受け入れることができます。

アプリケーション固有のメカニズムがない場合、HTTPS 仕様では、サーバー ID を検証するための HTTPS URL 整合性チェック と呼ばれる一般的なメカニズムが定義されています。これは、Web ブラウザーが使用する標準メカニズムです。

URL 整合性チェックの基本的な概念は、サーバー証明書のアイデンティティーがサーバーのホスト名と一致する必要があることです。この整合性チェックは、HTTPS 用の X.509 証明書の生成方法に重要な影響を及ぼします。証明書 ID(通常は証明書サブジェクト DN の共通名) は、HTTPS サーバーが展開されているホスト名と一致する必要があります。

URL 整合性チェックは、中間者攻撃 を防ぐように設計されています。

HTTPS URL 整合性チェックは RFC 2818 で指定され、http://www.ietf.org/rfc/rfc2818.txt の Internet Engineering Task Force (IETF) により公開されます。

URL 整合性チェックで使用される証明書アイデンティティーは、以下のいずれかの方法で指定できます。

(URL 整合性チェックの目的で) 証明書 ID を指定する通常の方法は、証明書のサブジェクト DN の共通名 (CN) を使用することです。

たとえば、サーバーが以下の URL でセキュアな TLS 接続をサポートする場合:

https://www.redhat.com/secure

対応するサーバー証明書には、以下のサブジェクト DN があります。

C=IE,ST=Co. Dublin,L=Dublin,O=RedHat,
OU=System,CN=www.redhat.com

ここで、CN はホスト名 www.redhat.com に設定されています。

新しい証明書にサブジェクト DN を設定する方法は、「独自の証明書の作成」 を参照してください。

証明書 ID にサブジェクト DN の共通名を使用すると、一度に 1 つの ホスト名しか指定できないという欠点があります。ただし、マルチホームホストに証明書を展開する場合は、任意 のマルチホームホスト名で証明書を使用できるようにすることが実用的である場合があります。この場合、複数の代替 ID を使用して証明書を定義する必要があります。これは、subjectAltName 証明書エクステンションを使用する場合に限り可能です。

たとえば、次のいずれかのホスト名への接続をサポートするマルチホームホストがある場合:

www.redhat.com
www.jboss.org

次に、これらの DNS ホスト名の両方を明示的に一覧表示する subjectAltName を定義できます。openssl ユーティリティーを使用して証明書を生成する場合は、以下のように openssl.cnf 設定ファイルに関連する行を編集し、subjectAltName エクステンションの値を指定します。

subjectAltName=DNS:www.redhat.com,DNS:www.jboss.org

ここで、HTTPS プロトコルは、subjectAltName に一覧表示されている DNS ホスト名のいずれかに対してサーバーホスト名が一致します (subjectAltName は共通名よりも優先されます)。

HTTPS プロトコルは、ホスト名のワイルドカード文字 (\*) もサポートしています。たとえば、以下のように subjectAltName を定義できます。

subjectAltName=DNS:*.jboss.org

この証明書 ID は、ドメイン jboss.org 内の任意の 3 コンポーネントホスト名と一致します。