Emettere nuovamente i certificati web PKI manualmente

Questa pagina fornisce istruzioni per attivare manualmente la riemissione dei certificati per gli endpoint web air gap di Google Distributed Cloud (GDC).

Prima di iniziare

Per ottenere le autorizzazioni necessarie per accedere ai certificati in uno spazio dei nomi, chiedi all'amministratore IAM dell'organizzazione di concederti il ruolo Amministratore certificati TLS web (web-tls-cert-admin).

Quando esegui la riemissione del certificato, tieni presente i seguenti requisiti dell'account:

• Utilizza un account Infrastructure Operator (IO) per accedere al certificato nello spazio dei nomi di sistema. Chiedi al tuo IO di eseguire questa attività.

• Utilizza un account amministratore della piattaforma per accedere ai certificati in altri spazi dei nomi.

Riemettere un certificato

Puoi riemettere manualmente un certificato con un aggiornamento dell'annotazione. Se l'emittente di certificati predefinita cambia, Distributed Cloud non riemetterà automaticamente i certificati firmati dall'emittente di certificati predefinita precedente, a meno che il certificato non stia per scadere.

Per attivare manualmente la riemissione di un certificato, utilizza la CLI kubectl per completare i seguenti passaggi:

1. Imposta l'annotazione manual-reissuance su requested per il target Certificate. L'esempio seguente aggiorna il certificato default-wildcard-cert nello spazio dei nomi istio-system che utilizza l'emittente di certificati predefinita corrente:

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

2. Potresti visualizzare un valore di annotazione in-progress come stato di transizione mentre il certificato viene riemesso. Attendi che venga visualizzato il valore dell'annotazione 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"'
   

   L'output è simile al seguente:

   finished
   

3. Verifica l'autorità di certificazione; deve corrispondere a quella menzionata nella specifica del certificato o, se non specificata, deve corrispondere a quella predefinita attuale:

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

   L'output è simile al seguente:

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

Rotazione manuale del certificato Bring Your Own Certificate

Quando attivi e completi una rotazione manuale del certificato Bring Your Own (BYO), devi firmare la richiesta di firma del certificato (CSR) appena generata per un certificato BYO firmato in precedenza. Per saperne di più, vedi Firmare il certificato BYO.

Durante la rotazione, Distributed Cloud crea una nuova coppia di chiavi privata e pubblica. In questo modo, il certificato firmato caricato in precedenza non è compatibile con la nuova CSR. Se la specifica del certificato non è cambiata rispetto al caricamento iniziale, il certificato caricato in precedenza rimane in uso fino alla sua scadenza. Se le specifiche cambiano, si verifica uno dei seguenti eventi:

• Distributed Cloud utilizza un certificato corrispondente esistente.
• Un'autorità di certificazione (CA) di riserva emette un nuovo certificato.

Esempio di rotazione manuale del certificato BYO

Nell'esempio seguente viene visualizzato un certificato BYO firmato in precedenza attivato per la rotazione manuale:

• byoCertStatus mostra che il valore type del certificato è Ready,

• Il valore reason è Issued con un valore lastTransitionTime precedente rispetto al valore precedente:

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

Nell'esempio seguente, viene visualizzato l'output per un certificato BYO firmato in precedenza attivato per la rotazione manuale:

• Nel signedCertStatus, il campo reason mostra Rejected perché il certificato firmato in precedenza non corrisponde più alla nuova richiesta di firma del certificato dopo la rotazione.

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

  Gestire gli avvisi di firma dei certificati

Gli avvisi di firma dei certificati per l'emissione, la rotazione e la scadenza iniziali devono essere gestiti dal tuo IO utilizzando i passaggi per la risoluzione dei problemi documentati in queste sezioni del runbook PKI:

• Per subCA errorCode: PLATAUTH2001, vedi PLATAUTH-R2001.

• Per il codice di errore del certificato BYO: PLATAUTH2002, consulta PLATAUTH-R2002.