Gestionar los certificados

Importante:

El proceso de instalación genera certificados autofirmados en tu nombre. Estos certificados cumplen con FIPS y caducarán en 90 días. Debes reemplazarlos por certificados firmados por una autoridad de certificación (AC) de confianza en cuanto finalice la instalación. Si no actualizas los certificados, la instalación dejará de funcionar transcurridos 90 días.

Si instalaste Automation Suite en un host habilitado para FIPS y deseas actualizar los certificados, asegúrate de que sean compatibles con FIPS.

El paquete de instalación ofrece una herramienta de gestión de clústeres que le permite actualizar los certificados después de la instalación. Para acceder a la herramienta, accede al lugar en el que tengas el paquete del instalador:

cd /opt/UiPathAutomationSuite/

Generating a Certificate Signing Request (CSR) and a private key

Para generar el CSR y la clave privada, ejecuta el siguiente comando:

# copy the machine openssl configuration locally
cp /etc/pki/tls/openssl.cnf ./openssl.tmp.cnf

# Replace the [AUTOMATION_SUITE_FQDN] value. For example, "automationsuite.corp.com"
AS_FQDN=[AUTOMATION_SUITE_FQDN]
cat >> ./openssl.tmp.cnf <<EOF
[SAN]
subjectAltName=DNS:$AS_FQDN,DNS:alm.$AS_FQDN,DNS:monitoring.$AS_FQDN,DNS:registry.$AS_FQDN,DNS:objectstore.$AS_FQDN,DNS:insights.$AS_FQDN,DNS:apps.$AS_FQDN
EOF

# create the certificate request
openssl req -new -sha256 -newkey rsa:2048 -nodes -keyout server.key -subj "/C=xx/ST=xx/O=xx/OU=xx/CN=$AS_FQDN" -reqexts SAN -config openssl.tmp.cnf -out ${AS_FQDN}.csr

Su equipo de TI utiliza los valores obtenidos para generar un certificado firmado. La clave privada generada sigue siendo local.

Gestionar certificados de servidor

Para ver más información sobre los certificados de servidor, ejecuta el siguiente comando:

./bin/uipathctl config tls-certificates --help

Salida:

************************************************************************************

Manage tls certificates

Usage:
  uipathctl config tls-certificates [flags]
  uipathctl config tls-certificates [command]

Available Commands:
  get         Get the current tls certificates
  update      Update tls certificates

Flags:
  -h, --help   help for tls-certificates

Global Flags:
      --context string      name of the kubeconfig context to use
  -f, --force               override all user prompts to true
      --kubeconfig string   kubectl configuration file (default: ~/.kube/config)
      --log-format string   log format. one of [text,json] (default "text")
      --log-level string    set log level. one of [trace,debug,info,error] (default "info")
  -q, --quiet                disable progress indicators (emoji/formatted status messages)
      --timeout duration    timeout of the command (default: 90 minutes) (default 1h30m0s)
      --versions string     optional path to versions file

Use "uipathctl config tls-certificates [command] --help" for more information about a command.

************************************************************************************

Las siguientes secciones describen las operaciones que puedes realizar utilizando el comando uipathctl config tls-certificates .

Actualizar el certificado del servidor

Instalación en línea: Cómo encontrar el certificado del servidor

Los certificados se almacenan como secreto a nivel de Istio.Puedes encontrar certificados bajo el nombre istio-ingressgateway-certs en el espacio de nombres istio-system.

Consulta los archivos de certificado en la siguiente lista:

• El certificado TLS del servidor se almacena como tls.crt
• La clave privada TLS del servidor como tls.key
• El paquete de CA se almacena como ca.crt

Puedes verificar los secretos utilizando el siguiente comando :

kubectl -n istio-system get secrets istio-ingressgateway-certs -o yaml

Los certificados también se almacenan en el espacio de nombres de UiPath. Esto es aplicable a todos los productos de UiPath® que necesitan información de certificados para confiar en las llamadas entrantes. Para obtener más detalles, consulta Comprender la arquitectura del contenedor relacionada con los certificados.

Instalación sin conexión: Cómo encontrar el certificado del servidor

Además de los certificados requeridos por la implementación en línea, una implementación sin conexión tiene dos ubicaciones adicionales que usan el mismo rootCA.crt y tls.crt: ArgoCD y el registro de Docker. A continuación, los certificados se almacenan en los espacios de nombres de Docker y ArgoCD.

