Appendix - Web Tier with Apache Example Deployment

This topic provides an end-to-end procedure that describes how to implement web tier in the example AWS reference architecture. The example configuration is composed of the following components:

  • AWS application load balancer
  • Apache proxy servers
  • Mellon authentication module
  • Okta IdP
  • SAML authentication

Note: The example web tier configuration presented in this section includes detailed procedures for deploying third party software and services. We've made a best effort to verify and document the procedures to enable the web tier scenario. However, the third-party software may change or your scenario may differ from the reference architecture described here. Please refer to third-party documentation for authoritative configuration details and support.

The Linux examples throughout this section show commands for RHEL-like distributions. Specifically the commands here have been developed with the Amazon Linux 2 distribution. If you are running the Ubuntu distribution, edit the commands accordingly.

Deploying the web tier in this example follows a stepwise configuration and verification procedure. The core web tier configuration consists of the following steps to enable HTTP between Tableau and the internet. Apache is run and configured for reverse proxy/load balancing behind the AWS application load balancer:

  1. Install Apache
  2. Configure reverse proxy to test connectivity to Tableau Server
  3. Configure load balancing on proxy
  4. Configure AWS application load balancer

After the web tier is set up and connectivity with Tableau is verified, configure authentication with an external provider.

Install Apache

Run the following procedure on both EC2 hosts (Proxy 1 and Proxy 2). If you are deploying in AWS according to the reference architecture example then you should have two availability zones and be running a single proxy server in each zone.

  1. Install Apache:

    sudo yum update -y
    sudo yum install -y httpd
  2. Configure to start Apache on reboot:

    sudo systemctl enable --now httpd

  3. Verify that the version of httpd you have installed includes proxy_hcheck_module:

    sudo httpd -M

    The proxy_hcheck_module is required. If your version of httpd does not include this module, then update to a version of httpd that does include it.

Configure proxy to test connectivity to Tableau Server

Run this procedure on one of the proxy hosts (Proxy 1). The purpose of this step is to verify connectivity between the internet to your proxy server to the Tableau Server in the private security group.

  1. Create a file called tableau.conf and add it to the /etc/httpd/conf.d directory.

    Copy the following code and specify the ProxyPass and ProxyPassReverse keys with the private IP address of Tableau Server Node 1.

    Important: The configuration shown below is not a secure and should not be used in production. This configuration should only be used during the installation process to verify end-to-end connectivity.

    For example, if the private IP address of Node 1 is 10.0.30.32, then the contents of the tableau.conf file would be:

    <VirtualHost *:80>
    ProxyPreserveHost On
    ProxyPass "/" "http://10.0.30.32:80/"
    ProxyPassReverse "/" "http://10.0.30.32:80/"
    </VirtualHost>
  2. Restart httpd:

    sudo systemctl restart httpd

Verification: Base topology configuration

You should be able to access the Tableau Server admin page by browsing to http://<proxy-public-IP-address>.

If the Tableau Server sign-in page does not load in your browser then follow these troubleshooting steps on the Proxy 1 host:

  • Stop and then start httpd as a first troubleshooting step.
  • Double-check the tableau.conf file. Verify that the Node 1 private IP is correct. Verify double-quotes and carefully review syntax.
  • Run the curl command on the reverse proxy server with Node 1 private IP address, for example, curl 10.0.1.90. If the shell does not return html, or if it returns html for the Apache test web page, then verify protocol/port configuration between the Public and Private security groups.
  • Run the curl command with Proxy 1 private IP address, for example, curl 10.0.0.163. If the shell returns the html code for the Apache test web page, then the proxy file is not configured correctly.
  • Always restart httpd (sudo systemctl restart httpd) after any configuration change to the proxy file or to the security groups.
  • Make sure TSM is running on Node 1.

