Réémettre manuellement des certificats Web PKI

Cette page explique comment déclencher manuellement le renouvellement des certificats pour vos points de terminaison Web isolés de Google Distributed Cloud (GDC).

Avant de commencer

Pour obtenir les autorisations nécessaires pour accéder aux certificats dans un espace de noms, demandez à votre administrateur IAM de l'organisation de vous accorder le rôle Administrateur de certificats TLS Web (web-tls-cert-admin).

Tenez compte des exigences suivantes concernant le compte lorsque vous réémettez un certificat :

  • Utilisez un compte d'opérateur d'infrastructure (IO) pour accéder au certificat dans l'espace de noms système. Demandez à votre responsable des identités d'effectuer cette tâche.
  • Utilisez un compte administrateur de plate-forme pour accéder aux certificats dans d'autres espaces de noms.

Réémettre un certificat

Vous pouvez réémettre manuellement un certificat avec une annotation mise à jour. Si l'émetteur de certificats par défaut change, Distributed Cloud ne réémettra pas automatiquement les certificats signés par l'ancien émetteur de certificats par défaut, sauf si le certificat est sur le point d'expirer.

Pour déclencher manuellement la réémission d'un certificat, utilisez la CLI kubectl pour effectuer les étapes suivantes :

  1. Définissez l'annotation manual-reissuance sur requested pour la cible Certificate. L'exemple suivant met à jour le certificat default-wildcard-cert dans l'espace de noms istio-system qui utilise l'émetteur de certificat par défaut actuel :

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

  2. Il est possible que la valeur d'annotation in-progress s'affiche comme état de transition pendant la réémission du certificat. Attendez que la valeur de l'annotation manual-reissuance affiche 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"'

    La sortie ressemble à ceci :

    finished

  3. Vérifiez l'émetteur du certificat. Il doit correspondre à l'émetteur mentionné dans la spécification du certificat ou, s'il n'est pas spécifié, il doit correspondre à l'émetteur par défaut actuel :

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

    La sortie ressemble à ceci :

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

Rotation manuelle de votre propre certificat

Lorsque vous déclenchez et effectuez une rotation manuelle de votre propre certificat (BYO cert), vous devez signer la demande de signature de certificat (CSR) nouvellement générée pour un certificat BYO précédemment signé. Pour en savoir plus, consultez Signer le certificat BYO.

Lors de la rotation, Distributed Cloud crée une paire de clés privées et publiques. Le certificat signé importé précédemment devient alors incompatible avec la nouvelle CSR. Si la spécification du certificat n'a pas changé depuis l'importation initiale, le certificat importé précédemment reste utilisé jusqu'à son expiration. Si la spécification change, l'un des événements suivants se produit :

  • Distributed Cloud utilise un certificat correspondant existant.
  • Une autorité de certification (CA) de secours émet un nouveau certificat.

Exemple de rotation manuelle de certificat BYO

Dans l'exemple suivant, vous voyez un certificat BYO précédemment signé déclenché pour la rotation manuelle :

  • Le byoCertStatus indique que la valeur type du certificat est Ready.

  • La valeur reason est Issued avec une valeur lastTransitionTime antérieure à la valeur précédente :

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

Dans l'exemple suivant, vous voyez la sortie d'un certificat BYO signé précédemment déclenché pour la rotation manuelle :

  • Dans signedCertStatus, le champ reason affiche Rejected, car le certificat signé précédemment ne correspond plus à la nouvelle CSR après la rotation.

  • La CSR reason indique 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"
}
}

    Gérer les alertes de signature de certificat

Votre équipe d'ingénieurs d'exploitation doit résoudre les alertes de signature de certificat pour l'émission initiale, la rotation et l'expiration en suivant les étapes de dépannage décrites dans les sections suivantes du runbook PKI :

  • Pour le code d'erreur de la sous-autorité de certification : PLATAUTH2001, consultez PLATAUTH-R2001.

  • Pour le code d'erreur BYO cert : PLATAUTH2002, consultez PLATAUTH-R2002.