25.6.15.3 Using TLS Connections

Once you have created a CA and certificate, you can test the availability of the TLS connection to the management server by running the ndb_mgm client with --test-tls, like this:

$> ndb_mgm --test-tls
No valid certificate.

An appropriate message is generated if the client can connect using TLS. You may need to include other ndb_mgm options such as --ndb-tls-search-path to facilitate the TLS connection, as shown here:

$> ndb_mgm --test-tls --ndb-tls-search-path="CA:keys"
Connected to management server at localhost port 1186 (using TLS)

You can cause the cluster to use the CA and certificates created with ndb_sign_keys by performing a rolling restart of the cluster, beginning with the management nodes, which should be restarted using the --ndb-tls-search-path option. After this, restart the data nodes, again using --ndb-tls-search-path. --ndb-tls-search-path is also supported for mysqld run as a cluster API node.

For TLS to function, every node connecting to the cluster must have a valid certificate and key. This includes data nodes, API nodes, and utility programs. The same certificate and key files can be used by more than one node.

Data nodes log the TLS connection and include the full path to the certificate file used, as shown here:

$> ndbmtd -c localhost:1186 --ndb-tls-search-path='CA:keys'
2023-12-19 12:02:15 [ndbd] INFO     -- NDB TLS 1.3 available using certificate file 'keys/ndb-data-node-cert'
2023-12-19 12:02:15 [ndbd] INFO     -- Angel connected to 'localhost:1186'
2023-12-19 12:02:15 [ndbd] INFO     -- Angel allocated nodeid: 5

You can verify that cluster nodes are using TLS to connect by checking the output of the TLS INFO command in the ndb_mgm client, like this:

$> ndb_mgm --ndb-tls-search-path="CA:keys"
-- NDB Cluster -- Management Client --
ndb_mgm> TLS INFO
Connected to management server at localhost port 1186 (using TLS)
 
Main interactive connection is using TLS
Event listener connection is using TLS
 
Server reports 6 TLS connections.

  Session ID:          32
  Peer address:        ::
  Certificate name:    NDB Node Dec 2023
  Certificate serial:  39:1E:4A:78:E5:93:45:09:FC:56
  Certificate expires: 21-Apr-2024
 
  Session ID:          31
  Peer address:        127.0.0.1
  Certificate name:    NDB Node Dec 2023
  Certificate serial:  39:1E:4A:78:E5:93:45:09:FC:56
  Certificate expires: 21-Apr-2024
 
  Session ID:          30
  Peer address:        127.0.0.1
  Certificate name:    NDB Node Dec 2023
  Certificate serial:  39:1E:4A:78:E5:93:45:09:FC:56
  Certificate expires: 21-Apr-2024
 
  Session ID:          18
  Peer address:        127.0.0.1
  Certificate name:    NDB Data Node Dec 2023
  Certificate serial:  57:5E:58:70:7C:49:B3:74:1A:99
  Certificate expires: 07-May-2024
 
  Session ID:          12
  Peer address:        127.0.0.1
  Certificate name:    NDB Data Node Dec 2023
  Certificate serial:  57:5E:58:70:7C:49:B3:74:1A:99
  Certificate expires: 07-May-2024
 
  Session ID:          1
  Peer address:        127.0.0.1
  Certificate name:    NDB Management Node Dec 2023
  Certificate serial:  32:10:44:3C:F4:7D:73:40:97:41
  Certificate expires: 17-May-2024
 
 
    Server statistics since restart
  Total accepted connections:        32
  Total connections upgraded to TLS: 8
  Current connections:               6
  Current connections using TLS:     6
  Authorization failures:            0
ndb_mgm>

If Current connections and Current connections using TLS are the same, this means that all cluster connections are using TLS.

Once you have established TLS connections for all nodes, you should make TLS a strict requirement. For clients, you can do this by setting ndb-mgm-tls=strict in the my.cnf file on each cluster host. Enforce the TLS requirement on the management server by setting RequireTls=true in the [mgm default] section of the cluster config.ini file, then performing a rolling restart of the cluster so that this change takes effect. Do this for the data nodes as well, by setting RequireTls=true in the [ndbd default] section of the configuration file; after this, perform a second rolling restart of the cluster to make the changes take effect on the data nodes. Start ndb_mgmd with the --reload and --config-file options both times to ensure that each of the two configuration file changes is read by the management server.

To replace a private key, use ndb_sign_keys --create-key to create the new key and certificate, with the --node-id and --node-type options if and as necessary to limit the replacement to a single node ID, node type, or both. If the tool finds existing key and certificate files, it renames them to reflect their retired status, and saves the newly created key and certificate as active files; the new files are used the next time that the node is restarted.

To replace a certificate without replacing the private key, use ndb_sign_keys without supplying the --create-key option. This creates a new certificate for the existing key (without replacing the key), and retires the old certificate.

Remote key siging is is also supported by ndb_sign_keys. Using SSH, the --remote-CA-host option supplies the SSH address of the CA host in user@host format. By default, the local ndb_sign_keys process uses the system ssh utility and address to run ndb_sign_keys on the remote host with the correct options to perform the desired signing. Alternately, if --remote-openssl=true, openssl rather than ndb_sign_keys is used on the remote host.

When using remote signing, the data sent over the network is a PKCS#10 signing request, and not the private key, which never leaves the local host.