Understanding Connector SSL


In this blog post, we explain the various communication channels used by the Tungsten Connector and how to configure them securely:

  • MySQL query traffic
  • Management traffic

The In’s and Out’s

Let’s think about it - the Connector juggles multiple conversations very deftly - here is a list of all the communications channels open at the same time:

  • MySQL query traffic: Client application ⇔ Connector 3306
  • MySQL query traffic: Connector ⇔ MySQL Server 13306
  • Cluster management traffic (status & RMI): Connector ⇔ Manager 11999

Each of these four channels can optionally be encrypted in flight with SSL. There are entirely different procedures for handling the three channels listed above.

MySQL Query Traffic - Details

SSL encryption for MySQL query traffic is supported by the Tungsten Connector operating in Proxy mode in three different possible combinations:

  • SSL between the application and Connector
    Non-SSL connections between Connector and MySQL
  • Non-SSL between the application and Connector
    SSL connections between Connector and MySQL
  • SSL between the application and Connector
    SSL between Connector and MySQL

NOTE: that when operating in Bridge mode, the Connector is only involved in picking the correct server. In this situation the SSL configuration will be identical to the regular MySQL SSL setup, as explained in the MySQL documentation located here: https://dev.mysql.com/doc/refman/8.0/en/using-encrypted-connections.html

To enable connector SSL during installation or update:


This will configure the Connector with the specified keystores, truststore and enable SSL on MySQL Query traffic via Connector Proxy-mode connections.

The complete documentation for configuring encrypted MySQL traffic via the Connector is here: https://docs.continuent.com/tungsten-clustering-6.1/connector-ssl.html

Management Channels - Details

Communication between managers and the connectors is handled on port 11999 (managed by --router-gateway-port).

These connections are used to exchange cluster status and individual datasource availability as identified by the manager so that decisions about active connections can be effectively made by the connector.

Complete documentation for these details is located at

SSL encryption for Management traffic is supported by the Tungsten Connector in two different possible combinations:

  • Non-SSL between the Connector to the Manager
  • SSL between the Connector to the Manager

To enable encrypted internal cluster management traffic during installation or update, configure your INI:


Once the install completes on all nodes, simply choose one node and run the following TWO commands to copy the needed keys from node db1 to the rest of the cluster nodes. Please update the below commands to match your hostnames and paths!

shell> for i in `seq 2 6`; do scp /opt/continuent/share/[jpt]* db$i:/opt/continuent/share/; done
shell> for i in `seq 2 6`; do scp /opt/continuent/share/.[jpt]* db$i:/opt/continuent/share/; done

Now that the same keys are on every cluster node, including Connector-only nodes, start the Tungsten processes:

shell> startall

NOTE: If you are using the Staging installation method from a single host, then the keys are automatically copied for you, and the start-and-report=false should be omitted.

For more information, please visit: https://docs.continuent.com/tungsten-clustering-6.1/deployment-security-enabling.html


In this blog post, we explained the various communication channels used by the Connector:

  • MySQL query traffic
  • Cluster internal management traffic

Each channel is required, and configured separately. If your cluster is configured to use disable-security-controls=false so that internal cluster management traffic is encrypted, then ALL nodes must be configured the same way, and ALL nodes must share the same keys.

Related Resources

Tungsten Connector (also known as Tungsten Proxy) is a key component of our Tungsten Clustering solution. To find out more about it, please see these resources:

About the Author

Eric M. Stone
COO and VP of Product Management

Eric is a veteran of fast-paced, large-scale enterprise environments with 35 years of Information Technology experience. With a focus on HA/DR, from building data centers and trading floors to world-wide deployments, Eric has architected, coded, deployed and administered systems for a wide variety of disparate customers, from Fortune 500 financial institutions to SMB’s.

Add new comment