Reference: Certificate Trust Model

Hammerspace uses X.509 certificates for mutual authentication between all NFS endpoints. Understanding the trust model helps administrators plan their certificate strategy.

Hammerspace system CA. At startup, Hammerspace generates a self-signed root CA certificate for the cluster. This CA is used to sign per-node certificates for all product nodes. The system CA has a validity period of 10 years. Administrators can download the system CA certificate to install as a trust anchor on clients and storage systems. During enablement, click Download Cluster Certificate on the Certificates or Volumes step of the Enable TLS wizard. At any other time, go to Administration  TLS, select the Cluster Root CA tab, and click Download Certificate.

Per-node certificates. Each product node receives a unique X.509 certificate signed by the system CA. Certificates include the node’s IP addresses in the Subject Alternative Name (SAN) field. Per-node certificates are valid for 365 days from issue. A node’s certificate is issued when the cluster first runs Hammerspace 5.3 or when the node is added, whether or not TLS is enabled. Hammerspace re-issues a node’s certificate when the node’s IP addresses change or the system CA changes; it does not renew certificates as they approach expiry. See Limitations in Hammerspace 5.3.

Uploaded CA certificates. Administrators can upload their organization’s CA certificate (or certificate chain) to extend Hammerspace’s trust store. Uploaded CAs are used for verifying incoming client and storage certificates — they are not used to sign internal Hammerspace node certificates.

Signing user-supplied CSRs. Clients and storage systems that do not have their own CA can submit a Certificate Signing Request (CSR) to Hammerspace. Hammerspace signs the CSR with its system CA and returns the signed certificate. The CSR must include at least one IP address in the SAN field.