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

Exécutez uipathctl pour mettre à jour le certificat comme indiqué ci-dessous. Vous avez besoin du chemin d'accès à chacun des trois fichiers de certificat. Tout le fichier de certificat doit être au format PEM .

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

  Le fichier server.crt doit contenir toute la chaîne, comme illustré dans l'exemple suivant :

  -----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 propose deux méthodes pour gérer la rotation des certificats de signature de jeton d'identité : automatique et manuelle.

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 :

Vous pouvez utiliser une longueur de clé maximale de 4096 bits pour la signature des certificats. Comme meilleure pratique, nous vous recommandons fortement d'utiliser une longueur de clé d'au moins 512 bits (64 octets).

La section suivante fournit des détails sur les opérations que vous pouvez effectuer à l'aide de la commande uipathctl config token-signing-certificates .

Rotation automatique des certificats

La rotation automatique des certificats signifie qu’Automation Suite gère le cycle de vie des clés de signature. Cela inclut la rotation des clés tous les 90 jours, l'annonce de nouvelles clés 14 jours avant la rotation, la conservation des anciennes clés pendant 14 jours après la rotation, puis la suppression de celles-ci lorsque la période de 14 jours se termine.

Si vous effectuez une mise à niveau à partir d'une ancienne version vers 2024.10, la rotation automatique des certificats est désactivée par défaut. Pour activer la gestion automatique des clés, utilisez la commande suivante :

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

Important :

L'activation de la rotation automatique des certificats peut entraîner un temps d'arrêt allant jusqu'à une heure.

La rotation automatique des certificats est activée par défaut pour les nouvelles installations d'Automation Suite. Pour désactiver la gestion automatique des clés, utilisez la commande suivante :

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

Si la fonctionnalité de gestion automatique est désactivée, les certificats de signature doivent être mis à jour et pivotés manuellement. Pour plus de détails sur la gestion manuelle des clés, consultez la documentation sur la mise à jour manuelle et la rotation du certificat.

Mise à jour manuelle du certificat

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 .

Le fichier server.crt doit contenir toute la chaîne, comme illustré dans l'exemple suivant :

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

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

Faire pivoter manuellement le certificat

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 :

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

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

Rotation du certificat 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. Cependant, si la validité des certificats dépasse la période de 90 jours, vous devez effectuer une rotation manuelle des certificats en suivant les étapes mentionnées dans RKE2 - Options avancées - Rotation du certificat.

Si vous souhaitez personnaliser la période d'expiration des certificats RKE2 pour répondre à des exigences particulières, vous pouvez le faire avant de redémarrer les services RKE2 pour les nœuds de serveur et d'agent.

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. Pour personnaliser la période d'expiration des certificats RKE2, utilisez la commande suivante. Sachez que cet exemple définit la période de validité sur 1 000 jours, mais vous pouvez modifier cette valeur en fonction de vos besoins.

   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. 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.
6. 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. Pour personnaliser la période d'expiration des certificats RKE2, utilisez la commande suivante. Sachez que cet exemple définit la période de validité sur 1 000 jours, mais vous pouvez modifier cette valeur en fonction de vos besoins.

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