Why use custom certificates?

Not every installation of Tableau Server needs custom certificates, but for enterprises that need to follow regulated-industry compliance requirements (FIPS for example) the ability to use custom certificates in place of the self-signed certificates is crucial. These may also be necessary to resolve security scans that flag self-signed internal certificates. Your IT and security teams should tell you if you need to use custom certificates.

Services supporting custom certificates

The following internal services support custom certificates. Use the service name with the --name option of tsm security internal-cert set and tsm security internal-cert reset. To see the available service names, run tsm security internal-cert list without the --name option.

• Simple TLS (server certificate and key, with an optional chain):

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

• Mutual TLS (mTLS), which requires a client certificate and key in addition to the server certificate:

  activemqMTLS, coordinationService

  Note: The Coordination Service can also be configured with its own command if you choose to use a separate certificate for that. For more information, see (Optional) Configuring a separate custom certificate for the Coordination Service below.

In addition, tsm security internal-cert set-all orchestrates the following pre-existing subsystems:

• Repository SSL (PostgreSQL), TSM Controller SSL, and OpenSearch (Index and Search Server).

  When you use set-all, the server certificate is mapped to the node and service certificates, the client certificate is mapped to the ActiveMQ client and OpenSearch admin, and the chain is mapped to the OpenSearch CA.

Certificate requirements

The certificates and keys that you supply to these commands must meet the following requirements:

• Certificates must be PEM-encoded X.509 certificates. Private keys must be in PKCS#1 or PKCS#8 format.

• Key algorithms RSA and ECC (EC/ECDSA) are supported. DSA keys are rejected.

• Encrypted keys are supported. Use the --passphrase and --client-passphrase options to supply the passphrase.

• Supplying a chain file is optional, but most deployments require one. For a private or internal CA, the root CA must be included in the chain. The root CA can be omitted only if the certificate was issued by a well-known public CA that is already trusted by the JVM. The root CA should also be installed in the operating system and Java truststore on all nodes.

• Hostname verification: The TSM Controller certificate must include the controller node's fully qualified domain name (FQDN) as the common name (CN) or as a DNS Subject Alternative Name (SAN)—for example, DNS:<value returned by the Linux hostname command>. This alone satisfies validation. Other internal certificates do not validate hostnames at this time. To keep the certificate valid if the TSM Controller ever moves to a different node, issue the certificate with SANs that cover every node in the cluster that could run the controller, or use a wildcard SAN for the shared domain (for example, DNS:*.corp.example.com).

• Extended Key Usage (EKU): Do not set the EKU to serverAuth or clientAuth alone. You can either leave the EKU unset or set it to both values, but not to one individually.

The Tableau Server custom certificates feature introduces a number of new TSM CLI commands. These provide administrators with the ability to designate certificates that Tableau Server should use for communication between internal services. The new commands include a series of sub-commands under tsm security internal-cert, and a similar series of sub-commands under tsm security coordination-service-internal-cert that are specific to the Coordination Service.