Certificate Manager は、環境内のドメイン名ごとに、割り当てる証明書とその提供方法をきめ細かく制御できる柔軟なマッピング メカニズムを使用します。
次の図は、ロードバランサの転送ルールで指定された一般的なターゲット プロキシの Certificate Manager コンポーネント間の関係を示しています。
Certificate Manager のコンポーネントの詳細については、コア コンポーネントをご覧ください。
証明書の選択ロジック
大まかに言うと、ロードバランサは次のように証明書を選択します。
クライアントが handshake を開始します。これは、ロードバランサの背後にあるサービスへの接続リクエストです。
handshake 中に、クライアントは handshake の完了に使用する暗号アルゴリズムのリストと、必要に応じてアクセスしようとしているホスト名をロードバランサに提供します。このホスト名は、Server Name Indication(SNI)とも呼ばれます。
ロードバランサはリクエストを受信すると、証明書を選択してセキュアな handshake を完了します。
ホスト名が完全に一致する: クライアントが指定したホスト名が、プロビジョニングされた証明書マップのホスト名エントリと完全に一致する場合、ロードバランサは対応する証明書を選択します。
ワイルドカードを含むホスト名が一致する: クライアントのホスト名がプロビジョニングされた証明書マップのホスト名エントリのいずれとも一致しないが、証明書マップ エントリのワイルドカードを含むホスト名と一致する場合、ロードバランサは対応する証明書を選択します。
たとえば、
*.myorg.example.com
として構成されるワイルドカード エントリは、myorg.example.com
ドメインの第 1 レベルのサブドメインを対象とします。ホスト名が完全に一致しない、またはワイルドカードを含むホスト名が一致しない: クライアントのホスト名がプロビジョニングされた証明書マップのホスト名エントリのいずれとも一致しない場合、ロードバランサはプライマリ証明書マップ エントリを選択します。
ハンドシェイクの失敗: クライアントがホスト名を指定しなかった場合、またはプライマリ証明書マップ エントリが構成されていない場合、ハンドシェイクは失敗します。
証明書の優先度
ロードバランサは、証明書を選択するときに、次の要素に基づいて優先順位を付けます。
- 証明書の種類。クライアントが ECDSA 証明書をサポートしている場合、ロードバランサはこれらの証明書を RSA 証明書よりも優先します。クライアントが ECDSA 証明書をサポートしていない場合、ロードバランサは代わりに RSA 証明書を提供します。
- 証明書のサイズ。証明書が小さいほど使用する帯域幅が少なくなるため、ロードバランサはサイズの大きい証明書よりもサイズの小さい証明書を優先します。
ワイルドカード ドメイン名
ワイルドカード ドメイン名には以下のルールが適用されます。
- ワイルドカード ドメイン名をサポートするのは、DNS 認証を使用した Google マネージド証明書と、CA Service を使用した Google マネージド証明書のみです。ロードバランサ認証を使用した Google マネージド証明書は、ワイルドカード ドメイン名をサポートしていません。
- 両方がエントリで定義されている場合、完全一致がワイルドカードよりも優先されます。たとえば、
www.myorg.example.com
と*.myorg.example.com
に対して証明書マップ エントリを構成した場合、www.myorg.example.com
に対する接続リクエストでは、*.myorg.example.com
も存在している場合でも、常にwww.myorg.example.com
に対するエントリが選択されます。 - ワイルドカード ドメイン名は、第 1 レベルのサブドメインにのみ一致します。たとえば、
host1.myorg.example.com
に対する接続リクエストでは、*.myorg.example.com
に対する証明書マップエントリが選択されますが、host1.hosts.myorg.example.com
に対する証明書マップエントリは選択されません。
証明書の更新
Google マネージド証明書は自動的に更新されます。セルフマネージド証明書は手動で更新する必要があります。必要に応じて、証明書の有効期限が切れる前に Cloud Logging アラートを構成できます。詳細については、ログアラートを構成するをご覧ください。