Securing Tanium Console, API, and Module Server access

Tanium as a Service (TaaS) uses Transport Layer Security (TLS) to secure the connections among Tanium Core Platform components. However, you cannot change the digital certificates and keys that TaaS uses for TLS communication.

Overview

Tanium user and module operations require connections to the Tanium Servers, Module Server, and Tanium module services. The Tanium Core Platform uses SSL/TLS certificates and keys to secure connections to the Tanium Server and Module Server (illustrated in Figure  2). For example, when you use Tanium™ Patch to deploy patches to endpoints, the Tanium Core Platform establishes connections in the following order:

  1. User system (browser or CLI) to the Tanium Server (Tanium Console or API)
  2. Tanium Server to Tanium Module Server
  3. Module Server to Patch service
  4. Patch service to Tanium Server

The Tanium Server and Module Server installers generate self-signed certificates. You can replace these with certificates issued by a commercial certificate authority (CA) or your enterprise CA. As a best practice to facilitate troubleshooting, use the self-signed certificates during initial installation and replace them with CA-issued certificates later. This practice enables you to separate potential installation issues from TLS connection issues. Using a CA-issued certificate is highly recommended for Tanium Console and API access but is optional for communication between the Tanium Server and Module Server.

Tanium Console and API access require user authentication through sign-in credentials, but not for securing the TLS connection.

For details about the Tanium™ Protocol that secures communication among the Tanium Servers, Zone Server, Zone Server Hub, and Tanium Clients, see Securing Tanium Server, Zone Server, and Tanium Client access. To manage the keys that the Tanium Protocol uses, see Tanium Console User Guide: Managing Tanium keys.

To install the Tanium Server or Module Server, see Tanium Appliance Deployment Guide or Tanium Core Platform Deployment Guide for Windows.

Tanium Console and API

Users access the Tanium Console or API on the Tanium Server to perform Tanium operations such as issuing questions or deploying actions. The console and API communicate over Hypertext Transfer Protocol Secure (HTTPS), which uses SSL/TLS certificates and keys to secure client-server connections. When a user accesses the Tanium Console or API, the user system is the client and the Tanium Server is the server. To secure the connection, the Tanium Server presents its SOAPServer.crt certificate to prove its identity to the client and uses its SOAPServer.key private key to complete the TLS handshake. For console or API access, clients do not have to prove their identity to secure the connection. Figure  2 illustrates these processes.

When you install the Tanium Server on a Tanium Appliance, it generates a self-signed SOAPServer.crt certificate. When you install the Tanium Server on a Windows server, you can choose between a self-signed certificate or (if one is available) a CA-issued certificate. If you use a self-signed certificate, users see a certificate validation error when they access the Tanium Console or API. The error occurs because the CA certificates on the user system cannot validate the self-signed certificate. The following figure shows an example of such an error when users try to connect from a browser to the Tanium Console.

Figure  1:  Certificate validation error

Even though browsers provide the option to access the Tanium Console despite the error, avoiding that option is a security best practice. Therefore, Tanium highly recommends that you replace the self-signed SOAPServer.crt certificate with a CA-issued certificate. If the Tanium Server is currently using a self-signed certificate, you can replace it at any time.

Module Server communication

When users use the Tanium Console or API to work with Tanium modules, the Tanium Server communicates with the Tanium Module Server, the Module Server accesses the Tanium module services that it hosts (such as Patch), and the module services communicate back with the Tanium Server (see Figure  2).

The Tanium Server and Module Server communicate over HTTPS, and both servers must prove their identities through certificates. The Tanium Server presents SOAPServer.crt to prove its identity, while the Module Server presents ssl.crt. The servers use the associated private keys (SOAPServer.key and ssl.key) to complete the TLS handshake that secures the connection. To verify the Tanium Server identity, the Module Server checks that its trusted.crt file contains the SOAPServer.crt that the Tanium Server presented. In an active-active deployment, trusted.crt must contain the SOAPServer.crt of both Tanium Servers. Tanium Servers also verify the Module Server identity by checking that their trusted‑module‑servers.crt file contains the ssl.crt that the Module Server presented. The Module Server registration process generates trusted.crt on the Module Server and trusted‑module‑servers.crt on the Tanium Server. The Module Server installation process generates ssl.crt.

