MySQL 9.1 Release Notes
TLS can be used to secure network communications in NDB Cluster 8.3 and later. NDB Transporter connections secured by TLS use TLS mutual authentication, in which each node validates the certificate of its peer. A node certificate can also be bound to a particular hostname; in this case, a peer authorizes the certificate only if the hostname can be verified.
A node's own certificate file contains the entire chain of trust it uses to validate the certificates of its peers. This usually includes only its own certificate and that of the issuing CA, but may include additional CAs. Because an NDB cluster is considered a realm of trust, the CA should be limited in scope to a single cluster.
In order to obtain signed node certificates, it is necessary first to create a Certification Authority (CA). When TLS is deployed, every node has an authentic certificate, which is signed by the CA. Only the administrator (DBA) should have access to the private CA signing key with which valid node certificates are created.
Hostname bindings are created for management and API node certificates by default. Since NDB Cluster data nodes are already subject to hostname checks as part of node ID allocation, the default behavior is to not add an additional hostname check for TLS.
A certificate is no longer valid upon arrival of the expiration date. To minimize the impact of certificate expiration on system availability, a cluster should have several certificates with staggered expiration dates; client certificates should expire earliest, followed by data node certificates, and then by management server certificates. To facilitate staggered expiration, each certificate is associated with a node type; a given node uses keys and certificates of the appropriate type only.
Private keys are created in place; copying of files containing private keys is minimized. Both private keys and certificates are labeled as either active (current) or pending. It is possible to rotate keys to allow for pending keys to replace active keys before the active keys expire.
Due to the potentially large numbers of files involved, NDB follows several naming conventions for files storing keys, signing requests, and certificates. These names are not user configurable, although the directories where these files are stored can be determined by the user.
By default, NDB Cluster CA private keys are protected by a passphrase which must be provided when creating a signed node certificate. Node private keys are stored unencrypted, so that they can be opened automatically at node startup time. Private key files are read-only (Unix file mode 0400).