Gestion des certificats

Important :

Le processus d'installation génère des certificats auto-signés en votre nom. Ces certificats expireront dans 90 jours et vous devrez les remplacer par des certificats signés par une autorité de certification (CA) approuvée dès que l'installation sera terminée. Si vous ne mettez pas à jour les certificats, l'installation cessera de fonctionner dans 90 jours.

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

Certificates are also stored in the UiPath namespace. This is applicable to every UiPath® product that needs certificate information to trust incoming calls. For details, see Understanding the container architecture related to certificates.

Installation hors ligne : comment trouver le certificat du serveur

In addition to the certificates required by online deployment, an offline deployment has two additional locations that use the same rootCA.crt and tls.crt: ArgoCD and Docker Registry. Certificates are then stored in both Docker and ArgoCD namespaces.

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

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é

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 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. If IdentityServer1.pfx is expired, rotate and update the certificate. For instructions, see Rotating the certificate.

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. Restart all deployments. For instructions, see Troubleshooting.

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 :

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

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