Cómo volver a emitir manualmente certificados web de PKI

En esta página, se proporcionan instrucciones para activar manualmente la nueva emisión de certificados para tus extremos web aislados de Google Distributed Cloud (GDC).

Antes de comenzar

Para obtener los permisos que necesitas para acceder a los certificados en un espacio de nombres, pídele al administrador de IAM de tu organización que te otorgue el rol de administrador de certificados TLS web (web-tls-cert-admin).

Ten en cuenta los siguientes requisitos de la cuenta cuando vuelvas a emitir el certificado:

  • Usa una cuenta de operador de infraestructura (IO) para acceder al certificado en el espacio de nombres del sistema. Pídele a tu IO que realice esta tarea.
  • Usa una cuenta de administrador de la plataforma para acceder a los certificados en otros espacios de nombres.

Cómo volver a emitir un certificado

Puedes volver a emitir manualmente un certificado con una actualización de anotación. Si cambia la entidad emisora de certificados predeterminada, Distributed Cloud no volverá a emitir automáticamente los certificados firmados por la entidad emisora de certificados predeterminada anterior, a menos que el certificado esté a punto de vencer.

Para activar manualmente la nueva emisión de un certificado, usa la CLI de kubectl y sigue estos pasos:

  1. Establece la anotación manual-reissuance en requested para el objetivo Certificate. En el siguiente ejemplo, se actualiza el certificado default-wildcard-cert en el espacio de nombres istio-system, que usa la entidad emisora de certificados predeterminada actual:

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

  2. Es posible que veas un valor de anotación in-progress como un estado de transición mientras se vuelve a emitir el certificado. Espera a que el valor de la anotación manual-reissuance muestre 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"'

    El resultado es similar al siguiente:

    finished

  3. Verifica la entidad emisora del certificado. Debe coincidir con la entidad emisora mencionada en la especificación del certificado o, si no se especifica, debe coincidir con la entidad emisora predeterminada actual:

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

    El resultado es similar al siguiente:

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

Rotación manual de tu propio certificado

Cuando activas y completas una rotación manual del certificado externo (BYO cert), debes firmar la solicitud de firma de certificado (CSR) recién generada para un certificado externo firmado anteriormente. Para obtener más información, consulta Firma el certificado BYO.

Durante la rotación, Distributed Cloud crea un nuevo par de claves pública y privada. Esto hace que el certificado firmado que se subió antes sea incompatible con la nueva CSR. Si la especificación del certificado no cambió desde la carga inicial, el certificado cargado anteriormente seguirá en uso hasta que venza. Si cambia la especificación, se produce uno de los siguientes eventos:

  • Distributed Cloud usa un certificado coincidente existente.
  • Una autoridad certificadora (CA) de respaldo emite un certificado nuevo.

Ejemplo de rotación manual de un certificado BYO

En el siguiente ejemplo, se muestra un certificado BYO firmado anteriormente que se activó para la rotación manual:

  • El byoCertStatus muestra que el valor type del certificado es Ready.

  • El valor de reason es Issued con un valor de lastTransitionTime anterior al 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"
       }
     ]
   }
 },
 ```

En el siguiente ejemplo, se muestra el resultado de un certificado BYO firmado anteriormente que se activó para la rotación manual:

  • En signedCertStatus, el campo reason muestra Rejected porque el certificado firmado anteriormente ya no coincide con la nueva CSR después de la rotación.

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

    Administra las alertas de firma de certificados

Tu IO debe abordar las alertas de firma de certificados para la emisión, la rotación y el vencimiento iniciales siguiendo los pasos de solución de problemas que se documentan en estas secciones del manual de operaciones de la PKI:

  • Para el código de error de la subCA: PLATAUTH2001, consulta PLATAUTH-R2001.

  • Para el código de error del certificado BYO: PLATAUTH2002, consulta PLATAUTH-R2002.