The Module Server opens a single HTTPS listener to route requests from the Tanium Server to Tanium module services, which listen only on localhost. TLS termination occurs on the Module Server, which forwards the requests locally over non-TLS connections from the HTTPS listener to the appropriate module service.

Module services connect to the Tanium Server over TLS and verify that the certificate that the Tanium Server presented during the TLS handshake is included in the trusted.crt file on the Module Server. Because module services use the same API as Tanium Console users, client certificate validation is not enforced.

Optionally, you can use CA-issued certificates to replace the server-generated, self-signed SOAPServer.crt and ssl.crt certificates, but not the trusted.crt and trusted‑module‑servers.crt files. If you replace SOAPServer.crt or ssl.crt, you must re-register the Module Server with the Tanium Server to regenerate the trusted.crt and trusted‑module‑servers.crt files.

The following table summarizes the certificates and keys that the Tanium Core Platform uses for connections to the Module Server:

 Table 1: Certificates and keys for Module Server connections
Location File Name Purpose
Module Server ssl.crt
ssl.key
HTTPS certificate and private key that the Module Server presents to secure incoming connections from the Tanium Server or outgoing connections to Tanium services.
trusted.crt Contains the SOAPServer.crt of the Tanium Servers with which the Module Server has registered. The Module Server uses trusted.crt to validate Tanium Server certificates.
Tanium Server SOAPServer.crt
SOAPServer.key
HTTPS certificate and private key that the Tanium Server presents to secure outgoing connections to the Module Server or incoming connections from the systems of Tanium Console users or Tanium API users.
trusted-module-servers.crt
(Tanium Core Platform 7.2 or later)
Contains the ssl.crt of the Module Server that has registered with the Tanium Server. The Tanium Server uses trusted‑module‑servers.crt to validate the Module Server certificate.

SSL/TLS connection processes and setup tasks

The following figure illustrates the components, processes, and setup tasks involved in securing connections to the Tanium Server (Tanium Console or API) and Module Server.

Figure  2:  SSL/TLS connections

The following processes correspond to the numbers in Figure  2.

1 Tanium Console/API access

When a user system connects to the Tanium Console or API, the Tanium Server presents its SOAPServer.crt certificate to prove its identity to the user system. In Figure  2, the server uses a CA-issued version of SOAPServer.crt (Number 2) instead of a self-signed version. Therefore, the user system uses a CA certificate to validate SOAPServer.crt.

2 Replace self-signed certificate with CA-issued certificate

Generate a certificate signing request (CSR) and associated private key SOAPServer.key for the Tanium Server. You submit the CSR to your CA, which uses a CA certificate and associated private key to digitally sign the requested certificate (SOAPServer.crt). The CA signing certificate must also be present on the systems from which users access the Tanium Console or API (Number 1). The Tanium Server can then use the requested CA-issued certificate instead of a self-signed certificate. Optionally, you can also request a CA-issued certificate to replace the Module Server certificate (ssl.crt). For details, see CA-issued certificates.

3 Module Server registration

During a fresh installation of the Module Server, you must manually enable trust between it and the Tanium Server before registration. The Module Server then registers with the Tanium Server and the servers generate the trusted‑module‑servers.crt and trusted.crt files. For subsequent communication between the servers, including during version upgrades, manually enabling trust is unnecessary because the servers automatically check trusted‑module‑servers.crt and trusted.crt during their mutual identity verification (Number 4).

The installation procedures in the following deployment guides include steps to manually enable trust for the server certificates by verifying or entering certificate fingerprints (hash digests of certificate public keys): Tanium Appliance Deployment Guide: Installing Tanium Module Server and Tanium Core Platform Deployment Guide for Windows: Installing the Tanium Module Server.

