PKI ウェブ証明書を手動で再発行する

このドキュメントでは、Google Distributed Cloud（GDC）エアギャップ環境のウェブ エンドポイントの証明書の再発行を手動でトリガーする手順について説明します。

このドキュメントは、PKI ウェブ証明書を管理するプラットフォーム管理者グループ内のユーザーを対象としています。詳細については、 GDC エアギャップ環境のドキュメントの対象読者をご覧ください。

始める前に

ウェブ証明書を手動で再発行する前に、必要な権限を取得し、環境を準備する必要があります。

IAM ロールをリクエストする

名前空間で PKI ウェブ証明書を作成、更新、削除するには、組織 IAM 管理者に連絡して Web TLS 証明書管理者 （web-tls-cert-admin）ロールをリクエストしてください。

次のアカウント要件を考慮してください。

  • インフラストラクチャ オペレーター グループのメンバーは、PKI ウェブ 証明書を システム 名前空間で再発行する必要があります。
  • プラットフォーム管理者グループのメンバーは、管理している他のすべての名前空間で PKI ウェブ証明書を再発行できます。

環境を準備する

証明書を再発行する

アノテーションを更新して、証明書を手動で再発行できます。デフォルトの証明書発行者が変更された場合、証明書が期限切れになるまで、Distributed Cloud は以前のデフォルトの証明書発行者によって署名された証明書を自動的に再発行しません。

証明書の再発行を手動でトリガーするには、kubectl CLI を使用して次の操作を行います。

  1. ターゲット Certificate の manual-reissuance アノテーションを requested に設定します。次の例では、現在のデフォルトの証明書発行者を使用する istio-system 名前空間の default-wildcard-cert 証明書を更新します。

    kubectl annotate --overwrite certificate.pki.security.gdc.goog
default-wildcard-cert -n istio-system
pki.security.gdc.goog/manual-reissuance='requested'

  2. 証明書の再発行中に、移行状態として in-progress アノテーション値が表示されることがあります。manual-reissuance アノテーション値が finished と表示されるまで待ちます。

    kubectl -n istio-system get
certificate.pki.security.gdc.goog/default-wildcard-cert -ojson | jq -r '
.metadata.annotations."pki.security.gdc.goog/manual-reissuance"'

    出力は次のようになります。

    finished

  3. 証明書発行者を確認します。証明書仕様に記載されている発行者と一致する必要があります。指定されていない場合は、発行者が現在のデフォルトの発行者と一致する必要があります。

    kubectl -n istio-system get certificate.pki.security.gdc.goog/default-wildcard-cert -ojson | jq -r '
.status.issuedBy'

    出力は次のようになります。

    {
  "name": "byo-cert-issuer",
  "namespace": "pki-system"
}

Bring-your-own 証明書の手動ローテーション

Bring-your-own 証明書（BYO 証明書）の手動ローテーションをトリガーして完了したら、以前に署名された BYO 証明書に対して新しく生成された証明書署名リクエスト（CSR）に署名する必要があります。詳細については、 BYO 証明書に署名するをご覧ください。

ローテーション中に、Distributed Cloud は新しい秘密鍵と公開鍵のペアを作成します。これにより、以前にアップロードされた署名付き証明書は新しい CSR と互換性がなくなります。最初のアップロード以降、証明書仕様が変更されていない場合、以前にアップロードされた証明書は期限切れになるまで使用されます。仕様が変更された場合は、次のいずれかのイベントが発生します。

  • Distributed Cloud は、既存の一致する証明書を使用します。
  • フォールバック認証局（CA）が新しい証明書を発行します。

BYO 証明書の手動ローテーションの例

次の例では、手動ローテーション用にトリガーされた、以前に署名された BYO 証明書が表示されます。

  • byoCertStatus は、証明書の type 値が Ready であることを示します。

  • reason 値は Issued で、以前の値よりも前の lastTransitionTime 値です。

    {
 "byoCertStatus": {
   "csrStatus": {
     "conditions": [
       {
         "lastTransitionTime": "2024-05-03T22:38:43Z",
         "message": "",
         "observedGeneration": 2,
         "reason": "WaitingForSigning",
         "status": "False",
         "type": "Ready"
       }
     ],
     "csr": "LS0tLS1CRUdJTiBDRVJ..."
   },
   "signedCertStatus": {
     "conditions": [
       {
         "lastTransitionTime": "2024-05-03T22:38:43Z",
         "message": "RawSubjectPublickKeyInfo does not match with the CSR",
         "observedGeneration": 2,
         "reason": "Rejected",
         "status": "False",
         "type": "Ready"
       }
     ]
   }
 },
 ```

次の例では、手動ローテーション用にトリガーされた、以前に署名された BYO 証明書の出力が表示されます。

  • signedCertStatus で、ローテーション後に以前に署名された証明書が新しい CSR と一致しなくなったため、reason フィールドに Rejected が表示されます。

  • CSR reason は WaitingForSigning を示します。

    "conditions": [
  {
    "lastTransitionTime": "2024-05-03T08:42:10Z",
    "message": "Certificate is issued",
    "observedGeneration": 2,
    "reason": "Issued",
    "status": "True",
    "type": "Ready"
  }
],
"errorStatus": {
  "errors": [
    {
      "code": "PLATAUTH2002",
      "message": "Waiting for CSR signing"
    }
  ],
  "lastUpdateTime": "2024-05-03T22:38:43Z"
},
"issuedBy": {
  "name": "byo-cert-issuer",
  "namespace": "pki-system"
}
}

    証明書署名アラートを管理する

最初の発行、ローテーション、有効期限の証明書署名アラートは、PKI ランブックの次のセクションに記載されているトラブルシューティング手順を使用して、IO が対応する必要があります。

  • subCA エラーコード PLATAUTH2001 の場合は、PLATAUTH-R2001 をご覧ください。

  • BYO 証明書のエラーコード PLATAUTH2002 の場合は、PLATAUTH-R2002 をご覧ください。