プライベート CA を使用してフロントエンド mTLS を設定する

有効なクライアント証明書には、トラストストア内のトラスト アンカーに至る信頼チェーンが含まれている必要があります。このページでは、管理しているプライベート CA（認証局）のルート証明書を使用して、独自の信頼チェーンを作成する手順について説明します。この設定では、Certificate Authority Service を使用してプライベート CA が作成されます。

このドキュメントでは、プライベート CA のルート証明書を取得した後、Certificate Manager TrustConfig リソースのトラストストアに証明書をアップロードするプロセスについて説明します。次に、信頼構成をクライアント認証（ServerTLSPolicy）リソースにリンクし、クライアント認証リソースをロードバランサのターゲット HTTPS プロキシ リソースに接続します。

始める前に

  • 相互 TLS の概要を確認します。
  • 信頼構成を管理するのガイドを確認します。

  • Google Cloud CLI をインストールします。ツールの完全な概要については、gcloud CLI の概要をご覧ください。ロード バランシングに関連するコマンドについては、API と gcloud CLI のリファレンスをご覧ください。

    gcloud CLI を初めて実行する場合は、最初に gcloud init を実行して認証します。

  • CA プールを作成するガイドを確認します。

  • グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサを使用している場合は、次のサポート対象のバックエンドのいずれかでロードバランサが設定されていることを確認してください。

    • VM インスタンス グループのバックエンド
    • Cloud Storage バケット（バックエンド バケットに加えて、ロードバランサに接続されているバックエンド サービスが 1 つ以上ある場合にのみサポートされます）
    • Cloud Run、App Engine、または Cloud Run functions
    • ハイブリッド接続

  • リージョン外部アプリケーション ロードバランサ、クロスリージョン内部アプリケーション ロードバランサ、またはリージョン内部アプリケーション ロードバランサを使用している場合は、次のいずれかのサポート対象のバックエンドを使用してロードバランサが設定されていることを確認します。

    • VM インスタンス グループのバックエンド
    • Cloud Run
    • ハイブリッド接続

権限

このガイドで必要になる権限を取得するには、プロジェクトに対する次の IAM ロールを付与するよう管理者に依頼してください。

  • TargetHTTPProxy などのロードバランサ リソースの作成: Compute ロードバランサ管理者（roles/compute.loadBalancerAdmin）
  • Certificate Manager リソースの使用: Certificate Manager オーナー（roles/certificatemanager.owner）
  • セキュリティとネットワーキングのコンポーネントの作成: Compute ネットワーク管理者（roles/compute.networkAdmin）と Compute セキュリティ管理者（roles/compute.securityAdmin）
  • プロジェクトの作成（任意）: プロジェクト作成者（roles/resourcemanager.projectCreator）

ロールの付与については、プロジェクト、フォルダ、組織に対するアクセス権の管理をご覧ください。

必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。

ルート CA の証明書を取得する

ルート CA には自己署名証明書があり、トラストストアに追加する必要があります。ルート CA の証明書は、証明書チェーンの最上位にあります。

ルート CA の証明書を取得するには、まず CA プールを作成する必要があります。このプールは作成時には空です。次に、ルート CA を作成して CA プールに追加する必要があります。ルート CA と CA プールは、次の手順で説明するように Certificate Authority Service を使用して作成されます。

  1. CA プールを作成するには、gcloud privateca pools create コマンドを使用します。

    gcloud privateca pools create CA_POOL \
   --location=us-central1

    CA_POOL は、親 CA プールの ID または名前に置き換えます。

  2. ルート CA を作成して CA プールに追加するには、gcloud privateca roots create コマンドを使用します。

    gcloud privateca roots create CA_ROOT \
   --pool=CA_POOL \
   --subject="CN=my-ca, O=Test LLC" \
   --location=us-central1

    次のように置き換えます。

    • CA_ROOT: ルート CA の ID または名前。
    • CA_POOL: 親 CA プールの ID または名前。

  3. ルート CA を識別する PEM でエンコードされた証明書を抽出します。

    gcloud privateca roots describe CA_ROOT \
   --pool=CA_POOL \
   --location=us-central1 \
   --format='value(pemCaCertificates)' > root.cert

    次のように置き換えます。

    • CA_ROOT: プライベート CA の ID または名前。
    • CA_POOL: 親 CA プールの ID または名前。

    ルート証明書（root.cert）をトラストストアにアップロードする必要があります。この手順は次のセクションで実施します。

