Reemitir manualmente certificados da Web da ICP

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

Antes de começar

Para receber as permissões necessárias para acessar certificados em um namespace, peça ao administrador do IAM da organização para conceder a você o papel de administrador de certificados TLS da Web (web-tls-cert-admin).

Considere os seguintes requisitos de conta ao fazer a nova emissão de certificados:

  • Use uma conta de operador de infraestrutura (IO) para acessar o certificado no namespace do sistema. Peça ao IO para realizar essa tarefa.
  • Use uma conta de administrador da plataforma para acessar certificados em outros namespaces.

Reemitir um certificado

É possível reemitir manualmente um certificado com uma atualização de anotação. Se o emissor de certificado padrão mudar, o Distributed Cloud não vai reemitir automaticamente os certificados assinados pelo emissor padrão 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 as seguintes etapas:

  1. Defina a anotação manual-reissuance como requested para o destino Certificate. O exemplo a seguir atualiza o certificado default-wildcard-cert no namespace istio-system, que usa o emissor de certificado padrão atual:

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

  2. Você pode ver um valor de anotação in-progress como um estado de transição enquanto o certificado é reemitido. Aguarde até que o valor da anotação manual-reissuance mostre 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"'

    A saída será assim:

    finished

  3. Verifique o emissor do certificado. Ele precisa corresponder ao emissor mencionado na especificação do certificado ou, se não for especificado, ao emissor padrão atual:

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

    A saída será assim:

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

Rotação manual do certificado BYOC

Ao acionar e concluir uma rotação manual de certificado próprio (BYO cert), você precisa assinar a solicitação de assinatura de certificado (CSR) recém-gerada para um certificado BYO assinado anteriormente. Para mais informações, consulte Assinar o certificado BYO.

Durante a rotação, o Distributed Cloud cria um novo par de chaves privadas e públicas. Isso torna o certificado assinado enviado anteriormente incompatível com a nova CSR. Se a especificação do certificado não tiver mudado desde o upload inicial, o certificado enviado anteriormente vai continuar em uso até expirar. Se a especificação mudar, um dos seguintes eventos vai ocorrer:

  • O Distributed Cloud usa um certificado correspondente.
  • Uma autoridade de certificação (CA) de substituição emite um novo certificado.

Exemplo de rotação manual de certificado BYO

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

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

  • O valor de reason é Issued com um valor de 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 a seguir, você vê a saída de um certificado BYO assinado anteriormente acionado para rotação manual:

  • Em signedCertStatus, o campo reason mostra Rejected porque o certificado assinado anteriormente não corresponde mais à nova CSR após a rotação.

  • A CSR reason afirma 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"
}
}

    Gerenciar alertas de assinatura de certificado

Os alertas de assinatura de certificado para emissão, rotação e expiração iniciais precisam ser resolvidos pelo seu IO usando as etapas de solução de problemas documentadas nestas seções do runbook da ICP:

  • Para subCA errorCode: PLATAUTH2001, consulte PLATAUTH-R2001.

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