4 Mutual identity verification

To establish a secure TLS connection, the Tanium Server and Module Server prove their identities to each other. During the TLS handshake, the Tanium Server presents its SOAPServer.crt certificate to the Module Server, which verifies that its trusted.crt file contains SOAPServer.crt. Also during the handshake, the Module Server presents its ssl.crt certificate to the Tanium Server, which verifies that its trusted‑module‑servers.crt file contains ssl.crt.

5 Module Server to Tanium module services

The Module Server opens a single HTTPS listener to route requests from the Tanium Server to Tanium module services, which listen only on localhost. The Module Server forwards the requests locally over non-TLS connections from the HTTPS listener to the appropriate module service.

6 Module services to the Tanium Server

Module services connect to the Tanium Server over TLS and verify that the certificate that the Tanium Server presented during the TLS handshake is included in the trusted.crt file on the Module Server. Because module services use the same API as Tanium Console users, client certificate validation is not enforced for this connection (in contrast with the connection described in Number 4).

CA-issued certificates

If your organization prefers to use CA-issued certificates to secure connections among systems, you can replace the self-signed certificates that the Tanium Server (SOAPServer.crt) and Module Server (ssl.crt) generated during installation. In an active-active deployment, you can use the same CA-issued SOAPServer.crt (and associated private key) for both Tanium Servers as long as the Subject Alternative Name in the certificate specifies both server names. Alternatively, you can use a distinct CA-issued certificate for each Tanium Server.

Obtaining a CA-issued certificate involves submitting a CSR to the CA and generating an associated private key. In a Windows deployment, use the Tanium™ KeyUtility program to generate the CSR and key locally (see Windows: Replace certificates). In a Tanium Appliance deployment, you must use a third-party tool such as OpenSSL (see Example: Create a CSR and private key with OpenSSL) to generate the CSR and key on a non-Appliance system and then copy them to the Appliance (see Tanium Appliance: Replace certificates).

The CA uses a CA certificate and its associated private key to digitally sign the certificate that you requested. If a CA-issued certificate replaces SOAPServer.crt on the Tanium Server, then the CA signing certificate must also be present on the systems from which users access the Tanium Console or API. For console users, the CA signing certificate must be in the trusted certificates store of their browsers. For API users, the CA signing certificate must be in the location specified in API calls, as shown in the ‑‑cacert <file path> option in the following example:

$ curl -s --cacert <file path> -X POST --data-binary @<sign in>.json https://localhost/api/v2/session/login

When you create the CSR, specify the options and X.509 attributes that ensure the CA returns a certificate that meets the following requirements.

Certificate requirements

Work with your CA to obtain a certificate with the following specifications for the Tanium Server or Module Server:

  • X.509 certificate with TLS Web Server Authentication and Client Authentication extended key usage

    CA certificate key usage

  • Separate certificate and private key files. You must remove the passphrase from the key file.
  • PEM format (Base64 encoded)
  • Certificate signed with a SHA-256 hashing algorithm
  • RSA 2048-bit key encryption
  • Common Name (CN) that specifies the fully qualified domain name (FQDN) or IP address of the server.

    CA certificate common name

  • Subject Alternative Name that specifies the FQDNs or IP addresses of both Tanium Servers in an active-active deployment where both servers use the same certificate. This is unnecessary if each server uses its own certificate.

    CA certificate subject alternative name

Example: Create a CSR and private key with OpenSSL

The following example shows how to use OpenSSL to create a CSR. You can use vendor-provided web forms or any tool you prefer, as long as the resulting certificate has the required attributes and a private key. This OpenSSL example uses a configuration file to pass X.509 attributes to the openssl command. You can specify command-line options instead of using a configuration file.

