Search the docs

Enable TLS Using the Management GUI

This procedure is fully disruptive to normal platform operations. After TLS is enabled on the cluster, all clients must be remounted before data access can resume. Schedule this procedure during a planned maintenance window.

  1. Log in to the Hammerspace Management GUI as an admin user.

  2. Navigate to Administration  TLS.

  3. Click the NFS Transport Layer Security toggle to open the Enable TLS wizard.

  4. In the Details tab, review the information about tech preview support status and the impact of enabling TLS. Select the checkbox to confirm that you understand the risks and want to proceed, then click Next.

  5. In the Certificates tab, review the table of trusted certificates. Hammerspace must trust the root CA that issued each client’s and each storage server’s certificate. In this step you can add root CA certificates only. Add intermediate CA certificates and individual self-signed certificates with cert-add, before or after the wizard.

    1. Click Add Trusted Certificate.

    2. In Certificates File, click Upload and select a self-signed root CA certificate. This step rejects intermediate CA certificates, CA-signed client certificates, and self-signed certificates that are not CA certificates — an intermediate CA certificate is refused with A certificate was skipped because of error: Certificate is an intermediate CA and trustIntermediateCa is not true, although the step’s own hint text mentions intermediate certificates.

    3. Click Add to add the certificate to the wizard’s pending list. The certificate displays Local (Not yet uploaded) until the wizard completes.

    4. Repeat for each root CA certificate that Hammerspace must trust.

      When all certificates have been added, click Next.

      Closing the wizard before completing the configuration removes any pending certificate from the list.
      The table shows a delete icon on every certificate, including the Hammerspace System CA and the node certificates. Delete only certificates that you uploaded.

  6. In the Volumes tab, review the list of storage volumes on which TLS will be enabled. All volumes must support TLS — fix or remove any volume shown as failed before continuing. Click Next.

    You can download the Hammerspace cluster CA certificate from this tab (Download Cluster Certificate; the same button is on the Certificates tab). Install this certificate in the trust store of any backend storage system that needs to authenticate the Hammerspace cluster. Hammerspace does not use an intermediate CA, so you must add either the Hammerspace root CA certificate or the node certificate directly to the storage system’s trust store.

  7. In the Mounts tab, review the list of NFS mounts that will be affected by the TLS policy change. The list shows the cluster mounts and each DSX node’s mounts for every share, and can span several pages. Click Next.

  8. In the Clients tab, review the client IP addresses, ports, and protocols. The list includes the clients that currently have the cluster mounted; pNFS clients are listed as NFS 4.2 Clients with outstanding layouts. Each of these clients must be remounted after TLS is enabled. Click Next.

  9. In the GFS tab, review the site names and management addresses for each remote site in your global file system deployment. This is the final step of the wizard, so there is no Next action here.

  10. Click Enable TLS to begin the enablement process.

The cluster performs a series of background operations to transition all components to TLS. You can monitor progress in the Enable TLS dialog.

Enabling TLS is a cluster-wide operation. It takes about 2½ minutes on a cluster with two Anvil nodes and two DSX nodes when the DSX data-portal mounts are not restarted, and up to about 30 minutes when they are: each DSX data-portal mount restart can take about 10 minutes. Monitor progress in the Enable TLS dialog; the change is complete when NFS Transport Layer Security shows Enabled.

While the change runs, transient VOLUME_CLONE_TEST_FAILED alerts ("Permission denied") on the storage volumes, a short Down state of the DSX data portals, and HW_FRU_EVENT notices (Added hardware device /dev/sd…, several per DSX node) are expected and clear on their own. Clients that are still mounted without TLS lose access about a minute after you click Enable TLS, when the metadata server restarts and before the change completes (Permission denied; the client kernel logs RPC: server <address> requires stronger authentication). Clients can mount with xprtsec=mtls from that point.

After the process finishes, proceed to Remount Clients.