Récupération d’un certificat personnalisé du service de coordination

Version : ajouté dans la version 2026.3.0.

Depuis la version 2026.3.0 de Tableau Server, les administrateurs de serveur ont la possibilité d’opter pour des certificats personnalisés au lieu des certificats auto-signés utilisés par Tableau Server.Si vous avez configuré Tableau Server pour utiliser des certificats personnalisés et que vous rencontrez ensuite des problèmes avec le service de coordination (par exemple en raison d’un certificat expiré, d’une non-concordance de clés ou d’une chaîne fournie par le client qui n’est plus valide), vous devez prendre des mesures particulières pour résoudre le problème sans qu’il y ait besoin d’une nouvelle installation de Tableau Server ni de restaurer une sauvegarde existante.Pour plus d’informations sur l’utilisation de certificats personnalisés pour la communication entre les services internes, consultez Configuration de certificats internes personnalisés pour Tableau Server.

Utilisez l’outil par nœud recover-coordination-service-cert pour remplacer le certificat mTLS et le matériel de clé du service de coordination (ZooKeeper) directement sur le disque.Vous devez appliquer la même paire certificat/clé serveur et client sur chaque nœud.

Conditions préalables

  • Vous devez exécuter l’outil sur un nœud Tableau Server existant, en tant que root ou en tant qu’utilisateur d’exécution Tableau sans privilèges.

  • Préparez une paire certificat serveur/clé et une paire certificat client/clé.Les fichiers de chaîne facultatifs et les phrases de passe pour les clés chiffrées sont pris en charge.

Récupération du certificat personnalisé

  1. Si vous ne possédez pas encore de certificat, générez une nouvelle paire auto-signée une seule fois, sur un seul nœud, et copiez les fichiers identiques sur chaque nœud.La paire doit refléter ce que TSM génère en interne (EC P-256, autosigné, CN=*) :

    openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -days 1825 -nodes -subj "/CN=*" -keyout server.key -out server.crt

    openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -days 1825 -nodes -subj "/CN=*" -keyout client.key -out client.crt

    Pour générer une clé chiffrée par phrase de passe, omettez -nodes.OpenSSL vous invite à saisir une phrase de passe, que vous transmettez ensuite à l’aide de l’option --server-passphrase ou --client-passphrase correspondante.

  2. Exécutez l’outil de récupération sur le premier nœud.Commencez par un nœud qui héberge le service de coordination afin que le quorum puisse se reformer :

    recover-coordination-service-cert --server-cert server.crt --server-key server.key --client-cert client.crt --client-key client.key [--server-chain <file.crt>] [--client-chain <file.crt>] [--server-passphrase <passphrase>] [--client-passphrase <passphrase>]

    L’outil prévalide les entrées avant d’arrêter quoi que ce soit : il confirme que le certificat peut être analysé au format X.509, que toute phrase de passe fournie déchiffre la clé et que le premier certificat de toute chaîne fournie est l’émetteur du certificat feuille.Il arrête ensuite les services locaux, met à jour la configuration et le magasin de clés de chaque service, et redémarre le plan de contrôle (ZooKeeper d’abord, puis l’agent d’administration, puis le reste).

  3. Exécutez exactement la même commande sur chaque nœud restant, en utilisant des fichiers de certificat et de clé identiques.Récupérez d’abord les nœuds qui hébergent le service de coordination, puis récupérez les nœuds restants.Le cluster n’est pas récupéré tant que l’outil n’a pas été exécuté sur chaque nœud — tout nœud contenant encore l’ancien magasin de clés ne le réintègre pas.

    Remarque : à ce stade, tsm status affiche les services métier dans un état d’erreur.Ce comportement est normal.L’outil applique les correctifs aux services mais les laisse arrêtés.La commande set de l’étape suivante les lance.

  4. Une fois chaque nœud terminé, exécutez la commande set suivante une seule fois depuis le contrôleur ou le nœud initial pour synchroniser la configuration persistante du service de coordination avec ce qui se trouve maintenant sur le disque :

    tsm security coordination-service-internal-cert set --server-cert server.crt --server-key server.key --client-cert client.crt --client-key client.key [--server-chain <file.crt>] [--client-chain <file.crt>] [--server-passphrase <passphrase>] [--client-passphrase <passphrase>]

    L’outil de récupération affiche cette commande pour vous, préremplie avec les chemins d’accès que vous avez transmis.Il vous rappelle d’ajouter à nouveau les options de phrase de passe, mais n’affiche jamais la valeur de la phrase de passe.La commande identical-certificate short-circuit synchronise la configuration et redémarre l’ensemble du cluster (y compris les services métier arrêtés), ce qui supprime l’état d’erreur.

Résolution des problèmes : chaque exécution écrit un journal structuré dans ${TABLEAU_SERVER_DATA_DIR}/logs/app-recover-coordination-service-cert.log.

Remarque : sous Windows, un wrapper équivalent, recover-coordination-service-cert.cmd, utilise les mêmes options et se comporte de la même manière.

Merci de vos commentaires !Avis correctement envoyé. Merci