If you deploy the Tanium Server and Module Server on Windows infrastructure, the security best practice is to use the KeyUtility.exe program that is local to those servers instead of using a third-party tool to generate the CSR and private key. Generating the key locally enables you to avoid copying it between systems.

  1. Create a configuration file with the following content. Change the values in bold to ones that are appropriate for your servers.

    [req]

    distinguished_name = req_distinguished_name

    req_extensions = v3_req

    [req_distinguished_name]

    countryName = US

    countryName_default = US

    stateOrProvinceName = CA

    stateOrProvinceName_default = CA

    localityName = Emeryville

    localityName_default = Emeryville

    organizationName = IT

    organizationalUnitName = IT

    organizationalUnitName_default = IT

    commonName = server.domain.com

    commonName_max = 64

    [ v3_req ]

    # Extensions to add to a certificate request

    basicConstraints = CA:FALSE

    keyUsage = digitalSignature, keyEncipherment

    extendedKeyUsage = serverAuth,clientAuth

    subjectAltName = @alt_names

    [alt_names]

    DNS.1 = server1.domain.com

    DNS.2 = server2.domain.com

  2. Create a private key file to digitally sign the CSR:

    openssl genrsa -out tanium.key 2048

  3. Generate the CSR file. The following example specifies the configuration file and private key created in the previous steps:

    openssl req -sha256 -new -out SOAPServer.csr -key tanium.key -config tanium-openssl.cfg

  4. Open the generated file to confirm that the CSR was created. The following example shows a PEM-formatted CSR.
  5. -----BEGIN CERTIFICATE REQUEST-----
    MIIC9DCCAdwCAQAwUzELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAkNBMRMwEQYDVQQH DApFbWVyeXZpbGxlMQswCQYDVQQLDAJJVDEVMBMGA1UEAwwMdHMudGFtLmxvY2Fs MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApUekQ9Q2cdV4HejVI6KY +EgnUsZm2qbQUHoTsRjQV82BUdsybOqY7/I4haTCA5x0tZVPmBV358B6cIiOtWdV +dwp8UFX90iSAugYpop3KQ/Ke7ws4twZiyL+SVZyEwARpZM0aiqt4iExs5+Kw+F5 uOvNlhj7F+csu8Q4VzWF+QsgrgMnSsNawZxGPvV9LghaEyow3oP+lmRN2LVrmy82 tsmhml2+vOwipR4lyAkNXJS6nIf3BROXUxqFC0vgHDI2/ilX+2GM3MMGZNxPn5iC nxXzLm/yLTytWyLB/mb77Ts/Si8BenLzrZtEvsV+dqWKq6a428/iZD4FYp6+LMd4 gQIDAQABoFwwWgYJKoZIhvcNAQkOMU0wSzAJBgNVHRMEAjAAMAsGA1UdDwQEAwIF oDAxBgNVHREEKjAoghJzZXJ2ZXIxLmRvbWFpbi5jb22CEnNlcnZlcjIuZG9tYWlu LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAC4ki2mTKzmrSAv/xW3L8FnJ8cUEzmfex Q/7N+XKGszUesAToBtVG1EHY2gSdA7gTR/OfUxZUrPJTx7oHWb9L/UgNB6gHeI2R uxwUOmbTcaSjcwdeKH+N+vEEnubMt/RzTun4Qk+CgQLws/jbGOsmcV2KoPJ4/2QM oxpnCHKyjc3HYaCvbYvT7UbFk9hNNfpl0djqxm0LRAi0uQqt5T0WmzIjxsVXY4ay F5bhwdCTLQT+e7ERqFStblBdfkIzxGOexUG96iQR4R8noN4qp/iNRFUTTiJPZ9aN 84Ab494Q4BtYY2cIA2LWQfSrCVgzcXSdpPwDdb2w5b8p5wSA0/rdMw==
    -----END CERTIFICATE REQUEST-----

  6. Save the private key to a secure location and submit the CSR to the CA. The submission process varies by CA. In some cases, you submit a file; in other cases, you paste the contents of the file into an online form. In any case, be sure to communicate the certificate requirements to your CA.

    Use a secure protocol such as Secure Copy Protocol (SCP) or Secure File Transfer Protocol (SFTP) when you need to copy the private key between systems; do not use Server Message Block (SMB) or File Transfer Protocol (FTP). For security, after copying the key to the installation folder of the Tanium Core Platform server that requires key, delete any other instance of it.

