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

Version : ajouté dans la version 2026.3.0.

À partir de la version 2026.3.0 de Tableau Server, les administrateurs de serveur ont la possibilité de remplacer les certificats auto-signés utilisés par Tableau Server par des certificats personnalisés. Si vous avez configuré Tableau Server pour utiliser des certificats personnalisés et que vous rencontrez des problèmes avec le service de coordination (par exemple en raison d’un certificat expiré, d’une incompatibilité de clé ou d’une chaîne fournie par le client qui n’est plus valide), vous devez prendre des mesures particulières pour régler le problème sans avoir à procéder à une nouvelle installation de Tableau Server ni à restaurer une sauvegarde existante. Pour plus d’informations sur l’utilisation de certificats personnalisés pour les communications de service internes, consultez Configuration de certificats internes personnalisés pour Tableau Server.

Utilisez l’outil recover-coordination-service-cert par nœud pour remplacer le certificat mTLS du service de coordination (ZooKeeper) ainsi que le matériel de clé directement sur le disque. Vous devez appliquer le même certificat/paire de clés 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 qu’utilisateur root ou en tant qu’utilisateur « Exécuter en tant qu’utilisateur Tableau non privilégié ».

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

Récupérer le certificat personnalisé

  1. Si vous n’avez pas encore de certificat, générez une nouvelle paire auto-signée une 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, auto-signé, 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 produire une clé chiffrée par phrase de passe, omettez -nodes. OpenSSL demande une phrase de passe, que vous transmettez ensuite avec l’option correspondante --server-passphrase ou --client-passphrase.

  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 rétablir :

    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 est 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. Il arrête ensuite les services locaux, corrige la configuration et le keystore de chaque service, puis redémarre le plan de contrôle (ZooKeeper d’abord, puis l’agent d’administration, puis les autres).

  3. Exécutez exactement la même commande sur chaque nœud restant, en utilisant exactement les mêmes fichiers de certificat et de clé. Récupérez d’abord les nœuds qui hébergent le service de coordination, puis récupérez les nœuds restants. Le groupement 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 keystore n’est pas reconnecté.

    Remarque : À ce stade, tsm status affiche les services métier dans un état d’erreur. C’est normal. L’outil corrige les services, mais les laisse arrêtés. À l’étape suivante, la commande set les redémarre.

  4. Une fois chaque nœud terminé, exécutez une fois la commande set suivante depuis le contrôleur ou le nœud initial, afin de 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 pré-remplit cette commande avec les chemins que vous avez déjà renseignés et l’imprime pour vous. Elle vous rappelle d’ajouter à nouveau les options de phrase de passe, mais en répète pas la valeur de la phrase de passe. Le raccourci que prend la commande lorsque les certificats sont identiques synchronise la configuration et ramène la sauvegarde de l’ensemble du groupement à l’état d’erreur, y compris les services métier arrêtés.

Résolution des problèmes : chaque exécution rédige 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, prend les mêmes options et se comporte de la même manière.

Merci de vos commentaires!Votre commentaire s été envoyé avec succès. Merci!