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 :

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

Sortie :

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

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

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

Les sections suivantes décrivent les opérations que vous pouvez effectuer à l'aide de la commande ./configureUiPathAS.sh tls-cert .

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 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 le script configureUiPathAS.sh 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

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

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

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.

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

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 :

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

Sortie :

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

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

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

Les sections suivantes décrivent les opérations que vous pouvez effectuer à l'aide de la commande ./configureUiPathAS.sh additional-ca-certs .

Mise à jour des certificats CA

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

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

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 :

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

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é

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

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

Sortie :

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

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 section suivante fournit des détails sur les opérations que vous pouvez effectuer à l'aide de la commande./configureUiPathAS.sh identity token-cert .

Mise à jour 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 .

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

Rotation du certificat

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

sudo ./configureUiPathAS.sh identity token-cert 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 :

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

Gestion des certificats Rancher

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