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
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:

sudo ./configureUiPathAS.sh tls-cert --help

Salida:

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

Manage cluster tls and server certificate

Usage:
  configureUiPathAS.sh tls-cert [command]
  configureUiPathAS.sh tls-cert [flags]

Available Commands:
  update                              Update the tls / server certificate

  get                                 Get the tls / server certificate

Flags:
  -h|--help                           Display help

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

Las siguientes secciones describen las operaciones que puedes realizar utilizando el comando ./configureUiPathAS.sh tls-cert .

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

Ejecute el script configureUiPathAS.sh para actualizar el certificado como se muestra a continuación. Necesita la ruta a cada uno de los tres archivos del 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

• Clave privada: clave privada para el certificado del servidor

  sudo ./configureUiPathAS.sh tls-cert update --ca-cert-file /path/to/cacert --tls-cert-file /path/to/tlscert --tls-key-file /path/to/tlskey

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.

sudo ./configureUiPathAS.sh tls-cert get --outpath /directory/path/to/store/certificate

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:

./configureUiPathAS.sh additional-ca-certs --help

Salida:

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

Manage additional CA certificates, this can be used to add sql server CA

Usage:
  configureUiPathAS.sh additional-ca-certs [command]
  configureUiPathAS.sh additional-ca-certs [flags]

Available Commands:
  update                              Update the additional trusted CA certificates.

  get                                 Get the additional trusted CA certificates

Flags:
  -h|--help                           Display help

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

Las siguientes secciones describen las operaciones que puedes realizar utilizando el comando ./configureUiPathAS.sh additional-ca-certs .

Actualizar los certificados de AC

Este comando le ayuda a actualizar o sustituir los certificados de AC configurados existentes.

./configureUiPathAS.sh additional-ca-certs update --ca-cert-file /path/to/ca/certs

Nota:

El comando anterior añade un certificado nuevo a la lista de certificados existentes. Si desea sustituir todos los certificados configurados previamente, añada --replace al final.

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:

./configureUiPathAS.sh additional-ca-certs get --outpath /path/to/download/certs

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 firma de tokens de identidad

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

sudo ./configureUiPathAS.sh identity token-cert --help

Salida:

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

Manage Identity token signing certificate

Usage:
  configureUiPathAS.sh identity token-cert [command]
  configureUiPathAS.sh identity token-cert [flags]

Available Commands:
  update                              Update secondary certificate to signing
                                        the authentication token
  rotate                              Switch secondary certificate as a primary
                                        token signing certificate
  get                                 Get token signing certificate

Flags:
  -h|--help                           Display help

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

La siguiente sección proporciona detalles sobre las operaciones que puedes realizar utilizando el comando./configureUiPathAS.sh identity token-cert .

Actualizar 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 .

sudo ./configureUiPathAS.sh identity token-cert update --cert-file-path /path/to/cert --cert-key-file-path /path/to/certkey

Rotar el certificado

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

sudo ./configureUiPathAS.sh identity token-cert 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.
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 Cache y haz clic en Aceptar.
   
   

   

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

   

   
   

Acceder al certificado

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

sudo ./configureUiPathAS.sh identity token-cert get --outpath /directory/path/to/store/certificate

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:

# Directory path to check
if [[ -d "/var/lib/rancher/rke2/server/tls" ]]; 
then
dir="/var/lib/rancher/rke2/server/tls"
else
dir="/var/lib/rancher/rke2/agent/tls"
fi
# Loop through each .crt file in the directory
for file in "$dir"/*.crt;
# Extract the expiry date from the certificate
 do
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

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. 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.
5. 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. 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]