<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h4 class="title">
      <a name="mysql-cluster-tls-overview">
      </a>
      25.6.15.1 Overview of TLS for NDB Cluster
     </h4>
    </div>
   </div>
  </div>
  <p>
   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.
  </p>
  <p>
   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.
  </p>
  <p>
   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.
  </p>
  <p>
   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.
  </p>
  <p>
   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.
  </p>
  <p>
   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.
  </p>
  <p>
   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.
  </p>
  <p>
   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).
  </p>
 </div>
 <br/>
</div>