Configure load balancing on proxy

  1. On the same proxy host (Proxy 1) where you created the tableau.conf file, remove the existing Virtual Host configuration and edit the file to include load-balancing logic.

    For example:

    <VirtualHost *:80>
    ServerAdmin admin@example.com
    #Load balancing logic.
    ProxyHCExpr ok234 {%{REQUEST_STATUS} =~ /^[234]/}
    Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/" env=BALANCER_ROUTE_CHANGED 
    <Proxy balancer://tableau>
    #Replace IP addresses below with the IP addresses to the Tableau Servers running the Gateway service.
    BalancerMember http://10.0.3.40/ route=1 hcmethod=GET hcexpr=ok234 hcuri=/favicon.ico
    BalancerMember http://10.0.4.151/ route=2 hcmethod=GET hcexpr=ok234 hcuri=/favicon.ico
    ProxySet stickysession=ROUTEID
    </Proxy>
    ProxyPreserveHost On
    ProxyPass / balancer://tableau/
    ProxyPassReverse / balancer://tableau/ 
    </VirtualHost>
  2. Stop and then start httpd:

    sudo systemctl stop httpd
    sudo systemctl start httpd
  3. Verify the configuration by browsing to the public IP address of Proxy 1.

Copy configuration to second proxy server

  1. Copy the tableau.conf file from Proxy 1 and save it to the /etc/httpd/conf.d directory on Proxy 2 host.
  2. Stop and then start httpd:

    sudo systemctl stop httpd
    sudo systemctl start httpd
  3. Verify the configuration by browsing to the public IP address of Proxy 2.

Configure AWS application load balancer

Configure the load balancer as an HTTP listener. The procedure here describes how to add a load balancer in AWS.

Step 1: Create target group

A target group is an AWS configuration that defines the EC2 instances running your proxy servers. These are the targets for traffic from the LBS.

  1. EC2>Target groups > Create target group

  2. On Create page:

    • Enter a target group name, for example TG-internal-HTTP
    • Target type: Instances
    • Protocol: HTTP
    • Port: 80
    • VPC: Select your VPC
    • Under Health checks > Advanced health checks settings > Success codes, append the code list to read: 200,303.
    • Click Create
  3. Select the target group that you just created, and then click the Targets tab: 

    • Click Edit.
    • Select the EC2 instances (or single instance if you are configuring one at a time) that are running proxy application, and then click Add to registered.
    • Click Save.

Step 2: Launch load balancer wizard

  1. EC2> Load Balancers > Create Load Balancer

  2. On "Select load balancer type" page, create an Application Load Balancer.

Note: The UI that is displayed to configure load balancer is not consistent across AWS datacenters. The procedure below, "Wizard configuration," maps to the AWS configuration wizard that begins with Step 1 Configure Load Balancer

If your datacenter displays all configurations in a single page that includes a Create load balancer button at the bottom of the page, then follow the "Single page configuration" procedure below.

  1. Configure load balancer page:

    • Specify name
    • Scheme: internet-facing (default)
    • IP address type: ipv4 (default)
    • Listeners (Listeners and routing):
      1. Leave the default HTTP listener
      2. Click Add listener and add HTTPS:443
    • VPC: select the VPC where you've installed everything
    • Availability Zones:
      • Select the a and b for your datacenter regions
      • In each corresponding drop-down selector, select the Public subnet (where your proxy servers reside).
    • Click: Configure Security Settings
  2. Configure Security Settings page

    • Upload your public SSL certificate.
    • Click Next: Configure Security Groups.
  3. Configure Security Groups page:

    • Select the Public security group. If the Default security group is selected, then clear that selection.
    • Click Next: Configure Routing.
  4. Configure Routing page

    • Target group: Existing target group.
    • Name: Select target group that you created earlier
    • Click Next: Register Targets.
  5. Register Targets page

    • The two proxy server instances that you configured previously should be displayed.
    • Click Next: Review.
  6. Review page

    Click Create.

Basic configuration

  • Specify name
  • Scheme: internet-facing (default)
  • IP address type: ipv4 (default)

Network mapping

  • VPC: select the VPC where you've installed everything
  • Mappings:
    • Select the a and b (or comparable) Availability Zones for your datacenter regions
    • In each corresponding drop-down selector, select the Public subnet (where your proxy servers reside).

