PKI-Webzertifikate manuell neu ausstellen

Auf dieser Seite finden Sie eine Anleitung zum manuellen Auslösen der Neuausstellung von Zertifikaten für Ihre Air-Gap-Webendpunkte von Google Distributed Cloud (GDC).

Hinweise

Bitten Sie Ihren IAM-Administrator der Organisation, Ihnen die Rolle „Web TLS Certificate Admin“ (web-tls-cert-admin) zuzuweisen, um die Berechtigungen zu erhalten, die Sie für den Zugriff auf Zertifikate in einem Namespace benötigen.

Beachten Sie bei der Neuausstellung von Zertifikaten die folgenden Kontoanforderungen:

  • Verwenden Sie ein Infrastructure Operator-Konto (IO), um auf das Zertifikat im System-Namespace zuzugreifen. Bitte deinen IO, diese Aufgabe auszuführen.
  • Verwenden Sie ein Plattformadministratorkonto, um auf Zertifikate in anderen Namespaces zuzugreifen.

Zertifikat neu ausstellen

Sie können ein Zertifikat mit einer Anmerkungsaktualisierung manuell neu ausstellen. Wenn sich der Standardaussteller von Zertifikaten ändert, werden von Distributed Cloud nicht automatisch Zertifikate neu ausgestellt, die vom vorherigen Standardaussteller von Zertifikaten signiert wurden, es sei denn, das Zertifikat läuft bald ab.

Wenn Sie die Neuausstellung eines Zertifikats manuell auslösen möchten, führen Sie die folgenden Schritte mit der kubectl CLI aus:

  1. Legen Sie die Anmerkung manual-reissuance für das Ziel Certificate auf requested fest. Im folgenden Beispiel wird das default-wildcard-cert-Zertifikat im Namespace istio-system aktualisiert, für das der aktuelle Standardzertifikataussteller verwendet wird:

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

  2. Möglicherweise sehen Sie den in-progress-Hinweiswert als Übergangszustand, während das Zertifikat neu ausgestellt wird. Warten Sie, bis für den Annotationswert manual-reissuance der Wert finished angezeigt wird:

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

    Die Ausgabe sieht dann ungefähr so aus:

    finished

  3. Prüfen Sie den Zertifikataussteller. Er muss entweder mit dem in der Zertifikatspezifikation angegebenen Aussteller übereinstimmen oder, falls nicht angegeben, mit dem aktuellen Standardaussteller:

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

    Die Ausgabe sieht dann ungefähr so aus:

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

Manuelle Rotation von eigenen Zertifikaten

Wenn Sie eine manuelle BYO-Zertifikatsrotation (Bring Your Own Certificate) auslösen und abschließen, müssen Sie die neu generierte Zertifikatsignierungsanfrage (Certificate Signing Request, CSR) für ein zuvor signiertes BYO-Zertifikat signieren. Weitere Informationen finden Sie unter BYO-Zertifikat signieren.

Während der Rotation erstellt Distributed Cloud ein neues privates und öffentliches Schlüsselpaar. Das zuvor hochgeladene signierte Zertifikat ist daher nicht mit dem neuen CSR kompatibel. Wenn sich die Zertifikatspezifikation seit dem ersten Upload nicht geändert hat, wird das zuvor hochgeladene Zertifikat bis zum Ablaufdatum verwendet. Wenn sich die Spezifikation ändert, tritt eines der folgenden Ereignisse ein:

  • Distributed Cloud verwendet ein vorhandenes übereinstimmendes Zertifikat.
  • Eine Fallback-Zertifizierungsstelle stellt ein neues Zertifikat aus.

Beispiel für die manuelle Rotation eines selbst bereitgestellten Zertifikats

Im folgenden Beispiel sehen Sie ein zuvor signiertes BYO-Zertifikat, das für die manuelle Rotation ausgelöst wurde:

  • Der byoCertStatus-Wert des Zertifikats type ist Ready.

  • Der reason-Wert ist Issued mit einem früheren lastTransitionTime-Wert als der vorherige Wert:

    {
 "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"
       }
     ]
   }
 },
 ```

Im folgenden Beispiel sehen Sie die Ausgabe für ein zuvor signiertes BYO-Zertifikat, das für die manuelle Rotation ausgelöst wurde:

  • Im signedCertStatus wird im Feld reason der Wert Rejected angezeigt, da das zuvor signierte Zertifikat nach der Rotation nicht mehr mit dem neuen CSR übereinstimmt.

  • Im CSR reason steht 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"
}
}

    Benachrichtigungen zur Zertifikatsignierung verwalten

Zertifikatsignierungsbenachrichtigungen für die Erstausstellung, Rotation und den Ablauf müssen von Ihrem IO mithilfe der in diesen Abschnitten des PKI-Runbooks dokumentierten Schritte zur Fehlerbehebung behandelt werden:

  • Informationen zum errorCode der untergeordneten CA: PLATAUTH2001 finden Sie unter PLATAUTH-R2001.

  • Informationen zum Fehlercode für BYO-Zertifikate: PLATAUTH2002 finden Sie unter PLATAUTH-R2002.