プライベート CA を使用して相互 TLS を設定する

このページでは、Certificate Authority Service を使用して証明書を Certificate Manager TrustConfig リソースにアップロードし、プライベート認証局（CA）を作成する手順について説明します。

また、アプリケーション ロードバランサの相互 TLS の構成に必要なネットワーク セキュリティ リソースも作成します。

始める前に

  • 相互 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 を作成するには、次の操作を行います。

  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 の説明を取得して root.cert ファイルを作成するには、gcloud privateca roots describe コマンドを使用します。

    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 または名前。

  4. 証明書を 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}"

次のステップ