Reemitir manualmente certificados da Web da ICP

Este documento fornece instruções para acionar manualmente a reemissão de certificados para seus endpoints da Web do Google Distributed Cloud (GDC) com isolamento físico.

Este documento é destinado a públicos-alvo do grupo de administradores de plataforma que querem gerenciar certificados da Web de PKI. Para mais informações, consulte Públicos-alvo da documentação do GDC com isolamento físico.

Antes de começar

Antes de reemitir manualmente certificados da Web, você precisa ter as permissões necessárias e preparar o ambiente.

Solicitar papéis do IAM

Para criar, atualizar e excluir certificados da Web de PKI em um namespace, entre em contato com o administrador do IAM da organização para solicitar o papel Administrador de certificados TLS da Web (web-tls-cert-admin).

Considere os seguintes requisitos da conta:

  • Um membro do grupo de operadores de infraestrutura precisa reemitir certificados da Web de PKI no namespace do sistema.
  • Os membros do grupo de administradores de plataforma podem reemitir certificados da Web de PKI em todos os outros namespaces que gerenciam.

Preparar o ambiente

Reemitir um certificado

É possível reemitir um certificado manualmente com uma atualização de anotação. Se o emissor do certificado padrão mudar, o Distributed Cloud não vai reemitir automaticamente os certificados assinados pelo emissor do certificado 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 Certificate de destino. O exemplo a seguir atualiza o certificado default-wildcard-cert no namespace istio-system, que usa o emissor do 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. Um valor de anotação in-progress pode aparecer como um estado de transição enquanto o certificado está sendo 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, o emissor precisa corresponder 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 próprio certificado

Ao acionar e concluir uma rotação manual do próprio certificado (BYO, na sigla em inglês), você precisa assinar a solicitação de assinatura de certificado (CSR, na sigla em inglês) 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 permanecerá em uso até expirar. Se a especificação mudar, um dos seguintes eventos ocorrerá:

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

Exemplo de rotação manual do certificado BYO

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

  • O byoCertStatus mostra que o valor type do certificado é 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 a seguir, você verá a saída de um certificado BYO assinado anteriormente acionado para rotação manual:

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

  • O reason da CSR declara 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 tratados pelo IO usando as etapas de solução de problemas documentadas nestas seções do runbook de PKI:

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

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