Tanium Appliance: Replace certificates

Perform the following steps to replace the current SOAPServer.crt and SOAPServer.key on the Tanium Server with a new, CA-issued certificate and associated private key. In an active-active deployment, you can use the same certificate and key for both Tanium Servers as long as the Subject Alternative Name in the certificate specifies both server names.

If you need to replace the current ssl.crt and ssl.key on the Module Server with a new, CA-issued certificate and associated private key, contact Tanium Support at [email protected].

Obtain the new certificate and key

  1. Use a tool such as OpenSSL to generate a CSR and new private key. When creating the CSR, specify the certificate options and X.509 attributes described under Certificate requirements. For an example procedure, see Example: Create a CSR and private key with OpenSSL.
  2. Save the private key to a secure location on a system from which you can connect to the Tanium Servers through an SFTP client.

    When transferring the private key between systems, use a secure protocol such as SCP or SFTP; do not use SMB or FTP.

  3. Submit the CSR to the CA. The submission process varies by CA. In some cases, you submit a file; in other cases, you paste the file contents into an online form. In any case, be sure to communicate the certificate requirements to your CA.
  4. When the CA returns the new certificate, save it to the same location as the private key so that you can copy both files to the Tanium Servers.

Upload the new certificate and key

Upload the new, CA-issued certificate and associated private key to the Tanium Server. In an active-active deployment, perform these steps on each Tanium Server.

  1. In the location where you saved the new certificate and key, change their file names to those used in the Tanium Server installation: SOAPServer.crt and SOAPServer.key.
  2. Set up an SFTP client to connect to the Tanium Server.
  3. Use SFTP to copy the certificate and key files to the /incoming directory on the Tanium Server.

    After copying the key to the Tanium Server, delete any other instance of the key for security.

Install the new certificate and key

Install the new, CA-issued certificate and associated private key on the Tanium Server. In an active-active deployment, perform these steps on each Tanium Server. Because the steps include stopping and restarting the servers, perform this task during a maintenance window.

  1. Sign in to the TanOS console as a user with the tanadmin role.
  2. Enter 2 to go to the Tanium Operations menu. ClosedView screen
  3. Enter 4 to initiate the Install Custom SOAP Cert process. ClosedView screen
  4. Follow the prompts to install the certificate and key files that you uploaded:
    1. Enter YES at the prompt to proceed with the installation.

      The Appliance verifies that the files are valid and that the key matches the certificate.

    2. Enter Y at the prompt to create a backup of the files in the /outgoing directory of the tancopy user.

      The Tanium Appliance stops the Tanium Server service, installs the new certificate and key, and restarts the service.

    3. If the Appliances are in an array, the last step is to re-register the Module Server: enter yes at the prompt and enter the password of the Tanium Console admin user. Otherwise, perform the steps described in Re-register the remote Module Server with each Tanium Server.

Re-register the remote Module Server with each Tanium Server

After you replace the certificate and private key on the Tanium Server, re-register the Module Server. In an active-active deployment, you must re-register with each Tanium Server. Because the steps include stopping and restarting services, perform this task during a maintenance window.

  1. Repeat the remote Module Server configuration steps to update the certificates that are used to validate SOAPServer.crt and ssl.crt on each server: trusted.crt on the Module Server appliance and trusted-module-servers.crt on the Tanium Server appliance. See the Tanium Appliance Deployment Guide: Configure the Tanium Server to use the remote Module Server.
  2. Restart all Tanium services on the Module Server appliance. See Tanium Appliance Deployment Guide: Start, stop, and restart Tanium services.

Windows: Replace certificates

Perform the following steps to replace the current certificates and private keys used for connections to the Tanium Console, API, and Module Server with new, CA-issued certificates and associated private keys. In an active-active deployment, you can use the same certificate and key for both Tanium Servers as long as the Subject Alternative Name in the certificate specifies both server names.

