Volver a emitir manualmente certificados web de PKI

En esta página se explica cómo activar manualmente la reedición de certificados para los endpoints web de tu dispositivo air-gapped de Google Distributed Cloud (GDC).

Antes de empezar

Para obtener los permisos que necesitas para acceder a los certificados de un espacio de nombres, pide a tu administrador de gestión de identidades y accesos de la organización que te conceda el rol Administrador de certificados TLS web (web-tls-cert-admin).

Ten en cuenta los siguientes requisitos de la cuenta al volver a emitir un certificado:

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

Volver a emitir un certificado

Puedes volver a emitir manualmente un certificado con una actualización de la anotación. Si cambia la entidad emisora de certificados predeterminada, el dispositivo aislado de GDC 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 caducar.

Para activar manualmente la reedición de un certificado, usa la CLI kubectl para seguir estos pasos:

  1. Asigna la anotación manual-reissuance a requested para el elemento de destino Certificate. En el siguiente ejemplo se actualiza el certificado default-wildcard-cert del espacio de nombres istio-system, que usa el emisor de certificados predeterminado actual:

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

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

    El resultado es similar al siguiente:

    finished

  3. Verifica el emisor del certificado. Debe coincidir con el emisor mencionado en la especificación del certificado o, si no se especifica, debe coincidir con el emisor predeterminado 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 certificados propios

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

Durante la rotación, el dispositivo con air gap de GDC crea un nuevo par de claves privada y pública. Por lo tanto, el certificado firmado que se subió anteriormente no es compatible con la nueva CSR. Si la especificación del certificado no ha cambiado desde la subida inicial, el certificado subido anteriormente seguirá en uso hasta que caduque. Si cambia la especificación, se produce uno de los siguientes eventos:

  • El dispositivo con air gap de GDC usa un certificado coincidente.
  • Una autoridad de certificación (CA) de respaldo emite un nuevo certificado.

Ejemplo de rotación manual de un certificado propio

En el siguiente ejemplo, se muestra un certificado BYO firmado anteriormente que se ha activado 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 ha activado para la rotación manual:

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

  • La reason CSR WaitingForSigning indica lo siguiente:

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

Gestionar alertas de firma de certificados

Tu IO debe solucionar las alertas de firma de certificados de emisión inicial, rotación y vencimiento siguiendo los pasos para solucionar problemas que se indican en estas secciones del manual de operaciones de la PKI:

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

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