Gestion des certificats

Important :

Le processus d'installation génère des certificats auto-signés en votre nom. Ces certificats sont conformes à la norme FIPS et expireront dans 90 jours. Vous devez les remplacer par des certificats signés par une autorité de certification (CA) approuvée dès la fin de l'installation. Si vous ne mettez pas à jour les certificats, l'installation cessera d'être opérationnelle après 90 jours.

Si vous avez installé Automation Suite sur un hôte compatible FIPS et que vous souhaitez mettre à jour les certificats, assurez-vous qu'ils sont compatibles avec FIPS.

Le bundle d'installation fournit un outil de gestion de cluster qui vous permet de mettre à jour les certificats après l'installation. Pour accéder à l'outil, accédez à l'emplacement du bundle d'installation :

cd /opt/UiPathAutomationSuite/

Génération d'une demande de signature de certificat (CSR) et d'une clé privée

Pour générer la CSR et la clé privée, exécutez la commande suivante :

# 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

Votre équipe informatique utilise les valeurs obtenues pour générer un certificat signé. La clé privée générée reste locale.

Gestion des certificats de serveur

Pour afficher plus d'informations sur les certificats de serveur, exécutez la commande suivante :

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

Sortie :

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

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
      --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 "error")
  -q, --quiet               suppress all output except for errors and warnings
      --timeout duration    timeout of the command (default 1h0m0s)

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

Les sections suivantes décrivent les opérations que vous pouvez effectuer à l'aide de la commande uipathctl config tls-certificates .

Mise à jour du certificat du serveur

Installation en ligne : Comment trouver le certificat du serveur

Les certificats sont stockés en tant que secret au niveau Istio. Vous pouvez trouver des certificats sous le nom istio-ingressgateway-certs dans l'espace de noms istio-system .

Consultez les fichiers de certificat dans la liste suivante :

• Le certificat TLS du serveur est stocké en tant que tls.crt
• Clé privée TLS du serveur en tant que tls.key
• Le bundle CA est stocké en tant que ca.crt

Vous pouvez vérifier les secrets à l'aide de la commande suivante :

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

Les certificats sont également stockés dans l’espace de noms UiPath. Cela s’applique à tous les produits UiPath® qui ont besoin d’informations de certificat afin d’approuver les appels entrants. Pour plus de détails, consultez la section Comprendre l’architecture de conteneur liée aux certificats.

Installation hors ligne : comment trouver le certificat du serveur

En plus des certificats requis par le déploiement en ligne, un déploiement hors ligne comporte deux emplacements supplémentaires qui utilisent les mêmes rootCA.crt et tls.crt: ArgoCD et le registre Docker. Les certificats sont ensuite stockés dans les espaces de noms Docker et ArgoCD.

Vous pouvez vérifier les secrets à l'aide de la commande suivante :

# 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

Comment mettre à jour les certificats de serveur

Important : vous devez déchiffrer la clé de certificat avant de mettre à jour le certificat du serveur. Ignorer l’étape de déchiffrement entraînerait une erreur.

Pour déchiffrer la clé de certificat, exécutez la commande suivante :

# 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

Run uipathctl to update the certificate as shown below. You need the path to each of the three certificate files. All the certificate file should be in PEM format.

• Ensemble de l'autorité de certification (Certificate Authority Bundle) : ce bundle ne doit contenir que les certificats de chaîne utilisés pour signer le certificat du serveur TLS. La limite de la chaîne est de neuf certificats.

• Certificat de serveur - Certificat de serveur public

  Remarque :

  The server.crt file must contain the entire chain, as shown in the following example:

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

• Clé privée - Clé privée pour le certificat du serveur

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

Les fichiers ci-dessous seront stockés à l'emplacement /directory/path/to/store/certificate.

Accéder au certificat TLS

Pour imprimer les fichiers de certificat, exécutez la commande suivante en spécifiant le répertoire dans lequel les certificats sont stockés.

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

Ajout du certificat CA au magasin d'approbations hôte

Vous êtes responsable de vous assurer que les certificats générés sont approuvés.

Pour ajouter le certificat au magasin approuvé de la machine virtuelle hôte, exécutez les commandes suivantes sur tous les nœuds du cluster :

# 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

Gestion des certificats CA supplémentaires

