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

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

始める前に

Namespace 内の証明書にアクセスするために必要な権限を取得するには、組織の IAM 管理者に Web TLS 証明書管理者（web-tls-cert-admin）ロールの付与を依頼してください。

証明書の再発行を行う際は、次のアカウント要件を考慮してください。

  • インフラストラクチャ オペレーター（IO）アカウントを使用して、システム Namespace の証明書にアクセスします。IO にこのタスクの実行を依頼してください。
  • プラットフォーム管理者アカウントを使用して、他の Namespace の証明書にアクセスします。

証明書を再発行する

アノテーションを更新して、証明書を手動で再発行できます。デフォルトの証明書発行者が変更された場合、証明書がまもなく期限切れになる場合を除き、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"
}

独自の証明書の手動ローテーション

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

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

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

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

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

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

  • reason の値は、前の値よりも lastTransitionTime の値が小さい Issued です。

    {
 "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 errorCode: PLATAUTH2001 については、PLATAUTH-R2001 を参照してください。

  • BYO 証明書の errorCode: PLATAUTH2002 については、PLATAUTH-R2002 をご覧ください。