7

小規模な Web サイト用の SSL 証明書を購入しようとしています。共通名として「www.domainName.com」または「domainName.com」を入力するのがベスト プラクティスですか?

4

1 に答える 1

8

フィールドを使用していることを確認し、使用するsubjectAltNameホスト名のすべてのバリエーションを含めるか、すべてのバリエーションが何であるかがわからない場合はワイルドカードを含めます。共通名 (CN) は、バックアップとしてのみ使用されます。詳細については、 RFC 2818を参照してください。

###3.1. サーバー ID

一般に、HTTP/TLS リクエストは URI を逆参照することによって生成されます。その結果、サーバーのホスト名がクライアントに認識されます。ホスト名が利用可能な場合、クライアントは、中間者攻撃を防ぐために、サーバーの証明書メッセージに示されているサーバーの ID に対してホスト名をチェックする必要があります。

クライアントがサーバーの予想される ID に関する外部情報を持っている場合、ホスト名のチェックは省略できます。(たとえば、アドレスとホスト名が動的であるが、サーバーが提示する証明書をクライアントが知っているマシンにクライアントが接続している場合があります。)中間者攻撃を防ぐために。特殊なケースでは、クライアントがサーバーの ID を単純に無視することが適切な場合がありますが、これにより接続がアクティブな攻撃に対して無防備になることを理解する必要があります。

タイプ dNSName の subjectAltName 拡張が存在する場合、それを ID として使用する必要があります。それ以外の場合は、証明書の Subject フィールドの (最も具体的な) Common Name フィールドを使用する必要があります。Common Name の使用は既存の慣行ですが、推奨されておらず、証明機関は代わりに dNSName を使用することをお勧めします。

マッチングは、[RFC2459] で指定されたマッチング ルールを使用して実行されます。特定のタイプの ID が証明書に複数存在する場合 (たとえば、複数の dNSName 名の場合、セットのいずれかでの一致は受け入れられると見なされます)。ドメイン名コンポーネントまたはコンポーネント フラグメント。例: に*.a.com一致しますが、 には一致foo.a.comしませんbar.foo.a.com。f*.com一致しますが、一致foo.comしませんbar.com。

場合によっては、URI がホスト名ではなく IP アドレスとして指定されます。この場合、iPAddress subjectAltName が証明書に存在し、URI の IP と正確に一致する必要があります。

ホスト名が証明書の ID と一致しない場合、ユーザー指向のクライアントは、ユーザーに通知するか (クライアントは、いずれの場合でも接続を続行する機会をユーザーに与えることができます)、または不正な証明書エラーで接続を終了する必要があります。自動化されたクライアントは、適切な監査ログ (利用可能な場合) にエラーを記録する必要があり、(不正な証明書エラーで) 接続を終了する必要があります。自動化されたクライアントは、このチェックを無効にする構成設定を提供する場合がありますが、有効にする設定を提供する必要があります。

多くの場合、URI 自体が信頼できないソースからのものであることに注意してください。上記のチェックは、このソースが侵害された攻撃に対する保護を提供しません。たとえば、HTTP/TLS を使用せずに取得した HTML ページをクリックして URI を取得した場合、中間者が URI を置き換えた可能性があります。この形式の攻撃を防ぐために、ユーザーはサーバーから提示された証明書を注意深く調べて、期待どおりかどうかを判断する必要があります。

于 2013-03-29T21:38:09.103 に答える