Skip to main content

Install SSL Certificate

You may optionally configure an SSL certificate to secure connections to the web application of the Designer Cloud Powered by Trifacta platform.

Note

For security reasons, a self-signed certificate is considered an insecure origin by most browsers, which do not cache results from these origins. As a result, each user visit to the Trifacta Application requires re-downloading of static assets from the application. For better performance, you should consider deploying a signed certificate. Low-cost solutions such as Let's Encrypt can be deployed to manage your certificates on the Trifacta node.

Prerequisites

  1. A valid SSL certificate for the FQDN where the Trifacta Application is hosted

    Tip

    Your certificate should be created using 2047-bit or larger keys. In some environments, such as RHEL 8.x, 1024-bit encryption is no longer accepted per default cryptographic policies.

  2. Root access to the Alteryx server

  3. Designer Cloud Powered by Trifacta platform is up and running

Configure nginx

There are two separate Nginx services on the server: one service for internal application use, and one service that functions as a proxy between users and the Trifacta Application. To install the SSL certificate, all configuration are applied to the proxy process only.

Note

Do not apply these configuration changes to the nginx files in /opt/trifacta/conf. Those files apply to the internal nginx server, which is not covered by SSL.

Steps:

  1. Log into the Alteryx server as the centos user. Switch to the root user:

    sudo su
  2. Enable the proxy nginx service so that it starts on boot:

    systemctl enable nginx
  3. Create a folder for the private key and limit access to it:

    sudo mkdir /etc/ssl/private/ && sudo chmod 700 /etc/ssl/private
  4. Copy the following files to the server. If you copy and paste the content, please ensure that you do not miss characters or insert unwanted characters.

    1. The .key file should go into the /etc/ssl/private/ directory.

    2. The .crt file and the CA bundle/intermediate certificate bundle should go into the /etc/ssl/certs/ directory.

      Note

      The delivery name and format of these files varies by provider. Please verify with your provider's documentation if this is unclear.

    3. Your certificate and the intermediate/authority certificate must be combined into one file for nginx. Here is an example of how to combine them together:

      cat example_com.crt bundle.crt >> ssl-bundle.crt
  5. Update the permissions on these files. Modify the following filenames as necessary:

    sudo chmod 600 /etc/ssl/certs/ssl-bundle.crt
    sudo chmod 600 /etc/ssl/private/your-private-cert.key
  6. Use the following commands to deploy the example SSL configuration file provided on the server:

    Note

    Below, some values are too long for a single line. Single lines that overflow to additional lines are marked with a \. The backslash should not be included if the line is used as input.

    cp /opt/trifacta/conf/ssl-nginx.conf.sample /etc/nginx/conf.d/trifacta.conf && \
    rm /etc/nginx/conf.d/default.conf
  7. Edit the following file:

    /etc/nginx/conf.d/trifacta.conf
  8. Please modify the following key directives at least:

    Directive

    Description

    server_name

    FQDN of the host, which must match the SSL certificate's Common Name

    ssl_certificate

    Path to the file of the certificate bundle that you created on the server. This value may not require modification.

    ssl_certificate_key

    Path to the .key file on the server.

    Example file:

    server {
      listen          443;
      ssl             on;
      server_name     EXAMPLE.CUSTOMER.COM;
      # Don't limit the size of client uploads.
      client_max_body_size 0;
      access_log      /var/log/nginx/ssl-access.log;
      error_log       /var/log/nginx/ssl-error.log;
      ssl_certificate      /etc/ssl/certs/ssl-bundle.crt;
      ssl_certificate_key  /etc/ssl/certs/EXAMPLE-NAME.key;
      ssl_protocols        TLSv1.2 TLSv1.3;
      ssl_ciphers RC4:HIGH:!aNULL:!MD5;
      ssl_prefer_server_ciphers on;
      keepalive_timeout    60;
      ssl_session_cache    shared:SSL:10m;
      ssl_session_timeout  10m;
      location / {
        proxy_pass  http://localhost:3005;
        proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
        proxy_set_header        Accept-Encoding   "";
        proxy_set_header        Host            $host;
        proxy_set_header        X-Real-IP       $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header        X-Forwarded-Proto $scheme;
        add_header              Front-End-Https   on;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_redirect     off;
      }
      proxy_connect_timeout       6000;
      proxy_send_timeout          6000;
      proxy_read_timeout          6000;
      send_timeout                6000;
    }
    server {
      listen          80;
      return 301 https://$host$request_uri;
    }
  9. Save the file.

  10. To apply the new configuration, start or restart the nginx service:

    service nginx restart

Modify listening port for Designer Cloud Powered by Trifacta platform

If you have changed the listening port as part of the above configuration change, then the proxy.port setting in Designer Cloud Powered by Trifacta platform configuration must be updated. See Change Listening Port.

Add secure HTTP headers

If you have enabled SSL on the platform, you can optionally insert the following additional headers to all requests to the Trifacta node:

Header

Protocol

Required Parameters

X-XSS-Protection

HTTP and HTTPS

proxy.securityHeaders.enabled=true

X-Frame-Options

HTTP and HTTPS

proxy.securityHeaders.enabled=true

Strict-Transport-Security

HTTPS

proxy.securityHeaders.enabled=true and

proxy.securityHeaders.httpsHeaders=true

Note

SSL must be enabled to apply these security headers.

Steps:

To add these headers to all requests, please apply the following change:

  1. You can apply this change through the Admin Settings Page (recommended) or trifacta-conf.json. For more information, see Platform Configuration Methods.

  2. Locate the following setting and change its value to true:

    "proxy.securityHeaders.httpsHeaders": false,
  3. Save your changes and restart the platform.

Enable secure cookies

If you have enabled SSL on the platform, you can optionally enable the use of secure cookies.

Note

SSL must be enabled.

Steps:

  1. You can apply this change through the Admin Settings Page (recommended) or trifacta-conf.json. For more information, see Platform Configuration Methods.

  2. Locate the following setting and change its value to true:

    "webapp.session.cookieSecureFlag": false,
  3. Save your changes and restart the platform.

Disable default port

If you wish to access through the default port (3005), you must do so external to the platform and through the node itself.

Note

The Designer Cloud Powered by Trifacta platform requires access to the default port internally. You cannot disable external access to this port through the platform. You must disable through the operating system.

For more information, please see the documentation provided with your operating system distribution.

Update certificates

To replace a certificate with an updated one, please do the following.

Steps:

  1. Copy in the new certificate to the Trifacta node.

  2. Edit the nginx configuration file:

    /etc/nginx/conf.d/trifacta.conf
  3. In the configuration file, replace the values for the following settings to point to the new certificate:

    1. ssl_certificate

    2. ssl_certificate_key

    3. For more information, see "Configure nginx" above.

  4. Save the file, and restart the platform.

Troubleshooting

Problem - SELinux blocks proxy service from communicating with internal app service

If the Designer Cloud Powered by Trifacta platform is installed on SELinux, the operating system blocks communications between the service that manages the proxy between users and the application and the service that manages internal application communications.

To determine if this problem is present, execute the following command:

sudo cat /var/log/audit/audit.log | grep nginx | grep denied

The problem is present if an error similar to the following is returned:

type=AVC msg=audit(1555533990.045:1826142): avc:  denied  { name_connect } for  pid=25516 comm="nginx" dest=3005 scontext=system_u:system_r:httpd_t:s0 

For more information on this issue, see https://www.nginx.com/blog/using-nginx-plus-with-selinux.

Solution:

The solution is to enable the following network connection through the operating system:

sudo setsebool -P httpd_can_network_connect 1

Restart the platform.