Puedes verificar los secretos utilizando el siguiente comando :

# For docker registry
kubectl -n docker-registry get secrets docker-registry-tls -o yaml
# For Argocd
argocd login alm.cluster_fqnd --username argocd_username --password argocd_password
argocd cert list --cert-type https

Cómo actualizar los certificados del servidor

Importante: Debes descifrar la clave del certificado antes de actualizar el certificado del servidor. Omitir el paso del descifrado generará un error

Para descifrar la clave del certificado, ejecuta el siguiente comando:

# replace /path/to/encrypted/cert/key to absolute file path of key
# replace /path/to/decrypt/cert/key to store decrypt key
# Once prompted, please entry the passphrase or password to decrypt the key

openssl rsa -in /path/to/encrypted/cert/key -out /path/to/decrypt/cert/key

Ejecuta uipathctl para actualizar el certificado. Necesitas la ruta a cada uno de los tres archivos de certificado. Todo el archivo del certificado debe estar en formato PEM .

• Paquete de entidad de certificación: este paquete debe contener solo los certificados en cadena utilizados para firmar el certificado del servidor TLS. El límite de la cadena es de hasta nueve certificados.

• Certificado del servidor: certificado del servidor público

  Nota:

  El archivo server.crt debe contener toda la cadena, como se muestra en el siguiente ejemplo:

  -----server cert-----
  -----root ca chain-----

• Clave privada: clave privada para el certificado del servidor

  ./bin/uipathctl config tls-certificates update --cert server.crt --cacert ca.crt --key server.key

Los siguientes archivos se almacenarán en la ubicación /directory/path/to/store/certificate .

Acceder al certificado TLS

Para imprimir los archivos del certificado, ejecuta el siguiente comando y especifica el directorio donde se almacenan los certificados.

./bin/uipathctl config tls-certificates get --show-details

Adding the CA certificate to the host trust store

Usted es responsable de asegurarse de que los certificados generados sean de confianza.

Para añadir el certificado al almacén de confianza de la máquina virtual host, ejecuta los siguientes comandos en todos los nodos del clúster:

# 1. Copy the certificate file to the /usr/share/pki/ca-trust-source/anchors/ or the /etc/pki/ca-trust/source/anchors/ directory
cp /path/to/the/ca-cert /usr/share/pki/ca-trust-source/anchors/

# 2. Update the trust store configuration
update-ca-trust

Gestionar certificados de AC adicionales

Para ver más información sobre certificados de CA adicionales, ejecuta el siguiente comando:

./bin/uipathctl config additional-ca-certificates --help

Salida:

***************************************************************************************

Manage additional ca certificates

Usage:
  uipathctl config additional-ca-certificates [flags]
  uipathctl config additional-ca-certificates [command]

Available Commands:
  get         Get the current additional ca certificates
  update      Update additional ca certificates

Flags:
  -h, --help   help for additional-ca-certificates

Global Flags:
      --context string      name of the kubeconfig context to use
  -f, --force               override all user prompts to true
      --kubeconfig string   kubectl configuration file (default: ~/.kube/config)
      --log-format string   log format. one of [text,json] (default "text")
      --log-level string    set log level. one of [trace,debug,info,error] (default "info")
  -q, --quiet               suppress all output except for errors and warnings
      --timeout duration    timeout of the command (default: 90 minutes) (default 1h30m0s)
      --versions string     optional path to versions file

Use "uipathctl config additional-ca-certificates [command] --help" for more information about a command.

***************************************************************************************

Las siguientes secciones describen las operaciones que puedes realizar utilizando el comando uipathctl config additional-ca-certificates .

Actualizar los certificados de AC

Para actualizar los certificados de CA, sigue los siguientes pasos:

1. Actualiza el archivo cluster_config.json para que apunte al archivo con additional_ca_certs. Para obtener más información sobre este parámetro, consulta Configuración de certificados.
2. Aplicar el manifiesto:

   ./bin/uipathctl manifest apply cluster_config.json --versions versions.json

   Importante: Este comando puede fallar con errores como:

   Error: [failed to wait for application argocd/<app-name1>: timed out waiting for the condition,
           failed to wait for application argocd/<app-name2>: timed out waiting for the condition]]
   

   Independientemente del fallo, continúa con el paso 3 para reiniciar las implementaciones y estabilizar el entorno.