Certificate Authority Service を使用して CA プールとルート CA を作成する方法については、以下をご覧ください。

ルート CA 証明書をフォーマットする

ルート証明書をトラストストアに含めるには、証明書を 1 行にまとめて環境変数に格納し、信頼構成 YAML ファイルで参照できるようにします。

export ROOT=$(cat root.cert | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')

信頼構成リソースを作成する

信頼構成は、Certificate Manager の公開鍵基盤（PKI）構成を表すリソースです。

信頼構成リソースを作成するには、次の手順を行います。

コンソール

  1. Google Cloud コンソールで、[Certificate Manager] ページに移動します。

    [Certificate Manager] に移動

  2. [信頼構成] タブで、[信頼構成を追加] をクリックします。

  3. 構成の名前を入力します。

  4. [ロケーション] で、[グローバル] または [リージョン] を選択します。

    ロケーションは、信頼構成リソースが保存される場所を示します。グローバル外部アプリケーション ロードバランサ、従来のアプリケーション ロードバランサ、クロスリージョン内部アプリケーション ロードバランサの場合は、グローバル信頼構成リソースを作成します。リージョン外部アプリケーション ロードバランサとリージョン内部アプリケーション ロードバランサの場合は、リージョン信頼構成リソースを作成します。

    [リージョン] を選択した場合は、リージョンを選択します。

  5. [トラストストア] セクションで、[トラスト アンカーを追加] をクリックし、PEM エンコードの証明書ファイルをアップロードするか、証明書の内容をコピーします。

  6. [追加] をクリックします。

  7. [作成] をクリックします。

新しい信頼構成リソースが構成のリストに表示されていることを確認します。

gcloud

  1. 信頼構成パラメータを指定する信頼構成 YAML ファイル（trust_config.yaml）を作成します。この例では、信頼構成リソースは、ルート証明書を表す単一のトラスト アンカーを含むトラストストアです。このルート証明書は、プライベート CA を使用して生成されます。

    cat << EOF > trust_config.yaml
name: TRUST_CONFIG_NAME
trustStores:
- trustAnchors:
    - pemCertificate: "${ROOT?}"
EOF

  2. 信頼構成 YAML ファイルをインポートするには、gcloud certificate-manager trust-configs import コマンドを使用します。

    グローバル

    グローバル外部アプリケーション ロードバランサ、従来のアプリケーション ロードバランサ、クロスリージョン内部アプリケーション ロードバランサの場合は、信頼構成リソースの保存場所として global を指定します。

    gcloud certificate-manager trust-configs import TRUST_CONFIG_NAME  \
    --source=trust_config.yaml \
    --location=global

    次のように置き換えます。

    • TRUST_CONFIG_NAME: 信頼構成リソースの名前。

    リージョン

    リージョン外部アプリケーション ロードバランサとリージョン内部アプリケーション ロードバランサの場合は、信頼構成リソースの保存場所としてリージョンを指定します。

    gcloud certificate-manager trust-configs import TRUST_CONFIG_NAME  \
    --source=trust_config.yaml \
    --location=LOCATION

    次のように置き換えます。

    • TRUST_CONFIG_NAME: 信頼構成リソースの名前。
    • LOCATION: 信頼構成リソースが保存されるリージョン。デフォルトの場所は global です。

クライアント認証リソースを作成する

クライアント認証（ServerTLSPolicy とも呼ばれます）リソースを使用すると、クライアント証明書の検証で使用するサーバーサイド TLS モードと信頼構成リソースを指定できます。クライアントがロードバランサに無効な証明書を提示するか、証明書を提示しない場合は、clientValidationMode でクライアント接続の処理方法を指定します。詳細については、mTLS クライアント検証モードをご覧ください。

  • clientValidationMode が ALLOW_INVALID_OR_MISSING_CLIENT_CERT に設定されている場合、検証が失敗した場合やクライアント証明書が欠落していても、すべてのリクエストがバックエンドに渡されます。
  • clientValidationMode が REJECT_INVALID に設定されている場合、TrustConfig リソースの検証が可能なクライアント証明書を提示するリクエストのみがバックエンドに渡されます。

クライアント認証（ServerTlsPolicy）リソースを作成するには、次の操作を行います。

コンソール

  1. Google Cloud コンソールで、[認証構成] ページに移動します。

    [認証構成] に移動

  2. [クライアント認証] タブで [作成] をクリックします。

  3. クライアント認証リソースの名前を入力します。

  4. [ロケーション] で、[グローバル] または [リージョン] を選択します。

    グローバル外部アプリケーション ロードバランサ、従来のアプリケーション ロードバランサ、クロスリージョン内部アプリケーション ロードバランサの場合は、ロケーションをグローバルに設定します。リージョン外部アプリケーション ロードバランサとリージョン内部アプリケーション ロードバランサの場合は、ロケーションをロードバランサが構成されているリージョンに設定します。

  5. [クライアント認証モード] で [ロード バランシング] を選択します。

  6. クライアント検証モードを選択します。

  7. 前に作成した信頼構成リソースを選択します。

  8. [作成] をクリックします。

クライアント認証（ServerTlsPolicy）が表示されていることを確認します。

gcloud

  1. 接続の処理方法に応じて、次のいずれかのオプションを選択し、クライアント認証（ServerTlsPolicy）リソースを YAML 形式で定義します。

    • オプション 1: clientValidationMode が ALLOW_INVALID_OR_MISSING_CLIENT_CERT に設定されている。

      グローバル

      グローバル外部アプリケーション ロードバランサ、従来のアプリケーション ロードバランサ、クロスリージョン内部アプリケーション ロードバランサの場合は、クライアント検証モードとグローバル信頼構成リソースを宣言的に指定する YAML ファイルを作成します。

      cat << EOF > server_tls_policy.yaml
name: SERVER_TLS_POLICY_NAME
mtlsPolicy:
    clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT
    clientValidationTrustConfig: projects/PROJECT_ID/locations/global/trustConfigs/TRUST_CONFIG_NAME
EOF

      リージョン

      リージョン外部アプリケーション ロードバランサとリージョン内部アプリケーション ロードバランサの場合は、クライアント検証モードとリージョン信頼構成リソースを宣言的に指定する YAML ファイルを作成します。

      cat << EOF > server_tls_policy.yaml
name: SERVER_TLS_POLICY_NAME
mtlsPolicy:
    clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT
    clientValidationTrustConfig: projects/PROJECT_ID/locations/REGION/trustConfigs/TRUST_CONFIG_NAME
EOF

    • オプション 2: clientValidationMode が REJECT_INVALID に設定されている。

      グローバル

      グローバル外部アプリケーション ロードバランサ、従来のアプリケーション ロードバランサ、クロスリージョン内部アプリケーション ロードバランサの場合は、クライアント検証モードとグローバル信頼構成リソースを宣言的に指定する YAML ファイルを作成します。

      cat << EOF > server_tls_policy.yaml
name: SERVER_TLS_POLICY_NAME
mtlsPolicy:
    clientValidationMode: REJECT_INVALID
    clientValidationTrustConfig: projects/PROJECT_ID/locations/global/trustConfigs/TRUST_CONFIG_NAME
EOF

      リージョン

      リージョン外部アプリケーション ロードバランサとリージョン内部アプリケーション ロードバランサの場合は、クライアント検証モードとリージョン信頼構成リソースを宣言的に指定する YAML ファイルを作成します。

      cat << EOF > server_tls_policy.yaml
name: SERVER_TLS_POLICY_NAME
mtlsPolicy:
      clientValidationMode: REJECT_INVALID
      clientValidationTrustConfig: projects/PROJECT_ID/locations/REGION/trustConfigs/TRUST_CONFIG_NAME
EOF

      次のように置き換えます。

      SERVER_TLS_POLICY_NAME: クライアント認証（ServerTlsPolicy）リソースの名前。

      PROJECT_ID: Google Cloud プロジェクトの ID。

      LOCATION: グローバル外部アプリケーション ロードバランサ、従来のアプリケーション ロードバランサ、クロスリージョン内部アプリケーション ロードバランサの場合は、global を使用します。リージョン外部アプリケーション ロードバランサまたはリージョン内部アプリケーション ロードバランサには、ロードバランサを構成したリージョンを使用します。

      TRUST_CONFIG_NAME: 前に作成した信頼構成リソースの名前。

  2. クライアント認証 ServerTlsPolicy リソースをインポートするには、gcloud network-security server-tls-policies import コマンドを使用します。

    グローバル

    グローバル外部アプリケーション ロードバランサ、従来のアプリケーション ロードバランサ、クロスリージョン内部アプリケーション ロードバランサの場合は、--location フラグを global に設定します。

    gcloud network-security server-tls-policies import SERVER_TLS_POLICY_NAME \
  --source=server_tls_policy.yaml \
  --location=global

    次のように置き換えます。

    SERVER_TLS_POLICY_NAME: クライアント認証（ServerTlsPolicy）リソースの名前。

    リージョン

    リージョン外部アプリケーション ロードバランサとリージョン内部アプリケーション ロードバランサの場合は、--location フラグをロードバランサが構成されているリージョンに設定します。

    gcloud network-security server-tls-policies import SERVER_TLS_POLICY_NAME \
  --source=server_tls_policy.yaml \
  --location=LOCATION

    次のように置き換えます。

    SERVER_TLS_POLICY_NAME: クライアント認証（ServerTlsPolicy）リソースの名前。

  3. 省略可: すべてのクライアント認証（ServerTlsPolicies）リソースを一覧取得するには、gcloud network-security server-tls-policies list コマンドを使用します。

    gcloud network-security server-tls-policies list \
  --location=LOCATION

    次のように置き換えます。

    LOCATION: グローバル外部アプリケーション ロードバランサ、従来のアプリケーション ロードバランサ、クロスリージョン内部アプリケーション ロードバランサの場合は、global を使用します。リージョン外部アプリケーション ロードバランサまたはリージョン内部アプリケーション ロードバランサには、ロードバランサを構成したリージョンを使用します。

クライアント認証リソースをロードバランサに接続する

相互 TLS 認証を機能させるには、ロードバランサを設定した後、クライアント認証（ServerTLSPolicy）リソースをロードバランサのターゲット HTTPS プロキシ リソースに接続する必要があります。

コンソール

  1. Google Cloud コンソールで、[ロード バランシング] ページに移動します。

    [ロード バランシング] に移動

  2. ロードバランサのリストから、クライアント認証（ServerTLSPolicy）リソースを接続するロードバランサを選択します。

  3. [編集] をクリックします。

  4. HTTPS フロントエンドの [フロントエンドの構成] セクションで、[高度な機能の表示] セクションを開きます。

  5. [クライアント認証] リストから、クライアント認証リソースを選択します。

  6. [完了] をクリックします。

  7. [更新] をクリックします。

gcloud

  1. プロジェクト内のすべてのターゲット HTTPS プロキシ リソースを一覧取得するには、gcloud compute target-https-proxies list コマンドを使用します。

    gcloud compute target-https-proxies list

    ServerTLSPolicy リソースを接続するターゲット HTTPS プロキシの名前をメモします。以降のステップでは、この名前を TARGET_HTTPS_PROXY_NAME として表しています。

  2. ターゲット HTTPS プロキシの構成をファイルにエクスポートするには、gcloud compute target-https-proxies export コマンドを使用します。

    グローバル

      gcloud compute target-https-proxies export TARGET_HTTPS_PROXY_NAME \
      --destination=TARGET_PROXY_FILENAME \
      --global

    次のように置き換えます。

    • TARGET_HTTPS_PROXY_NAME: ターゲット プロキシの名前。
    • TARGET_PROXY_FILENAME: ターゲット プロキシの構成ファイルの名前（YAML 形式）。例: mtls_target_proxy.yaml

    リージョン

    gcloud compute target-https-proxies export TARGET_HTTPS_PROXY_NAME \
    --destination=TARGET_PROXY_FILENAME \
    --region=REGION

    次のように置き換えます。

    • TARGET_HTTPS_PROXY_NAME: ターゲット プロキシの名前。
    • TARGET_PROXY_FILENAME: ターゲット プロキシの構成ファイルの名前（YAML 形式）。例: mtls_target_proxy.yaml
    • REGION: ロードバランサを構成したリージョン。

  3. すべてのクライアント認証（ServerTlsPolicy）リソースを一覧取得するには、gcloud network-security server-tls-policies list コマンドを使用します。

    gcloud network-security server-tls-policies list \
    --location=LOCATION

    次のように置き換えます。

    LOCATION: クロスリージョン内部アプリケーション ロードバランサ、グローバル外部アプリケーション ロードバランサ、または従来のアプリケーション ロードバランサの場合は、global を使用します。リージョン外部アプリケーション ロードバランサまたはリージョン内部アプリケーション ロードバランサには、ロードバランサを構成したリージョンを使用します。

    mTLS を構成するクライアント認証（ServerTLSPolicy）リソースの名前をメモします。次のステップでは、この名前を SERVER_TLS_POLICY_NAME と表しています。

  4. クライアント認証（ServerTlsPolicy）をターゲット HTTPS プロキシに追加します。

    echo "serverTlsPolicy: //networksecurity.googleapis.com/projects/PROJECT_ID/locations/LOCATION/serverTlsPolicies/SERVER_TLS_POLICY_NAME" >> TARGET_PROXY_FILENAME

    次のように置き換えます。

    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
    • LOCATION: グローバル外部アプリケーション ロードバランサ、従来のアプリケーション ロードバランサ、クロスリージョン内部アプリケーション ロードバランサの場合は、global を使用します。リージョン外部アプリケーション ロードバランサまたはリージョン内部アプリケーション ロードバランサには、ロードバランサを構成したリージョンを使用します。
    • SERVER_TLS_POLICY_NAME: クライアント認証（ServerTLSPolicy）リソースの名前。
    • TARGET_PROXY_FILENAME: ターゲット プロキシの構成ファイルの名前（YAML 形式）。

  5. ターゲット HTTPS プロキシの構成をファイルからインポートするには、gcloud compute target-https-proxies import コマンドを使用します。

    グローバル

      gcloud compute target-https-proxies import TARGET_HTTPS_PROXY_NAME \
      --source=TARGET_PROXY_FILENAME \
      --global

    次のように置き換えます。

    • TARGET_HTTPS_PROXY_NAME: ターゲット プロキシの名前。
    • TARGET_PROXY_FILENAME: ターゲット プロキシの構成ファイルの名前（YAML 形式）。例: mtls_target_proxy.yaml

    リージョン

      gcloud compute target-https-proxies import TARGET_HTTPS_PROXY_NAME \
      --source=TARGET_PROXY_FILENAME \
      --region=REGION

    次のように置き換えます。

    • TARGET_HTTPS_PROXY_NAME: ターゲット プロキシの名前。
    • TARGET_PROXY_FILENAME: ターゲット プロキシの構成ファイルの名前（YAML 形式）。例: mtls_target_proxy.yaml
    • REGION: ロードバランサを構成したリージョン。

mTLS カスタム ヘッダーを追加する

mTLS を有効にすると、カスタム ヘッダーを使用して mTLS 接続に関する情報を渡すことができます。また、ロギングを有効にして、mTLS 接続エラーをログにキャプチャすることもできます。

バックエンド サービスに mTLS カスタム ヘッダーを追加する

グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサの場合、カスタム ヘッダーを使用して mTLS 接続に関する情報をバックエンド サービスに渡すことができます。

  1. プロジェクト内のすべてのバックエンド サービスを一覧取得するには、gcloud compute backend-services list コマンドを使用します。

    gcloud compute backend-services list

    カスタム ヘッダーとロギングを有効にするため、バックエンド サービスの名前をメモします。この名前は、次のステップで BACKEND_SERVICE として参照されます。

  2. バックエンド サービスを更新するには、gcloud compute backend-services update コマンドを使用します。

    gcloud compute backend-services update BACKEND_SERVICE \
  --global \
  --enable-logging \
  --logging-sample-rate=1 \
  --custom-request-header='X-Client-Cert-Present:{client_cert_present}' \
  --custom-request-header='X-Client-Cert-Chain-Verified:{client_cert_chain_verified}' \
  --custom-request-header='X-Client-Cert-Error:{client_cert_error}' \
  --custom-request-header='X-Client-Cert-Hash:{client_cert_sha256_fingerprint}' \
  --custom-request-header='X-Client-Cert-Serial-Number:{client_cert_serial_number}' \
  --custom-request-header='X-Client-Cert-SPIFFE:{client_cert_spiffe_id}' \
  --custom-request-header='X-Client-Cert-URI-SANs:{client_cert_uri_sans}' \
  --custom-request-header='X-Client-Cert-DNSName-SANs:{client_cert_dnsname_sans}' \
  --custom-request-header='X-Client-Cert-Valid-Not-Before:{client_cert_valid_not_before}' \
  --custom-request-header='X-Client-Cert-Valid-Not-After:{client_cert_valid_not_after}'

mTLS カスタム ヘッダーを URL マップに追加する

クロスリージョン内部アプリケーション ロードバランサ、リージョン外部アプリケーション ロードバランサ、リージョン内部アプリケーション ロードバランサの場合は、カスタム ヘッダーを使用して mTLS 接続に関する情報を URL マップに渡すことができます。

プロジェクト内のすべての URL マップを一覧取得するには、gcloud compute url-maps list コマンドを使用します。

   gcloud compute url-maps list

カスタム ヘッダーとロギングを有効にするために、URL マップの名前をメモします。次のステップでは、この名前を URL_MAP_NAME と表しています。

グローバル

クロスリージョン内部アプリケーション ロードバランサの URL マップを編集するには、gcloud compute url-maps edit コマンドを使用します。

   gcloud compute url-maps edit URL_MAP_NAME --global

以下に、カスタム リクエスト ヘッダー（requestHeadersToAdd）で変数を使用する方法を示す YAML ファイルの例を示します。同じ変数を使用して、カスタム レスポンス ヘッダー（responseHeadersToAdd）を送信できます。

   headerAction:
      requestHeadersToAdd:
      - headerName: "X-Client-Cert-Present"
        headerValue: "{client_cert_present}"
      - headerName: "X-Client-Cert-Chain-Verified"
        headerValue: "{client_cert_chain_verified}"
      - headerName: "X-Client-Cert-Error"
        headerValue: "{client_cert_error}"
      - headerName: "X-Client-Cert-Hash"
        headerValue: "{client_cert_sha256_fingerprint}"
      - headerName: "X-Client-Cert-Serial-Number"
        headerValue: "{client_cert_serial_number}"
      - headerName: "X-Client-Cert-SPIFFE"
        headerValue: "{client_cert_spiffe_id}"
      - headerName: "X-Client-Cert-URI-SANs"
        headerValue: "{client_cert_uri_sans}"
      - headerName: "X-Client-Cert-DNSName-SANs"
        headerValue: "{client_cert_dnsname_sans}"
      - headerName: "X-Client-Cert-Valid-Not-Before"
        headerValue: "{client_cert_valid_not_before}"
      - headerName: "X-Client-Cert-Valid-Not-After"
        headerValue: "{client_cert_valid_not_after}"
      - headerName: "X-Client-Cert-Issuer-Dn"
        headerValue: "{client_cert_issuer_dn}"
      - headerName: "X-Client-Cert-Subject-Dn"
        headerValue: "{client_cert_subject_dn}"
      - headerName: "X-Client-Cert-Leaf"
        headerValue: "{client_cert_leaf}"
      - headerName: "X-Client-Cert-Chain"
        headerValue: "{client_cert_chain}"

リージョン

リージョン外部アプリケーション ロードバランサまたはリージョン内部アプリケーション ロードバランサの URL マップを編集するには、gcloud compute url-maps edit コマンドを使用します。

   gcloud compute url-maps edit URL_MAP_NAME --region=REGION

以下に、カスタム リクエスト ヘッダー（requestHeadersToAdd）で変数を使用する方法を示す YAML ファイルの例を示します。同じ変数を使用してカスタム レスポンス ヘッダー（responseHeadersToAdd）を送信できます。

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
      name: regional-lb-map
      region: region/REGION
   headerAction:
      requestHeadersToAdd:
      - headerName: "X-Client-Cert-Present"
        headerValue: "{client_cert_present}"
      - headerName: "X-Client-Cert-Chain-Verified"
        headerValue: "{client_cert_chain_verified}"
      - headerName: "X-Client-Cert-Error"
        headerValue: "{client_cert_error}"
      - headerName: "X-Client-Cert-Hash"
        headerValue: "{client_cert_sha256_fingerprint}"
      - headerName: "X-Client-Cert-Serial-Number"
        headerValue: "{client_cert_serial_number}"
      - headerName: "X-Client-Cert-SPIFFE"
        headerValue: "{client_cert_spiffe_id}"
      - headerName: "X-Client-Cert-URI-SANs"
        headerValue: "{client_cert_uri_sans}"
      - headerName: "X-Client-Cert-DNSName-SANs"
        headerValue: "{client_cert_dnsname_sans}"
      - headerName: "X-Client-Cert-Valid-Not-Before"
        headerValue: "{client_cert_valid_not_before}"
      - headerName: "X-Client-Cert-Valid-Not-After"
        headerValue: "{client_cert_valid_not_after}"
      - headerName: "X-Client-Cert-Issuer-Dn"
        headerValue: "{client_cert_issuer_dn}"
      - headerName: "X-Client-Cert-Subject-Dn"
        headerValue: "{client_cert_subject_dn}"
      - headerName: "X-Client-Cert-Leaf"
        headerValue: "{client_cert_leaf}"
      - headerName: "X-Client-Cert-Chain"
        headerValue: "{client_cert_chain}"

CSR を使用してクライアント証明書を取得する

このセクションでは、ルート CA の証明書によって署名されたクライアント（リーフ）証明書を生成するための追加の構成オプションについて説明します。

クライアント証明書を取得するには、証明書署名リクエスト（CSR）を生成し、CA プールに送信します。

  1. OpenSSL 構成ファイルを作成して、クライアント証明書の CSR を生成します。

    次の構成ファイル（client.config）には、CSR に含める X.509 拡張機能を指定する [extension_requirements] セクションが含まれています。クライアント証明書の要件の詳細については、証明書の要件をご覧ください。

    cat > client.config << EOF
[req]
default_bits              = 2048
req_extensions            = extension_requirements
distinguished_name        = dn_requirements
prompt                    = no

[extension_requirements]
basicConstraints          = critical, CA:FALSE
keyUsage                  = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage          = clientAuth

[dn_requirements]
countryName               = US
stateOrProvinceName       = California
localityName              = San Francisco
0.organizationName        = example
organizationalUnitName    = test
commonName                = test.example.com
emailAddress              = test@example.com

EOF

  2. 次の openssl コマンドを実行して、CSR（csr.pem）と対応する秘密鍵（key.pem）を生成します。

    openssl req -newkey rsa:2048 -nodes \
    -config client.config \
    -keyout key.pem \
    -out csr.pem

  3. 次の gcloud privateca certificates create コマンドを実行して CSR を送信し、CA プール内の CA から X.509 クライアント証明書をリクエストします。

    gcloud privateca certificates create \
     --issuer-pool CA_POOL \
     --issuer-location=us-central1 \
     --csr csr.pem \
     --cert-output-file CERT_FILENAME

    次のように置き換えます。

    • CA_POOL: CA プールの ID または名前。
    • CERT_FILENAME: リーフからルートの順に並べられた PEM エンコードされた証明書チェーン ファイル。

  4. クライアントサイドの SSL 証明書を使用して、ロードバランサの IP アドレスに安全な HTTPS リクエストを送信します。クライアントは、認証を受けるために自身の証明書をロードバランサに提示します。

    curl -v --key key.pem --cert CERT_FILENAME https://IP_ADDRESS

    次のように置き換えます。

    • CERT_FILENAME: リーフからルートの順に並べられた PEM エンコードされた証明書チェーン ファイル。
    • IP_ADDRESS: ロードバランサの IP アドレス。

次のステップ