Réémettre manuellement des certificats Web PKI

Cette page explique comment déclencher manuellement la réémission des certificats pour les points de terminaison Web de votre appliance Google Distributed Cloud (GDC) air-gapped.

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 opérations 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, l'appliance GDC air-gapped 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 et procédez comme suit :

  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 un é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é, à 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), 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, l'appliance GDC air-gapped crée une paire de clés privée et publique. 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 :

  • L'appliance GDC sous air gap 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.

Étapes suivantes