3. Reinicia manualmente todas las implementaciones y conjuntos con estado en el espacio de nombres uipath :

   kubectl rollout restart deployment -n <uipath>
   kubectl rollout restart sts -n <uipath>

Nota:

Para anexar los certificados antiguos, debes utilizar el comando get de la sección Acceder a los certificados de CA y anexarlos en el archivo .pem del certificado de CA que debes proporcionar en el campo additional_ca_certs .

El archivo del paquete de certificados de AC debe tener un formato .pem válido y puede constar de más de un certificado.

Acceder a los certificados de AC

Para descargar los certificados de CA ya configurados, ejecuta el siguiente comando:

 ./bin/uipathctl config additional-ca-certificates get

Adding the CA certificate to the host trust store

Usted es responsable de asegurarse de que los certificados generados sean de confianza.

Para añadir el certificado al almacén de confianza de la máquina virtual host, ejecuta los siguientes comandos en todos los nodos del clúster:

# 1. Copy the certificate file to the /usr/share/pki/ca-trust-source/anchors/ or the /etc/pki/ca-trust/source/anchors/ directory
cp /path/to/the/ca-cert /usr/share/pki/ca-trust-source/anchors/

# 2. Update the trust store configuration
update-ca-trust

Para entornos Windows, consulta esta guía para instalar certificados raíz de confianza.

Gestionar certificados de firma de tokens de identidad

Automation Suite ofrece dos métodos para gestionar la rotación de certificados de firma de tokens de identidad: automático y manual.

Para ver más información sobre los certificados de firma de tokens de identidad, ejecuta el siguiente comando:

./bin/uipathctl config token-signing-certificates --help

Salida:

************************************************************************************

Manage token signing certificates

Usage:
  uipathctl config token-signing-certificates [flags]
  uipathctl config token-signing-certificates [command]

Available Commands:
  automatic-key-management Manage key management
  get                      Get the current token signing certificate
  rotate                   Rotate token signing certificates
  update                   Update future token signing certificate

Flags:
  -h, --help   help for token-signing-certificates

Global Flags:
      --context string      name of the kubeconfig context to use
  -f, --force               override all user prompts to true
      --kubeconfig string   kubectl configuration file (default: ~/.kube/config)
      --log-format string   log format. one of [text,json] (default "text")
      --log-level string    set log level. one of [trace,debug,info,error] (default "info")
  -q, --quiet               suppress all output except for errors and warnings
      --timeout duration    timeout of the command (default: 90 minutes) (default 1h30m0s)
      --versions string     optional path to versions file

Use "uipathctl config token-signing-certificates [command] --help" for more information about a command.

************************************************************************************

Importante:

Puedes utilizar una longitud máxima de clave de 4096 bits para firmar certificados. Te recomendamos encarecidamente que utilices una longitud de clave de al menos 512 bits (64 bytes) como práctica recomendada.

La siguiente sección proporciona detalles sobre las operaciones que puedes realizar utilizando el comando uipathctl config token-signing-certificates .

Rotación automática de certificados

La rotación automática de certificados significa que Automation Suite gestiona el ciclo de vida de las claves de firma. Esto incluye rotar las claves cada 90 días, anunciar nuevas claves 14 días antes de la rotación, conservar las claves antiguas durante 14 días después de la rotación y luego eliminarlas cuando finalice el período de 14 días.

Si te actualizas desde una versión anterior a la 2.2510, la rotación automática de certificados está deshabilitada de forma predeterminada. Para habilitar la gestión automática de claves, utiliza el siguiente comando:

./bin/uipathctl config token-signing-certificates automatic-key-management enable

Importante:

Habilitar la rotación automática de certificados puede provocar un tiempo de inactividad de hasta una hora.

La rotación automática de certificados está habilitada de forma predeterminada para las instalaciones limpias de Automation Suite. Para deshabilitar la gestión automática de claves, utiliza el siguiente comando:

./bin/uipathctl config token-signing-certificates automatic-key-management disable

Si la función de gestión automática está deshabilitada, los certificados de firma deben actualizarse y rotarse manualmente. Para obtener más información sobre la gestión manual de claves, consulta la documentación sobre la actualización y rotación manual del certificado.

Actualizar manualmente el certificado

Para cargar el nuevo certificado para firmar el token, ejecuta el siguiente comando:

Nota:

El siguiente comando no reemplaza el certificado de firma de token existente.

Asegúrese de que el certificado que proporciona esté en formato .pem .

El archivo server.crt debe contener toda la cadena, como se muestra en el siguiente ejemplo:

-----server cert-----
-----root ca chain-----

./bin/uipathctl config token-signing-certificates update --cert server.crt --key server.key

Rotar manualmente el certificado

Para rotar o reemplazar el certificado antiguo por el nuevo, ejecuta el siguiente comando:

./bin/uipathctl config token-signing-certificates rotate

Nota:

El tiempo de espera entre la actualización del certificado y la rotación debe ser de 24 a 48 horas.

Este tiempo de espera es necesario para poder seguir admitiendo la autenticación de tokens en caché firmados por un certificado antiguo.

Si se rota el certificado con demasiada antelación a la expiración del token de caché, puede ocasionarse tiempo de inactividad. Y es posible que deba reiniciar todos sus robots.

Rotación de certificados en caso de emergencia

Importante: El siguiente procedimiento es solo para emergencias. Debes rotar certificados antes de sus fechas de caducidad

Para realizar una actualización de certificados de emergencia, sigue estos pasos:

1. Obtén un nuevo certificado o crea uno autofirmado y cópialo en el nodo del servidor de clúster utilizado para ejecutar los siguientes pasos de rotación. Para crear un nuevo certificado autofirmado, ejecuta el siguiente comando:

   openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout identityserver.key -out identityserver.crt
   openssl pkcs12 -export -out identityserver.pfx -inkey identityserver.key -in identityserver.crt

2. Si IdentityServer1.pfx ha caducado, rota y actualiza el certificado.Para obtener instrucciones, consulta Rotar el certificado.
3. Si IdentityServer2.pfx ha caducado, actualice el certificado.
4. Si ambos certificados caducan, actualiza, rota y vuelve a actualizar.
5. Reinicio de todas las implementaciones.Para obtener instrucciones, consulta Resolución de problemas.
6. Borrar todas las caché de navegador.Si ejecutas en modo de incógnito o privado, puedes omitir este paso.
7. Para Firefox, pulsa CTRL+SHIFT+DEL, selecciona Caché y selecciona Aceptar.
   
   

   

   
   
8. Para Chrome, pulsa CTRL+SHIFT+DEL, selecciona Imágenes y archivos en caché y selecciona Borrar datos.
   
   

   

   
   

Acceder al certificado

Ejecuta el siguiente comando para descargar el certificado de firma del token actual:

./bin/uipathctl config token-signing-certificates get --show-details 

Gestionar certificados RKE2

Por defecto, los certificados RKE2 caducan en 12 meses. En los 90 días anteriores a su fecha de vencimiento, los certificados se rotan al reiniciar RKE2.

Para más detalles, consulta RKE2: opciones avanzadas: rotación de certificados.

Comprobar la fecha de vencimiento del certificado de RKE2

Para comprobar la fecha de vencimiento del certificado RKE2, ejecuta el siguiente comando en cualquiera de los nodos:

if [[ -d "/var/lib/rancher/rke2/server/tls" ]]; then
  dir="/var/lib/rancher/rke2/server/tls"
elif [[ -d "/var/lib/rancher/rke2/agent/tls" ]]; then
  dir="/var/lib/rancher/rke2/agent/tls"
