После создания ЦС и сертификата вы можете проверить доступность TLS-соединения с сервером управления, запустив клиент ndb_mgm с параметром --test-tls, например так:

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

Если клиент может подключиться с использованием TLS, будет выведено соответствующее сообщение. Возможно, вам потребуется включить и другие параметры ndb_mgm, такие как --ndb-tls-search-path, для упрощения TLS-соединения, как показано здесь:

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

Если клиент подключается без использования TLS, это также будет указано, аналогично показанному ниже:

$> ndb_mgm
Connected to management server at localhost port 1186 (using cleartext)
$>

Чтобы заставить кластер использовать ЦС и сертификаты, созданные с помощью ndb_sign_keys, выполните постепенную перезагрузку кластера, начиная с узлов управления, которые следует перезапустить с использованием параметра --ndb-tls-search-path. После этого перезапустите узлы данных, снова используя --ndb-tls-search-path. Также поддерживается --ndb-tls-search-path для mysqld при работе в качестве узла API кластера.

Для функционирования TLS каждый узел, подключающийся к кластеру, должен иметь действительный сертификат и ключ. Это относится к узлам данных, узлам API и утилитам. Один и тот же сертификат и ключ могут использоваться более чем одним узлом.

Узлы данных регистрируют TLS-соединение и включают полный путь к файлу сертификата, используемого, как показано здесь:

$> 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

Вы можете проверить, что узлы кластера используют TLS для подключения, проверив вывод команды TLS INFO в клиенте ndb_mgm, например так:

$> 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>

Если Current connections и Current connections using TLS совпадают, это означает, что все соединения кластера используют TLS.

После того, как вы установили TLS-соединения для всех узлов, вы должны сделать TLS обязательным требованием. Для клиентов это можно сделать, установив ndb-mgm-tls=strict в файле my.cnf на каждом узле кластера. Принудительно применять требование TLS к серверу управления, установив RequireTls=true в разделе [mgm default] файла конфигурации кластера config.ini, а затем выполнив постепенную перезагрузку кластера, чтобы это изменение вступило в силу. Сделайте то же самое для узлов данных, установив RequireTls=true в разделе [ndbd default] файла конфигурации; после этого выполните вторую постепенную перезагрузку кластера, чтобы изменения вступили в силу для узлов данных. Запустите ndb_mgmd с параметрами --reload и --config-file в обоих случаях, чтобы гарантировать, что каждое из двух изменений файла конфигурации будет прочитано сервером управления.

Для замены закрытого ключа используйте ndb_sign_keys --create-key для создания нового ключа и сертификата, с --node-id и --node-type options, если необходимо, чтобы ограничить замену до одного идентификатора узла, типа узла или обоих. Если инструмент найдёт существующие файлы ключа и сертификата, он переименует их, чтобы отразить их статус устаревания, и сохранит вновь созданный ключ и сертификат как активные файлы; новые файлы будут использоваться при следующем запуске узла.

Для замены сертификата без замены закрытого ключа используйте ndb_sign_keys без предоставления параметра --create-key. Это создаст новый сертификат для существующего ключа (без замены ключа) и аннулирует старый сертификат.

Поддержка удалённого подписи ключей также доступна в ndb_sign_keys. Используя SSH, параметр --remote-CA-host предоставляет SSH-адрес узла ЦС в формате user@host. По умолчанию, локальный процесс ndb_sign_keys использует системную утилиту ssh и адрес для запуска ndb_sign_keys на удалённом узле с правильными параметрами для выполнения необходимой подписи. В качестве альтернативы, если --remote-openssl=true, вместо ndb_sign_keys на удалённом узле используется openssl.

При использовании удалённой подписи передаваемые по сети данные представляют собой запрос на подпись PKCS#10, а не закрытый ключ, который никогда не покидает локальный узел.