Gestion des certificats

Remplacez les certificats auto-signés par des certificats signés par une autorité de certification et gérez le cycle de vie des certificats dans Automation Suite.

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

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

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

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 clés secrètes à 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 de plus amples informations, 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 clés secrètes à 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

Comment la chaîne de certificats est assemblage

Lorsque vous exécutez la commande uipathctl config tls-certificates update , uipathctl assemble la chaîne complète de certificats à partir de deux fichiers d’entrée distincts:

• server.crt - la chaîne de certificats de serveur public complète au format PEM: le certificat de serveur de feuille, suivi du ou des certificats CA intermédiaires et de l'autorité de certification racine qui forment le chemin de signature de ce certificat de feuille. Inclure uniquement les certificats qui font partie de la chaîne de signature réelle du certificat de la feuille - n'incluez pas les certificats frères, non liés, en double ou alternatifs.
• ca.crt : la chaîne CA complète, y compris tous les certificats intermédiaires et l'autorité de certification racine. Le fichier doit uniquement contenir les certificats utilisés pour signer le certificat du serveur TLS. Inclure tout ce qui entraînera un échec.

uipathctl fusionne ces fichiers au moment du runtime.

Pour mettre à jour le certificat, indiquez le chemin d’accès à chacun des trois fichiers de certificat. Tous les fichiers de certificat doivent être au format PEM .

• Ensemble d’autorité de certification : chaîne CA complète utilisée pour signer le certificat du serveur TLS. Incluez tous les certificats intermédiaires et l’autorité de certification racine. N'incluez pas le certificat de la feuille ou tout autre certificat non utilisé pour signer le certificat du serveur TLS, car l'inclusion de toute autre chose entraînera l'échec. La limite de la chaîne est de neuf certificats au maximum.
• Certificat de serveur : la chaîne complète de certificats de serveur public au format PEM, en commençant par le certificat de serveur de la feuille, suivi du ou des certificats CA intermédiaires et de l'autorité de certification racine. Incluez uniquement les certificats qui forment la chaîne de signature réelle du certificat de la feuille.
• Clé privée : clé privée du certificat du serveur.

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

Pour résoudre les erreurs de validation de certificat TLS, consultez la section Erreurs de validation de certificat TLS.

Les fichiers suivants sont 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.

Cette étape est requise lorsque votre environnement utilise une autorité de certification privée ou un certificat auto-signé qui n'est pas approuvé mondialement. Si l'autorité de certification privée n'est pas déjà présente dans le magasin approuvé de l'hôte Linux, les appels provenant des nœuds de l'hôte échouent avec des erreurs SSL. Si votre autorité de certification est déjà approuvée par l'hôte, vous pouvez ignorer cette étape.

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

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

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

Utilisez cette commande lorsque votre environnement repose sur une autorité de certification privée ou sur un certificat auto-signé. L'ajout du certificat CA permet aux services Automation Suite de communiquer en toute sécurité avec des composants externes qui utilisent des certificats signés par cette autorité de certification, tels que SQL Server, le magasin d'objets ou les serveurs SMTP.

Pour mettre à jour les certificats CA, procédez comme suit :

1. Mettez à jour le fichier cluster_config.json pour pointer vers le fichier avec additional_ca_certs Pour des détails, reportez-vous à Configuration du certificat.

2. Appliquez le manifeste :

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

   Cette commande peut échouer en générant des erreurs telles que :

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

   Quel que soit l'échec, passez à l'étape 3 pour redémarrer les déploiements et stabiliser l'environnement.

3. Redémarrez manuellement tous les déploiements et ensembles d'états dans l'espace de noms uipath :

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

Remarque :

Pour ajouter les anciens certificats, vous devez utiliser la commande get de la section Accéder aux certificats CA et les ajouter dans le fichier de certificat CA .pem que vous devez fournir dans le champ additional_ca_certs . 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.

Cette étape est requise lorsque votre environnement utilise une autorité de certification privée ou un certificat auto-signé qui n'est pas approuvé mondialement. Si l'autorité de certification privée n'est pas déjà présente dans le magasin approuvé de l'hôte Linux, les appels provenant des nœuds de l'hôte échouent avec des erreurs SSL. Si votre autorité de certification est déjà approuvée par l'hôte, vous pouvez ignorer cette étape.

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

Pour les environnements Windows, reportez-vous à ce guide sur l'installation des certificats racines approuvés.

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

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

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 la mise à niveau d'une ancienne version vers 2.2510, la rotation automatique des certificats est désactivée par défaut. Pour activer la gestion automatique des clés, exécutez la commande suivante:

./bin/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, exécutez la commande suivante:

./bin/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 des détails sur la gestion manuelle des clés, reportez-vous à la documentation sur la mise à jour et la rotation manuelles du certificat.

Mise à jour manuelle du certificat

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 l'ensemble de la chaîne, comme illustré dans l'exemple suivant:

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

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

./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 est destinée aux urgences uniquement. 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 section Rotation du certificat.

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. Pour obtenir des instructions, consultez la section Résolution des problèmes.

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+SHIFT+SUPPR, sélectionnez Cache, puis sélectionnez OK.

   

8. Pour Chrome, appuyez sur CTRL+MAJ+SUPPR, sélectionnez Images et fichiers mis en cache, puis sélectionnez Effacer les données.

   

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 des certificats.

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]