else
dir="/var/lib/rancher/rke2/agent/"
fi
# Loop through each .crt file in the directory
for file in "$dir"/*.crt; do
# Extract the expiry date from the certificate
expiry=$(openssl x509 -enddate -noout -in "$file" | cut -d= -f 2-)
# Get the file name without the path
filename=$(basename "$file")
# Print the filename and expiry date in a pretty format
printf "%-30s %s\n" "$filename:" "$expiry"
done

El resultado obtenido debería ser similar al mostrado en la siguiente imagen:

Rotar el certificado de RKE2

De forma predeterminada, los certificados RKE2 caducan en 12 meses. En los 90 días anteriores a su fecha de vencimiento, los certificados se rotan al reiniciar RKE2. Sin embargo, si la validez de los certificados supera el período de 90 días, debes rotar manualmente los certificados siguiendo los pasos mencionados en RKE2 - Opciones avanzadas - Rotación de certificados.

Si deseas personalizar el período de caducidad de los certificados RKE2 para cumplir requisitos particulares, puedes hacerlo antes de reiniciar los servicios RKE2 para los nodos de servidor y agente.

Para rotar los certificados RKE2, debes ejecutar primero una serie de acciones en los nodos del servidor y luego continuar con algunos pasos en los nodos del agente.

Ejecuta los siguientes pasos en los nodos del servidor:

1. Detén el servidor RKE2:

   systemctl stop rke2-server.service

2. Borrar cualquier proceso RKE2 restante:

   rke2-killall.sh

3. Elimina el archivo dynamic-cert.json ubicado en /var/lib/rancher/rke2/server/tls/.

4. Para personalizar el período de caducidad de los certificados RKE2, utiliza el siguiente comando. Ten en cuenta que este ejemplo establece el período de validez en 1000 días, pero puedes cambiar este valor en función de tus requisitos.

   SERVICE_NAME="rke2-server.service"
   conf_file_path="/etc/systemd/system/${SERVICE_NAME}.d/cert.conf"
   mkdir -p /etc/systemd/system/"${SERVICE_NAME}".d/
   
   cat > "$conf_file_path" <<EOF
   [Service]
   Environment="CATTLE_NEW_SIGNED_CERT_EXPIRATION_DAYS=1000"
   EOF
   
   systemctl daemon-reload

5. Reinicia el servidor RKE2:

   systemctl start rke2-server.service

   Nota: si el clúster tiene más de un nodo del servidor, los pasos 1-4 pueden no ejecutarse por completo, ya que etcd puede no poder completar la elección del líder. Si esto sucede, repite los pasos de 1-4 en otros nodos del servidor.
6. Elimina el secreto rke2-serving del espacio de nombres kube-system:

   kubectl delete secret -n kube-system rke2-serving

   Nota:

   En una implementación multinodo, es posible que no puedas ejecutar los comandos kubectl hasta que hayas completado las primeras cuatro operaciones en el número necesario de nodos del servidor. Esto es para cumplir el requisito de quórum etcd. Puedes eliminar el secreto rke2-serving inmediatamente después de que el servidor RKE2 se inicie.

Una vez que etcd alcanza el quórum, el servidor RKE2 puede iniciar el resto de los pods del plano de control. A continuación, deberías ver la ejecución correcta del comando kubectl get nodes. Cuando tus nodos del servidor están listos, puedes continuar a los nodos del agente para regenerar los certificados.

Ejecuta los siguientes pasos en los nodos del agente:

1. Detén el servidor RKE2:

   systemctl stop rke2-agent.service

2. Borrar cualquier proceso RKE2 restante:

   rke2-killall.sh

3. Para personalizar el período de caducidad de los certificados RKE2, utiliza el siguiente comando. Ten en cuenta que este ejemplo establece el período de validez en 1000 días, pero puedes cambiar este valor en función de tus requisitos.

   SERVICE_NAME="rke2-agent.service"
   conf_file_path="/etc/systemd/system/${SERVICE_NAME}.d/cert.conf"
   mkdir -p /etc/systemd/system/"${SERVICE_NAME}".d/
   
   cat > "$conf_file_path" <<EOF
   [Service]
   Environment="CATTLE_NEW_SIGNED_CERT_EXPIRATION_DAYS=1000"
   EOF
   
   systemctl daemon-reload

4. Reinicia el servidor RKE2:

   systemctl start rke2-agent.service

Gestionar el certificado de registro externo compatible con OCI

Para actualizar el certificado para el registro externo compatible con OCI, después de la instalación, sigue estos pasos:

1. Actualiza el marcador registry_ca_cert en el archivo cluster_config.json . Para obtener más información, consulta Configuración de registro compatible con OCI externo.
2. Actualiza la CA raíz utilizada por el registro externo compatible con OCI ejecutando el siguiente comando en todos los nodos:

   ./bin/uipathctl rke2 generate-registries cluster_config.json --current-config-path /etc/rancher/rke2/registries.yaml > /etc/rancher/rke2/registries.yaml.tmp
   mv -f /etc/rancher/rke2/registries.yaml.tmp /etc/rancher/rke2/registries.yaml
   systemctl restart rke2-server || systemctl restart rke2-agent

3. Actualiza el certificado de CA de confianza de ArgoCD para el registro externo compatible con OCI:

   ./bin/uipathctl config argocd ca-certificates update --cacert [PATH]