Pour afficher plus d'informations sur les certificats CA supplémentaires, exécutez la commande suivante :

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

Sortie :

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

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
      --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 "error")
  -q, --quiet               suppress all output except for errors and warnings
      --timeout duration    timeout of the command (default 1h0m0s)

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

Les sections suivantes décrivent les opérations que vous pouvez effectuer à l'aide de la commande uipathctl config additional-ca-certificates .

Mise à jour des certificats CA

Cette commande vous aide à mettre à jour ou à remplacer les certificats CA configurés existants.

./bin/uipathctl config additional-ca-certificates update --cacert additional_ca.crt

Remarque :

La commande ci-dessus ajoute un nouveau certificat à la liste des certificats existants. si vous souhaitez remplacer tous les certificats précédemment configurés, assurez-vous d'ajouter --replace à la fin.

Le fichier groupé de certificats CA doit être au format .pem valide et peut contenir plusieurs certificats.

Accéder aux certificats CA

Pour télécharger les certificats CA déjà configurés, exécutez la commande suivante :

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

Ajout du certificat CA au magasin d'approbations hôte

Vous êtes responsable de vous assurer que les certificats générés sont approuvés.

Pour ajouter le certificat au magasin approuvé de la machine virtuelle hôte, exécutez les commandes suivantes sur tous les nœuds du cluster :

# 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

Gestion des certificats de signature de jeton d'identité

Automation Suite offers two methods to manage the rotation of identity token-signing certificates: automatic and manual.

Pour afficher plus d'informations sur les certificats de signature de jeton d'identité, exécutez la commande suivante :

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

Sortie :

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

Manage token signing certificates

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

Available Commands:
  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
      --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 "error")
  -q, --quiet               suppress all output except for errors and warnings
      --timeout duration    timeout of the command (default 1h0m0s)

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

Important :

You can use a maximum key length of 4096 bits for signing certificates. We highly recommend you to use a key length of at least 512 bits (64 bytes) as a best practice.

The following section provide details on the operations you can perform using the uipathctl config token-signing-certificates command.

Automatic certificate rotation

Automatic certificate rotation means Automation Suite manages the lifecycle of signing keys. This includes rotating keys every 90 days, announcing new keys 14 days prior to rotation, retaining old keys for 14 days post-rotation, and then deleting them when the 14-day period ends.

If you're upgrading from an older version to 2024.10, automatic certificate rotation is disabled by default. To enable automatic key management, use the following command:

uipathctl config token-signing-certificates automatic-key-management enable

Important :

Enabling automatic certificate rotation may result in a downtime of up to one hour.

Automatic certificate rotation is enabled by default for clean Automation Suite installations. To disable automatic key management, use the following command:

uipathctl config token-signing-certificates automatic-key-management disable

If the automatic management feature is disabled, signing certificates need to be updated and rotated manually. For details on manual key management, see the documentation on manually updating and rotating the certificate.

Manually updating the certificate

Pour télécharger le nouveau certificat afin de signer le jeton, exécutez la commande suivante :

Remarque :

La commande suivante ne remplace pas le certificat de signature de jeton existant.

Assurez-vous que le certificat que vous fournissez est au format .pem .

The server.crt file must contain the entire chain, as shown in the following example:

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

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

Manually rotating the certificate

Pour faire pivoter ou remplacer l'ancien certificat par le nouveau, exécutez la commande suivante :

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

Remarque :

Il devrait y avoir un délai d'environ 24 à 48 heures entre la mise à jour du certificat et sa rotation.

Nous avons besoin de ce délai pour continuer à prendre en charge l'authentification pour le jeton mis en cache signé par l'ancien certificat.

Si vous effectuez la rotation du certificat trop tôt avant l'expiration du jeton de cache, cela peut entraîner des temps d'arrêt. Et vous devrez peut-être redémarrer tous vos robots.

Rotation des certificats d'urgence

Important : la procédure suivante concerne uniquement les urgences. Vous devez effectuer une rotation des certificats avant leur date d'expiration

Pour effectuer une mise à jour d'urgence du certificat, procédez comme suit :

1. Obtenez un nouveau certificat ou créez-en un auto-signé et copiez-le sur le nœud du serveur de cluster utilisé pour exécuter les étapes de rotation suivantes. Pour créer un certificat auto-signé, exécutez la commande suivante :

   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 a expiré, faites pivoter et mettez à jour le certificat. Pour obtenir des instructions, consultez la Gestion des certificats.
