Reemita manualmente certificados Web de PKI

Esta página fornece instruções para acionar manualmente a reemissão de certificados para os seus endpoints Web isolados do Google Distributed Cloud (GDC).

Antes de começar

Para receber as autorizações necessárias para aceder a certificados num espaço de nomes, peça ao administrador de IAM da sua organização para lhe conceder a função de administrador de certificados TLS Web (web-tls-cert-admin).

Tenha em consideração os seguintes requisitos da conta quando realizar a reemissão do certificado:

  • Use uma conta de operador de infraestrutura (IO) para aceder ao certificado no espaço de nomes do sistema. Peça ao seu IO para realizar esta tarefa.
  • Use uma conta de administrador da plataforma para aceder a certificados noutros espaços de nomes.

Reemita um certificado

Pode reemitir manualmente um certificado com uma atualização de anotação. Se o emissor do certificado predefinido for alterado, a nuvem distribuída não volta a emitir automaticamente certificados assinados pelo emissor do certificado predefinido anterior, a menos que o certificado esteja prestes a expirar.

Para acionar manualmente a reemissão de um certificado, use a CLI kubectl para realizar os seguintes passos:

  1. Defina a anotação manual-reissuance como requested para o alvo Certificate. O exemplo seguinte atualiza o certificado no espaço de nomes istio-system, que usa o emissor de certificado predefinido atual: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. Pode ver um valor de anotação in-progress como um estado de transição enquanto o certificado está a ser reemitido. Aguarde até que o valor da anotação manual-reissuance seja apresentado 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"'

    O resultado tem um aspeto semelhante ao seguinte:

    finished

  3. Verifique o emissor do certificado. Tem de corresponder ao emissor mencionado na especificação do certificado ou, se não for especificado, o emissor tem de corresponder ao emissor predefinido atual:

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

    O resultado tem um aspeto semelhante ao seguinte:

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

Rotação manual do seu próprio certificado

Quando aciona e conclui uma rotação manual do seu próprio certificado (BYO cert), tem de assinar o pedido de assinatura de certificado (CSR) gerado recentemente para um BYO cert assinado anteriormente. Para mais informações, consulte o artigo Assine o certificado BYO.

Durante a rotação, a nuvem distribuída cria um novo par de chaves privadas e públicas. Isto torna o certificado assinado carregado anteriormente incompatível com o novo CSR. Se a especificação do certificado não tiver sido alterada desde o carregamento inicial, o certificado carregado anteriormente permanece em utilização até expirar. Se a especificação for alterada, ocorre um dos seguintes eventos:

  • O Distributed Cloud usa um certificado de correspondência existente.
  • Uma autoridade de certificação (AC) alternativa emite um novo certificado.

Exemplo de rotação manual de certificado BYO

No exemplo seguinte, vê um certificado BYO assinado anteriormente acionado para rotação manual:

  • O byoCertStatus mostra que o valor do certificado type é Ready,

  • O valor reason é Issued com um valor lastTransitionTime anterior ao valor anterior:

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

No exemplo seguinte, vê a saída de um certificado BYO assinado anteriormente acionado para rotação manual:

  • No campo signedCertStatus, o campo reason mostra Rejected porque o certificado assinado anteriormente já não corresponde ao novo CSR após a rotação.

  • O CSR reason indica 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"
}
}

    Faça a gestão dos alertas de assinatura de certificados

Os alertas de assinatura de certificados para emissão, rotação e expiração iniciais têm de ser resolvidos pelo seu IO através dos passos de resolução de problemas documentados nestas secções do manual de PKI:

  • Para o código de erro subCA: PLATAUTH2001, consulte PLATAUTH-R2001.

  • Para o errorCode do BYO cert: PLATAUTH2002, consulte PLATAUTH-R2002.