Security groups

  • Select the Public security group. If the Default security group is selected, then clear that selection.
  • Listeners and routing

    • Leave the default HTTP listener. For Default action, specify the Target Group that you previously set up.
    • Click Add listener and add HTTPS:443. For Default action, specify the Target Group that you previously set up.

    Secure listener settings

    • Upload your public SSL certificate.

    Click Create load balancer.

    Step 3: Enable stickiness

    1. After the load balancer is created, you must enable stickiness on the Target Group.

      • Open AWS Target Group page (EC2> Load Balancing> Target groups), select the target group instance that you just set up. On the Action menu, select Edit attributes.
      • On the Edit attributes page, select Stickiness, specify a duration of 1 day, and then Save changes.
    2. On load balancer, enable stickiness on the HTTP listener. Select the load balancer you just configured, and then click the Listeners tab:

      • For HTTP:80, click View/edit rules. On the resulting Rules page, click the edit icon (once at the top of the page, and then again by the rule) to edit the rule. Delete the existing THEN rule and replace it by clicking Add action > Forward to.... In the resulting THEN configuration, specify the same target group you have created. Under Group-level stickiness, enable stickiness and set duration to 1 day. Save the setting and then click Update.

    Step 4: Set idle timeout on load balancer

    On load balancer, update idle timeout to 400 seconds.

    Select the load balancer you have configured for this deployment, and then click Actions > Edit attributes. Set Idle timeout to 400 seconds, and then click Save.

    Step 5: Verify LBS connectivity

    Open AWS Load Balancer page (EC2> Load Balancers), select the load balancer instance that you just set up.

    Under Description, copy the DNS name and paste it into a browser to access the Tableau Server sign in page.

    If you get a 500-level error, then you may need to restart your proxy servers.

    Update DNS with public Tableau URL

    Use your domain DNS zone name from the AWS Load Balancer description to create a CNAME value in your DNS. Traffic to your URL (tableau.example.com) should be sent to the AWS public DNS name.

    Verify connectivity

    After your DNS updates are finished, you should be able to navigate to the Tableau Server sign-in page by entering your public URL, for example, https://tableau.example.com.

    Example authentication configuration: SAML with external IdP

    The following example describes how to setup and configure SAML with Okta IdP and Mellon authentication module for a Tableau deployment running in the AWS reference architecture. The example describes how to configure Tableau Server and the Apache proxy servers to use HTTP. Okta will send request to the AWS load balancer over HTTPS, but all internal traffic will travel over HTTP. As you configure for this scenario, be aware of the HTTP vs HTTPS protocols when setting URL strings.

    This example uses Mellon as a pre-authentication service provider module on the reverse proxy servers. This configuration ensures that only authenticated traffic connects to Tableau Server, which also acts as a service provider with the Okta IdP. Therefore, you must configure two IdP applications: one for the Mellon service provider and one for the Tableau service provider.

    Create Tableau administrator account

    A common mistake when configuring SAML is to forget to create an administrator account on Tableau Server before enabling SSO.

    The first step is to create an account on Tableau Server with a Server Administrator role. For the example Okta scenario, the username must be in a valid email address format, for example, user@example.com. You must set a password for this user, but the password will not be used after SAML is configured.

    Configure Okta pre-auth application

    The end-to-end scenario described in this section requires two Okta applications:

    • Okta pre-auth application
    • Okta Tableau Server application

    Each of these applications are associated with different metadata that you will need to configure on the reverse proxy and Tableau Server, respectively.

    This procedure describes how to create and configure the Okta pre-auth application. Later in this topic you will create the Okta Tableau Server application. For a free test Okta account with limited users, see the Okta Developer web page(Link opens in a new window).

    Create a SAML app integration for the Mellon pre-authentication service provider.

    1. Open the Okta administration dashboard > Applications Create App Integration.

    2. On Create a new app integration page, select SAML 2.0 and then click Next.

    3. On the General Settings tab, enter an App name, for example Tableau Pre-Auth, and then click Next.

    4. On the Configure SAML tab:

      • Single sign on (SSO) URL. The final element of the path in the single sign on URL is referred to as the MellonEndpointPath in the mellon.conf configuration file that follows later in this procedure. You can specify whatever endpoint you would like. In this example, sso is the endpoint. The last element, postResponse, is required: https://tableau.example.com/sso/postResponse.
      • Clear the checkbox: Use this for Recipient URL and Destination URL.
      • Recipient URL: Same as SSO URL, but with HTTP. For example, http://tableau.example.com/sso/postResponse.
      • Destination URL: same as SSO URL, but with HTTP. For example, http://tableau.example.com/sso/postResponse.
      • Audience URI (SP Entity ID). For example, https://tableau.example.com.
      • Name ID format: EmailAddress
      • Application username: Email
      • Attributes Statements: Name = mail; Name format = Unspecified; Value = user.email.

      Click Next.

    5. On the Feedback tab, select:

      • I'm an Okta customer adding an internal app
      • This is an internal app that we have created
      • Click Finish.
    6. Create the pre-auth IdP metadata file:

      • In Okta: Applications > Applications > Your new application (e.g., Tableau Pre-Auth) > Sign On
      • Adjacent to SAML Signing Certificates, click View SAML setup instructions.
      • On the How to Configure SAML 2.0 for <pre-auth> Application, page, scroll down to Optional section, Provide the following IDP metadata to your SP provider.
      • Copy the contents of the XML field and save them in a file called pre-auth_idp_metadata.xml.
    7. (Optional) Configure multifactor authentication:

      • In Okta: Applications > Applications > Your new application (e.g., Tableau Pre-Auth) > Sign On
      • Under Sign On Policy, click Add Rule.
      • On the App Sign On Rule, specify a name and the different MFA options. To test functionality, you can leave all options as default. However, under Actions, you must select, Prompt for factor, and then specify how often users must sign in. Click Save.

    Create and assign Okta user

    1. In Okta, create a user with the same username that you created in Tableau (user@example.com): Directory > People > Add person.
    2. After the user is created, assign the new Okta app to that person: Click the user name then assign the application in Assign Application.

    Install Mellon for pre-auth

    1. On the EC2 instances that are running the Apache proxy server, run the following commands to install PHP and Mellon modules:

      sudo yum install httpd php mod_auth_mellon

    2. Create the /etc/httpd/mellon directory

    Configure Mellon as pre-auth module

    Run this procedure on both proxy servers.

    You must have a copy of pre-auth_idp_metadata.xml file that you created from the Okta configuration.

    1. Change directory:

      cd /etc/httpd/mellon

    2. Create the service provider metadata. Run the mellon_create_metadata.sh script. You must include the entity ID and the return URL for your organization in the command.

      The return URL is referred to as the single sign on URL in Okta. The final element of the path in the return URL is referred to as the MellonEndpointPath in the mellon.conf configuration file that follows later in this procedure. In this example, we specify sso as the endpoint path.

      For example:

      sudo /usr/libexec/mod_auth_mellon/mellon_create_metadata.sh https://tableau.example.com "https://tableau.example.com/sso"

      The script returns the service provider certificate, key, and metadata files.

    3. Rename the service provider files in the mellon directory for easier readability. We will refer to these files by the following names in the documentation:

      sudo mv *.key mellon.key
      sudo mv *.cert mellon.cert
      sudo mv *.xml sp_metadata.xml

    4. Copy the pre-auth_idp_metadata.xml file to the same directory.

    5. Create the mellon.conf file in the /etc/httpd/conf.d directory:

      sudo nano /etc/httpd/conf.d/mellon.conf

    6. Copy the following contents into mellon.conf.

      <Location />
      MellonSPPrivateKeyFile /etc/httpd/mellon/mellon.key
      MellonSPCertFile /etc/httpd/mellon/mellon.cert
      MellonSPMetadataFile /etc/httpd/mellon/sp_metadata.xml
      MellonIdPMetadataFile /etc/httpd/mellon/pre-auth_idp_metadata.xml
      MellonEndpointPath /sso
      MellonEnable "info"
      </Location>
    7. Add the following contents into the existing tableau.conf file:

      Inside the <VirtualHost *:80> block, add the following content. Update ServerName with the public host name in your Entity ID:

      DocumentRoot /var/www/html
      ServerName tableau.example.com
      ServerSignature Off
      ErrorLog logs/error_sp.log
      CustomLog logs/access_sp.log combined
      LogLevel info 

      Add the Location block outside of the <VirtualHost *:80> block. Update MellonCookieDomain with the top-level domain to preserve cookie information as shown:

      <Location />
      AuthType Mellon
      MellonEnable auth
      Require valid-user
      MellonCookieDomain example.com					
      </Location>

      The complete tableau.conf file should look like the following example:

      <VirtualHost *:80>
      ServerAdmin admin@example.com
      ProxyHCExpr ok234 {%{REQUEST_STATUS} =~ /^[234]/}
      Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/" env=BALANCER_ROUTE_CHANGED
      <Proxy balancer://tableau>
      BalancerMember http://10.0.3.36/ route=1 hcmethod=GET hcexpr=ok234 hcuri=/favicon.ico
      BalancerMember http://10.0.4.15/ route=2 hcmethod=GET hcexpr=ok234 hcuri=/favicon.ico
      ProxySet stickysession=ROUTEID
      </Proxy>
      ProxyPreserveHost On
      ProxyPass / balancer://tableau/
      ProxyPassReverse / balancer://tableau/
      DocumentRoot /var/www/html
      ServerName tableau.example.com
      ServerSignature Off
      ErrorLog logs/error_sp.log
      CustomLog logs/access_sp.log combined
      LogLevel info 
      </VirtualHost>
      <Location />
      AuthType Mellon
      MellonEnable auth
      Require valid-user
      MellonCookieDomain example.com
      </Location>
    8. Verify the configuration. Run the following command:

      sudo apachectl configtest

      If the configuration test returns an error, fix any errors and run configtest again. A successful configuration will return, Syntax OK.

    9. Restart httpd:

      sudo systemctl restart httpd

    Create Tableau Server application in Okta

    1. In Okta dashboard: Applications > Applications > Browse App Catalog
    2. In Browse App Integration Catalog, search Tableau, select the Tableau Server tile, and then click Add.
    3. On Add Tableau Server > General Settings, enter a Label, and then click Next.
    4. In Sign-On Options, select SAML 2.0, and then scroll down to Advanced Sign-on Settings:
      • SAML Entity ID: enter the public URL, for example, https://tableau.example.com.
      • Application user name format: Email
    5. Click the Identity Provider metadata link, to launch a browser. Copy the browser link. This is the link you will use when you configure Tableau in the procedure that follows.
    6. Click Done.
    7. Assign the new Tableau Server Okta app to your user (user@example.com): Click the user name then assign the application in Assign Application.

    Enable SAML on Tableau Server for IdP

    Run this procedure on Tableau Server Node 1.

    1. Download the Tableau Server application metadata from Okta. Use the link that you saved from the previous procedure:

      wget https://dev-66144217.okta.com/app/exk1egxgt1fhjkSeS5d7/sso/saml/metadata -O idp_metadata.xml

    2. Copy a TLS certificate and related key file to the Tableau Server. The key file must be an RSA key. For more information about SAML certificate and IdP requirements, see SAML Requirements (Linux(Link opens in a new window)).

      To simplify certificate management and deployment, and as a security best practice, we recommend using certificates generated by a major trusted-third party certificate authority (CA). Alternatively, you may generate self-signed certificates or use certificates from a PKI for TLS.

      If you do not have a TLS certificate, you can generate a self-signed certificate using the embedded procedure below.

      Generate a self-signed certificate

      Run this procedure onTableau Server Node 1.

      1. Generate signing root certificate authority (CA) key:

        openssl genrsa -out rootCAKey-saml.pem 2048

      2. Create the root CA certificate:

        openssl req -x509 -sha256 -new -nodes -key rootCAKey-saml.pem -days 3650 -out rootCACert-saml.pem

        You will be prompted to enter values for the certificate fields. For example:

        Country Name (2 letter code) [XX]:US
        State or Province Name (full name) []:Washington
        Locality Name (eg, city) [Default City]:Seattle
        Organization Name (eg, company) [Default Company Ltd]:Tableau
        Organizational Unit Name (eg, section) []:Operations
        Common Name (eg, your name or your server's hostname) []:tableau.example.com
        Email Address []:example@tableau.com
      3. Create the certificate and related key (server-saml.csrand server-saml.key in the example below). The subject name for the certificate must match the public host name of the Tableau host. The subject name is set with the -subj option with the format "/CN=<host-name>", for example:

        openssl req -new -nodes -text -out server-saml.csr -keyout server-saml.key -subj "/CN=tableau.example.com"

      4. Sign the new certificate with the CA certificate that you created above. The following command also outputs the certificate in the crt format:

        openssl x509 -req -in server-saml.csr -days 3650 -CA rootCACert-saml.pem -CAkey rootCAKey-saml.pem -CAcreateserial -out server-saml.crt

      5. Convert the key file to RSA. Tableau requires an RSA key file for SAML. To convert the key, run the following command:

        openssl rsa -in server-saml.key -out server-saml-rsa.key

    3. Configure SAML. Run the following command, specifying your entity ID and return URL, and the paths to the metadata file, certificate file, and key file:

      tsm authentication saml configure --idp-entity-id "https://tableau.example.com" --idp-return-url "https://tableau.example.com" --idp-metadata idp_metadata.xml --cert-file "server-saml.crt" --key-file "server-saml-rsa.key"

      tsm authentication saml enable

    4. If your organization is running Tableau Desktop 2021.4 or later, then you must run the following command to enable authentication through the reverse proxy servers.

      Versions of Tableau Desktop 2021.2.1 - 2021.3 will work without running this command, provided that your pre-authentication module (e.g., Mellon) is configured to allow top-level domain cookie preservation.

      tsm configuration set -k features.ExternalBrowserOAuth -v false

    5. Apply configuration changes:

      tsm pending-changes apply

    Validate SAML functionality

    To validate end-to-end SAML functionality, sign-in to Tableau Server with the public URL (e.g., https://tableau.example.com) with the Tableau admin account that you created at the beginning of this procedure.

    Validation troubleshooting

    Bad Request: A common error for this scenario is a "Bad Request" error from Okta. Often this issue occurs when the browser is caching data from previous Okta session. For example, if you manage the Okta applications as an Okta administrator and then attempt to access Tableau using a different Okta-enabled account, session data from the administrator data may cause the "Bad Request" error. If this error persists even after you clear the local browser cache, try validating the Tableau scenario by connecting with a different browser.

    Another cause of the "Bad Request" error is a typo in one of the many URLs that you enter during the Okta, Mellon, and SAML configuration processes. Check all of these carefully.

    Often the httpd error.log file on the Apache server will specify which URL is causing the error.

    Not Found - The requested URL was not found on this server: This error indicates one of many configuration errors.

    If the user is authenticated with Okta, and then receives this error, then it's likely that you have uploaded the Okta pre-auth application to Tableau Server when you configured SAML. Verify that you have the Okta Tableau Server application metadata configured on Tableau Server, and not the Okta pre-auth application metadata

    Other troubleshooting steps:

    • Review tableau.conf carefully for typos or configuration errors
    • Review the Okta pre-auth application settings. Be sure HTTP vs HTTPS protocols are set as specified in this topic.
    • Restart httpd on both proxy servers.
    • Verify that sudo apachectl configtest returns “Syntax OK” on both proxy servers.
    • Verify that the test user is assigned to both applications in Okta.
    • Verify that stickiess is set on the load balancer and associated target groups

    Configure SSL/TLS from load balancer to Tableau Server

    Some organizations require end-to-end encryption channel from the client to the back end service. The default reference architecture as described to this point specifies SSL from the client to the load balancer running in the web tier of your organization.

    To configure SSL from the load balancer to Tableau Server, you must:

    • Install a valid SSL certificate on both the Tableau and proxy servers.
    • Configure SSL from the load balancer to the reverse proxy servers.
    • Configure SSL from the proxy servers to Tableau Server.
    • You may also configure SSL from Tableau Server to the PostgreSQL instance.

    The remainder of this topic describes this implementation in the context of the example AWS example reference architecture.

    Example: Configure SSL/TLS in AWS reference architecture

    This section describes how to configure SSL on Tableau and configure SSL on an Apache proxy server, all running in the example AWS reference architecture.

    The Linux procedures throughout this example show commands for RHEL-like distributions. Specifically the commands here have been developed with the Amazon Linux 2 distribution. If you are running the Ubuntu distribution, edit the commands accordingly.

    To simplify certificate management and deployment, and as a security best practice, we recommend using certificates generated by a major trusted-third party certificate authority (CA).

    Alternatively, you may generate self-signed certificates or use certificates from a PKI for TLS.

    The following procedure how to generate self-signed certificates. If you are using 3rd party certificates as we recommend, then you can skip this procedure.

    Run this procedure on one of the proxy hosts. After you generate the certificate and associated key, you will share it to the other proxy host and to Tableau Server Node 1.

    1. Generate signing root certificate authority (CA) key:

      openssl genrsa -out rootCAKey.pem 2048

    2. Create the root CA certificate:

      openssl req -x509 -sha256 -new -nodes -key rootCAKey.pem -days 3650 -out rootCACert.pem

      You will be prompted to enter values for the certificate fields. For example:

      Country Name (2 letter code) [XX]:US
      State or Province Name (full name) []:Washington
      Locality Name (eg, city) [Default City]:Seattle
      Organization Name (eg, company) [Default Company Ltd]:Tableau
      Organizational Unit Name (eg, section) []:Operations
      Common Name (eg, your name or your server's hostname) []:tableau.example.com
      Email Address []:example@tableau.com
    3. Create the certificate and related key (serverssl.csrand serverssl.key in the example below). The subject name for the certificate must match the public host name of the Tableau host. The subject name is set with the -subj option with the format "/CN=<host-name>", for example:

      openssl req -new -nodes -text -out serverssl.csr -keyout serverssl.key -subj "/CN=tableau.example.com"

    4. Sign the new certificate with the CA certificate that you created in step 2. The following command also outputs the certificate in the crt format:

      openssl x509 -req -in serverssl.csr -days 3650 -CA rootCACert.pem -CAkey rootCAKey.pem -CAcreateserial -out serverssl.crt

    Step 2: Configure proxy server for SSL

    Run this procedure on both proxy servers.

    1. Install the Apache ssl module:

      sudo yum install mod_ssl

    2. Create the /etc/ssl/private directory:

      sudo mkdir -p /etc/ssl/private

    3. Copy the crt and key files to the following /etc/ssl/ paths:

      sudo cp serverssl.crt /etc/ssl/certs/

      sudo cp serverssl.key /etc/ssl/private/

    4. Update the existing tableau.conf with the following updates:

      • Add the SSL rewrite block:
        RewriteEngine on
        RewriteCond %{SERVER_NAME} =tableau.example.com
        RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
      • In the SSL rewrite block, update the RewriteCond server name: add your public host name, for example, tableau.example.com
      • Change <VirtualHost *:80> to <VirtualHost *:443>.
      • Wrap the <VirtualHost *:443> and the <Location /> blocks with <IfModule mod_ssl.c> ... </IfModule>.
      • BalancerMember: change the protocol from http to https.
      • Add SSL* elements inside the <VirtualHost *:443> block:
        SSLEngine on
        SSLCertificateFile /etc/ssl/certs/serverssl.crt
        SSLCertificateKeyFile /etc/ssl/private/serverssl.key
        SSLProxyEngine on
        SSLProxyVerify none
        SSLProxyCheckPeerName off
        SSLProxyCheckPeerExpire off
      • In the LogLevel element: add ssl:warn.
      • Optional: If you have installed and configured an authentication module, then you may have additional elements in the tableau.conf file. For example, the <Location /> </Location> block will include elements.

      An example tableau.conf file configured for SSL is shown here:

      RewriteEngine on
      RewriteCond %{SERVER_NAME} =tableau.example.com
      RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
      
      <IfModule mod_ssl.c>
      <VirtualHost *:443>
      ServerAdmin admin@example.com
      ProxyHCExpr ok234 {%{REQUEST_STATUS} =~ /^[234]/}
      Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/" env=BALANCER_ROUTE_CHANGED
      <Proxy balancer://tableau>
      BalancerMember https://10.0.3.36/ route=1 hcmethod=GET hcexpr=ok234 hcuri=/favicon.ico
      BalancerMember https://10.0.4.15/ route=2 hcmethod=GET hcexpr=ok234 hcuri=/favicon.ico
      ProxySet stickysession=ROUTEID
      </Proxy>
      ProxyPreserveHost On
      ProxyPass / balancer://tableau/
      ProxyPassReverse / balancer://tableau/
      DocumentRoot /var/www/html
      ServerName tableau.example.com
      ServerSignature Off
      ErrorLog logs/error_sp.log
      CustomLog logs/access_sp.log combined
      LogLevel info ssl:warn
      SSLEngine on
      SSLCertificateFile /etc/ssl/certs/serverssl.crt
      SSLCertificateKeyFile /etc/ssl/private/serverssl.key
      SSLProxyEngine on
      SSLProxyVerify none
      SSLProxyCheckPeerName off
      SSLProxyCheckPeerExpire off
      </VirtualHost>
      <Location />
      #If you have configured a pre-auth module (e.g. Mellon) include those elements here.
      </Location>
      </IfModule>
    5. Add index.html file to supress 403 errors:

      sudo touch /var/www/html/index.html
    6. Restart httpd:

      sudo systemctl restart httpd

    Step 3: Configure Tableau Server for external SSL

    Copy the serverssl.crt and serverssl.key files from the Proxy 1 host to the initial Tableau Server (Node 1).

    Run the following commands on Node 1:

    tsm security external-ssl enable --cert-file serverssl.crt --key-file serverssl.key
    tsm pending-changes apply

    Step 4: Optional authentication configuration

    If you have configured an external identity provider for Tableau, then you will likely need to update return URLs in the IdP administrative dashboard.

    For example, if you are using a Okta pre-auth application, you will need to update the application to use HTTPS protocol for the Recipient URL and the Destination URL.

    Step 5: Configure AWS load balancer for HTTPS

    If you are deploying with AWS load balancer as documented in this guide, then you reconfigure the AWS load balancer to send HTTPS traffic to the proxy servers:

    1. Deregister existing HTTP target group:

      In Target Groups, select the HTTP target group that has been configured for the load balancer, click Actions, and then click Register and deregister instance.

      On the Register and deregister targets page, select the instances that are currently configured, click Deregister, and then click Save.

    2. Create HTTPS target group:

      Target groups > Create target group

      • Select "Instances"
      • Enter a target group name, for example TG-internal-HTTPS
      • Select your VPC
      • Protocol: HTTPS 443
      • Under Health checks > Advanced health checks settings > Success codes, append the code list to read: 200,303.
      • Click Create.
    3. Select the target group that you just created, and then click the Targets tab: 

      • Click Edit
      • Select the EC2 instances that are running proxy application, and then click Add to registered.
      • Click Save.
    4. After the target group is created, you must enable stickiness:

      • Open AWS Target Group page (EC2> Load Balancing> Target groups), select the target group instance that you just set up. On the Action menu, select Edit attributes.
      • On the Edit attributes page, select Stickiness, specify a duration of 1 day, and then Save changes.
    5. On load balancer, update listener rules. Select the load balancer you have configured for this deployment, and then click the Listeners tab.

      • For HTTP:80, click View/edit rules. On the resulting Rules page, click the edit icon (once at the top of the page, and then again by the rule) to edit the rule. Delete the existing THEN rule and replace it by clicking Add action > Redirect to.... In the resulting THEN configuration, specify HTTPS and port 443 and leave the other options to default settings. Save the setting and then click Update.
      • For HTTP:443, click View/edit rules. On the resulting Rules page, click the edit icon (once at the top of the page, and then again by the rule) to edit the rule. In the THEN configuration, under Forward to... change theTarget group to the HTTPS group that you just created. Under Group-level stickiness, enable stickiness and set duration to 1 day. Save the setting and then click Update.

    Step 6: Verify SSL

    Verify the configuration by browsing to  https://tableau.example.com.

    Thanks for your feedback!Your feedback has been successfully submitted. Thank you!