The certificates and keys that the Tanium Server and Module Server use are not interchangeable. The Tanium Server uses the SOAPServer.crt certificate and SOAPServer.key key. The Module Server uses the ssl.crt certificate and ssl.key key.

Obtain the new certificate and key

Use the KeyUtility.exe program instead of a third-party tool to generate the CSR and private key on whichever server (Tanium Server or Module Server) needs them.

For better security, generate the key locally on the server to avoid copying it between systems.

  1. Sign in to the server that needs a new certificate and access the CLI as an administrator (see Windows).
  2. Navigate to the server installation folder.

    $ cd <Tanium/Module Server>

  3. Use the KeyUtility.exe program to generate a CSR and private key.

    The --hostname argument specifies the server FQDN or IP address. In an active-active deployment where both Tanium Servers use the same certificate and key, specify both Tanium Servers with a comma separator (ts1.example.com,ts2.example.com for example). Optionally, you can also generate a unique CSR and key for each Tanium Server.

    The --out argument specifies the output folder and files names of the CSR and key. The command automatically appends the suffix (.csr or .key) to the file name. Use the file name SOAPServer on the Tanium Server or ssl on the Module Server to avoid having to rename the files later. To avoid overwriting the current key, be sure to specify an output folder that is not the server installation folder.

    $ KeyUtility selfsign --export-csr --hostname <server FQDN/IP address> --out <output folder path><file name>

    The command creates three files in the specified output folder: <filename>.csr, <filename>.key, and <filename>.crt. The command automatically uses the key to sign <filename>.csr. The <filename>.crt file is a self-signed certificate that you use only if you do not need a CA-issued certificate.

  4. Submit the CSR to the CA. The submission process varies by CA. In some cases, you submit a file; in other cases, you paste the file contents into an online form. In any case, be sure to communicate the certificate requirements to your CA.
  5. When the CA returns the new certificate file, save it to a temporary location from where you can later copy the file to the installation folder of the Tanium Server or Module Server.

Update the Tanium Server certificate and key files

Because you must restart servers during this task, perform it during a maintenance window.

Update the Tanium Server certificate and key files in a standalone (non-HA) deployment

  1. On the Tanium Server, back up the existing SOAPServer.crt certificate and SOAPServer.key private key in case you later want to revert your changes.
  2. Stop the Tanium Server service: open the Windows Services application, right-click Tanium Server, and select Stop.
  3. Copy the new certificate and key files to the server installation folder to replace the existing files.

    For security, delete any instance of the key that is not in the installation folder after you copy the key there.

  4. Start the Tanium Server service: open the Windows Services application, right-click Tanium Server, and select Start.

    If you plan to update the Module Server certificates and keys, skip to Update the Module Server certificates and key files. Otherwise, perform the remaining steps.

  5. Sign in to the Module Server and re-register it with the Tanium Server to regenerate the trusted.crt and trusted‑module‑servers.crt files. You can re-register by re-running the Module Server installer (see Tanium Core Platform Deployment Guide for Windows: Installing the Tanium Module Server) or by using the Module Server CLI as follows. Specifying the port is necessary only if the Tanium Console does not use the standard port (443). Specify the user name and password of a Tanium Console administrator.

    cmd-prompt>TaniumModuleServer register <Tanium Server FQDN>:<port>
    Enter administrator username: <user name>
    Enter password for user '<user name>': <password>
    Successfully completed registration.

  6. On the Module Server, perform one of the following steps to restart the services for the Tanium Module Server and all Tanium solutions:
    • Reboot the Module Server. All the services automatically restart during the reboot process.
    • Open the Windows Services application and, for each Tanium service, right-click the service name and select Restart.

  7. Restart the Tanium Server service: on the Tanium Server, open the Windows Services application, right-click Tanium Server, and select Restart.

Update the Tanium Server certificate and key files in an active-active deployment

