Pourquoi utiliser des certificats personnalisés ?

Toutes les installations Tableau Server ne nécessitent pas de certificats personnalisés, mais pour les entreprises qui doivent respecter les exigences de conformité propres aux secteurs réglementés (FIPS, par exemple), la possibilité d’utiliser des certificats personnalisés à la place des certificats auto-signés est cruciale.Ils peuvent également être nécessaires pour résoudre les alertes des analyses de sécurité qui signalent des certificats internes auto-signés.Vos équipes informatique et de sécurité doivent vous indiquer si vous devez utiliser des certificats personnalisés.

Services prenant en charge les certificats personnalisés

Les services internes suivants prennent en charge les certificats personnalisés.Utilisez le nom du service avec l’option --name de tsm security internal-cert set et tsm security internal-cert reset.Pour afficher les noms de service disponibles, exécutez tsm security internal-cert list sans l’option --name.

• TLS simple (certificat serveur et clé, avec une chaîne facultative) :

  apiGateway, gatewayInternal, hyper, jmx, thrift, tsigLogs, relationshipService, recommendationsService, vizportalMetadataApi et backgrounderMetadataApi

• TLS mutuel (mTLS), qui nécessite un certificat client et une clé en plus du certificat serveur :

  activemqMTLS, coordinationService

  Remarque : le service de coordination peut également être configuré avec sa propre commande si vous choisissez d’utiliser un certificat distinct à cet effet.Pour plus d’informations, consultez (Facultatif) Configuration d’un certificat personnalisé distinct pour le service de coordination ci-dessous.

De plus, tsm security internal-cert set-all orchestre les sous-systèmes préexistants suivants :

• SSL du référentiel (PostgreSQL), SSL du contrôleur TSM et OpenSearch (serveur d’indexation et de recherche).

  Lorsque vous utilisez set-all, le certificat serveur est associé aux certificats de nœud et de service, le certificat client est associé au client ActiveMQ et à l’administrateur OpenSearch, et la chaîne est associée à CA OpenSearch.

Exigences en matière de certificat

Les certificats et les clés que vous fournissez à ces commandes doivent répondre aux exigences suivantes :

• Les certificats doivent être des certificats X.509 codés au format PEM.Les clés privées doivent être au format PKCS#1 ou PKCS#8.

• Les algorithmes de clé RSA et ECC (EC/ECDSA) sont pris en charge.Les clés DSA sont rejetées.

• Les clés chiffrées sont prises en charge.Utilisez les options --passphrase et --client-passphrase pour fournir la phrase de passe.

• Fournir un fichier de chaîne est facultatif, mais la plupart des déploiements en requièrent un.Pour une autorité de certification privée ou interne, l’autorité de certification racine doit être incluse dans la chaîne.L’autorité de certification racine ne peut être omise que si le certificat a été émis par une autorité de certification publique bien connue et déjà approuvée par la JVM.L’autorité de certification racine doit également être installée dans le système d’exploitation et dans le magasin de confiance Java sur tous les nœuds.

• Vérification du nom d’hôte : le certificat du contrôleur TSM doit inclure le nom de domaine qualifié complet (FQDN) du nœud du contrôleur comme nom commun (CN) ou comme autre nom de l’objet (SAN) DNS — par exemple, DNS:<value returned by the Linux hostname command>.Cela suffit à lui seul pour la validation.Les autres certificats internes ne valident pas les noms d’hôte pour le moment.Pour que le certificat reste valide si le contrôleur TSM est déplacé vers un autre nœud, émettez le certificat avec des SAN couvrant chaque nœud du cluster susceptible d’exécuter le contrôleur, ou utilisez un SAN comportant un caractère générique pour le domaine partagé (par exemple, DNS:*.corp.example.com).

• Utilisation de clé étendue (EKU) : ne définissez pas le paramètre EKU uniquement sur serverAuth ou clientAuth.Vous pouvez soit laisser le paramètre EKU non défini, soit le définir sur les deux valeurs, mais pas sur l’une d’elles individuellement.

La fonctionnalité de certificats personnalisés dans Tableau Server introduit un certain nombre de nouvelles commandes d’interface en ligne de commande TSM.Ils permettent aux administrateurs de désigner les certificats que Tableau Server doit utiliser pour la communication entre les services internes.Les nouvelles commandes incluent une série de sous-commandes sous tsm security internal-cert et une série similaire de sous-commandes sous tsm security coordination-service-internal-cert, qui sont spécifiques au service de coordination.