Gestionar los certificados

Importante: El proceso de instalación genera certificados autofirmados en tu nombre. Estos certificados expirarán en 90 días, y deberá sustituirlos 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.

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/

Generar una solicitud de firma de certificado (CSR) y una clave privada

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

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

El siguiente comando carga el nuevo certificado para firmar el token. Tenga en cuenta que no reemplaza el certificado de firma de token existente. El certificado debe estar en formato pkcs12 con la extensión .pfx .

Nota: Asegúrate de que el valor que proporcionas para la marca --password esté entre comillas simples. Por ejemplo: --password 'CertificatePassword!@#'.

sudo ./configureUiPathAS.sh identity token-cert update --cert-file-path /path/to/cert --password '<cert_pass>'

Rotar el certificado

Esto rotará o sustituirá el certificado antiguo por el nuevo cargado utilizando la opción de actualizar el certificado.

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, actualiza 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.
   1. Para Firefox, pulsa CTRL+SHIFT+DEL, selecciona Cache y haz clic en Aceptar.
      
      

      

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

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