Perform these steps on one Tanium Server at a time. The steps in this example start on the primary Tanium Server.

  1. On the primary Tanium Server, back up the existing SOAPServer.crt certificate and SOAPServer.key private key in case you later want to revert your changes.
  2. Stop the Tanium Server service: open the Windows Services application, right-click Tanium Server, and select Stop.
  3. Copy the new certificate and key files to the server installation folder to replace the existing files.

    For security, delete any instance of the key that is not in the installation folder after you copy the key there.

  4. Start the Tanium Server service: open the Windows Services application, right-click Tanium Server, and select Start.
  5. On the secondary Tanium Server, stop the Tanium Server service.
  6. Replace the existing certificate and key in the installation folder of the secondary Tanium Server:

    • If each Tanium Server requires a unique certificate and key, copy the files from the temporary folder where you stored them.

    • If both Tanium Servers use the same certificate and key, copy the files from the primary Tanium Server.

    Use a secure protocol such as SCP or SFTP to copy the key between systems; do not use SMB or FTP.

  7. On the secondary Tanium Server, start the Tanium Server service.

    If you plan to update the Module Server certificates and keys, skip to Update the Module Server certificates and key files. Otherwise, perform the remaining steps.

  8. Sign in to the Module Server and re-register it with each Tanium Server to regenerate the trusted.crt and trusted‑module‑servers.crt files. You can re-register by re-running the Module Server installer (see Tanium Core Platform Deployment Guide for Windows: Installing the Tanium Module Server), but only for the primary Tanium Server. You can use the Module Server CLI as follows to re-register with either Tanium Server. Specifying the port is necessary only if the Tanium Console does not use the standard port (443). Specify the user name and password of a Tanium Console administrator.

    cmd-prompt>TaniumModuleServer register <Tanium Server FQDN>:<port>
    Enter administrator username: <user name>
    Enter password for user '<user name>': <password>
    Successfully completed registration.

  9. On the Module Server, perform one of the following steps to restart the services for the Tanium Module Server and all Tanium solutions:
    • Reboot the Module Server. All the services automatically restart during the reboot process.
    • Open the Windows Services application and, for each Tanium service, right-click the service name and select Restart.

  10. Restart the Tanium Server service: on each Tanium Server, open the Windows Services application, right-click Tanium Server, and select Restart.

Update the Module Server certificates and key files

Because this task involves stopping and starting the Module Server, perform the steps during a maintenance window.

The Tanium Server service must be running on each Tanium Server when you perform the step to re-register the Module Server.

  1. On the Module Server, back up the existing ssl.crt certificate and ssl.key private key in case you later want to revert your changes.
  2. Stop the services for the Tanium Module Server and all Tanium solutions (modules and shared services): open the Windows Services application and, for each service, right-click the service name and select Stop.
  3. Copy the new certificate and key files to the Module Server installation folder to replace the existing files.

    For security, delete any instance of the key that is not in the installation folder after you copy the key there.

  4. Re-register the Module Server with each Tanium Server to regenerate the trusted.crt and trusted‑module‑servers.crt files. You can re-register by re-running the Module Server installer, but only for the primary Tanium Server in an active-active deployment or for a standalone Tanium Server. You can use the Module Server CLI as follows to re-register with any Tanium Server in an active-active or standalone deployment. Specifying the port is necessary only if the Tanium Console does not use the standard port (443). Specify the user name and password of a Tanium Console administrator.

    cmd-prompt>TaniumModuleServer register <Tanium Server FQDN>:<port>
    Enter administrator username: <user name>
    Enter password for user '<user name>': <password>
    Successfully completed registration.

  5. On the Module Server, perform one of the following steps to restart the services for the Tanium Module Server and all Tanium solutions:
    • Reboot the Module Server. All the services automatically restart during the reboot process.
    • Open the Windows Services application and, for each Tanium service, right-click the service name and select Restart.

  6. Restart the Tanium Server service: on each Tanium Server, open the Windows Services application, right-click Tanium Server, and select Restart.