3. Si IdentityServer2.pfx a expiré, mettez à jour le certificat.
4. Si les deux certificats ont expiré, mettez à jour, faites pivoter et mettez à jour à nouveau.
5. Redémarrez tous les déploiements.
6. Effacez tous les caches du navigateur. Si vous exécutez en mode Incognito ou Privé, vous pouvez ignorer cette étape.
7. Pour Firefox, appuyez sur CTRL+MAJ+SUPPR, sélectionnez Cacheet cliquez sur OK.
   
   

   

   
   
8. Pour Chrome, appuyez sur CTRL+MAJ+SUPPR, sélectionnez Images et fichiers mis en cache (Cached images and files) et cliquez sur Effacer les données (Clear data).
   
   

   

   
   

Accéder au certificat

Exécutez la commande suivante pour télécharger le certificat de signature de jeton actuel :

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

Gestion des certificats RKE2

Par défaut, les certificats RKE2 expirent sous 12 mois. Au cours des 90 jours précédant leur date d’expiration, les certificats font l’objet d’une rotation lorsque vous redémarrez RKE2.

Pour plus de détails, consultez la section RKE2 - Options avancées - Rotation du certificat.

Vérification de la date d’expiration du certificat RKE2

Pour vérifier la date d’expiration du certificat RKE2, exécutez la commande suivante sur l’un des nœuds :

# 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

La sortie que vous obtenez doit être similaire à celle illustrée dans l’image suivante :

Rotation du certificat RKE2

Pour effectuer une rotation des certificats RKE2, vous devez d’abord exécuter une série d’actions sur les nœuds de serveur, puis poursuivre certaines étapes sur les nœuds d’agent.

Effectuez les étapes suivantes sur les nœuds de serveur :

1. Arrêtez le serveur RKE2 :

   systemctl stop rke2-server.service

2. Effacez tous les processus RKE2 restants :

   rke2-killall.sh

3. Supprimez le fichier dynamic-cert.json situé dans /var/lib/rancher/rke2/server/tls/.
4. Redémarrez le serveur RKE2 :

   systemctl start rke2-server.service

   Remarque : si le cluster comporte plusieurs nœuds de serveur, les étapes 1 à 4 peuvent ne pas s’exécuter entièrement car etcd peut ne pas permettre de finaliser l’élection du responsable. Si cela se produit, répétez les étapes 1 à 4 sur d’autres nœuds de serveur.
5. Supprimez la clé secrète rke2-serving de l’espace de noms kube-system :

   kubectl delete secret -n kube-system rke2-serving

   Remarque :

   Dans un déploiement multi-nœuds, vous ne pourrez peut-être pas exécuter les commandes kubectl tant que vous n’aurez pas effectué les quatre premières opérations sur le nombre nécessaire de nœuds de serveur. Cela permet de répondre à l’exigence de quorum etcd. Vous pouvez supprimer la clé secrète rke2-serving immédiatement après le démarrage du serveur RKE2.

Une fois que etcd atteint le quorum, le serveur RKE2 peut démarrer le reste des pods du plan de contrôle. Vous devriez alors voir l’exécution réussie de la commande kubectl get nodes. Lorsque vos nœuds de serveur sont prêts, vous pouvez passer aux nœuds d’agent pour régénérer les certificats.

Effectuez les étapes suivantes sur les nœuds d’agent :

1. Arrêtez le serveur RKE2 :

   systemctl stop rke2-agent.service

2. Effacez tous les processus RKE2 restants :

   rke2-killall.sh

3. Redémarrez le serveur RKE2 :

   systemctl start rke2-agent.service

Gestion du certificat de registre compatible OCI externe

Pour mettre à jour le certificat post-installation du registre compatible OCI externe, procédez comme suit :

1. Mettez à jour l'indicateur registry_ca_cert dans le fichier cluster_config.json . Pour plus de détails, consultez la section Configuration du registre externe compatible OCI.
2. Mettez à jour l'autorité de certification racine utilisée par le registre externe compatible OCI en exécutant la commande suivante sur tous les nœuds :

   ./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. Mettez à jour le certificat CA approuvé ArgoCD pour le registre externe compatible OCI :

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