Certificate Lifetimes and Expiration

Every certificate that NFS over TLS relies on has a fixed lifetime. Hammerspace does not warn you before a certificate expires, and does not renew any certificate automatically, so you must track expiration dates yourself and act before the earliest one expires.

The most important dates are those of the node certificates. Hammerspace issues one to every Anvil and DSX node, they are valid for one year, and they exist even on a cluster that has never enabled TLS. When a node certificate expires on a cluster that requires TLS, new TLS connections to and from that node fail.

Certificate Lifetimes

Table 1. Certificate lifetimes
Certificate	Lifetime	When it is issued, and how it is replaced
Hammerspace system CA (`SYSTEM_CA`)	10 years (3,650 days)	Created once, when the cluster first runs Hammerspace 5.3. Hammerspace 5.3 provides no way to replace it.
Node certificate (`SYSTEM_ISSUED`), one per Anvil and DSX node	365 days	Issued when the cluster first runs Hammerspace 5.3, whether by installation or by upgrade, and when a node is added to the cluster. Issued whether or not TLS is enabled. See Renewing Certificates.
Certificate signed from a CSR (`CSR_SIGNED_BY_CA`)	365 days	Issued when you sign a certificate signing request with `cert-csr-sign` or on the Signed Certificates tab. Supports client authentication only. Replace it by signing a new CSR.
Certificate or CA that you upload to the trust store (`UPLOADED_ROOT_CA`, `UPLOADED_INTERMEDIATE_CA`, `UPLOADED_PINNED_CERT`)	Set by the issuer	Managed by your certificate authority. Replace it by adding the new certificate and removing the old one.

Enabling or disabling TLS does not issue new node certificates. A node’s existing certificate is used, so its expiration date is counted from the day it was issued, not from the day TLS was enabled. On a cluster that was upgraded to 5.3 and switched to require TLS later, the node certificates can expire well under a year after TLS was enabled.

Hammerspace does not reissue a node certificate as it approaches expiration.

Each certificate’s Not Before date is set 30 days before the date it was issued, to allow for clock differences between systems. A node certificate’s Not After date is therefore 395 days after its Not Before date.

The certificate that the Management GUI and REST API present over HTTPS is separate from NFS over TLS and has its own lifetime. See Server Certificate.

Checking Certificate Expiration Dates

Check the expiration dates of the node certificates as soon as the cluster is running Hammerspace 5.3, and again before you enable TLS. Record the earliest Not After date and plan to act well before it.

To list the node certificates with their validity dates, run the following command in the Admin CLI:

List node certificates

Command:

cert-list --origin SYSTEM_ISSUED --full

Expected output (one node’s entry; the listing has one entry per node):

total 4
ID:                      da5cc4d0-fe89-4605-b231-00e748a522d5
Type:                    Certificate
Origin:                  System issued
Usages:                  [TLS client, Service to service trust, TLS server]
Enabled:                 Yes
Certificate:
                         Version:      3
                         Serial:       8214428371184591649910355041491249791547246493 (0x17059035d28d8e89268e285ef547982e60c879d)
                         Algorithm:    SHA512withRSA
                         Issuer:       O=Hammerspace, OU=CLUSTER, OU=789c4318-baf9-44f8-b43c-fb5923741c38, CN=Hammerspace System CA
                         Subject:      O=Hammerspace, OU=NODE, CN=b3282a04-a030-5816-b9ea-6c0452e8980e
                         Validity:
                           Not Before: 2026-08-28 18:36:49 UTC
                           Not After:  2027-09-27 18:36:49 UTC
                         Fingerprints:
                           SHA1:       3a:48:da:2:22:c2:84:77:8:9d:ad:cb:5f:60:66:6c:b4:86:85:e3
                           MD5:        5e:b3:e0:b9:50:eb:96:32:42:12:62:3a:d1:f2:18:1c
                           CRC32:      0x735b89cf

Parent:                  ID:                      80836289-5308-49eb-94d9-0c1c15ffee68
                         Type:                    Certificate
<Additional output removed for brevity>

The output includes one certificate for each Anvil and DSX node. For each certificate, the Not After line under Validity is the expiration date, in UTC. The certificate’s Subject contains OU=NODE and CN=<node ID>, where <node ID> is the node’s ID. To match an ID to a node name, compare it with the ID column of the node-list command.

To check the other certificates, run cert-list --full without the --origin option. The system CA, uploaded certificates, and certificates signed from a CSR with the --track option are listed with the same Validity fields. A certificate signed without --track is not kept by Hammerspace, so check its expiration date where it is installed.

In the Management GUI, go to Administration TLS and select the Trusted Certificates tab. The tab lists the node certificates, the system CA, and the certificates you have uploaded, each with an Expiration Date. A node certificate’s Issued To value begins with CN=<node ID>,OU=NODE; node certificates and the system CA have no delete action. The Signed Certificates tab lists the certificates signed from a CSR, and the Cluster Root CA tab shows the system CA’s validity dates.

When a Certificate Expires

Every NFS over TLS connection begins with a TLS handshake in which both sides present a certificate and each side checks that the other’s certificate is signed by a trusted CA and has not expired. A handshake that presents an expired certificate fails.

What an expired certificate breaks depends on which certificate it is:

A node certificate, while the cluster requires TLS. New TLS connections to and from the node fail. Clients cannot mount through that node, and connections between the node and the Anvil, other DSX nodes, and backend storage cannot be re-established. When every node certificate was issued on the same day, as on a cluster upgraded to 5.3, they all expire on the same day.
A node certificate, while TLS is forbidden. NFS traffic does not use the certificate, so data access continues. The certificate must be replaced before you enable TLS.
A certificate signed from a CSR, or a certificate issued by a CA you uploaded. The client, storage system, or external mover that presents it can no longer complete a TLS handshake with the cluster.

A Linux client reports a failed handshake, whatever the cause, as access denied by server. For how to tell an expired certificate from other causes, see Troubleshoot TLS Issues.

Hammerspace checks each node’s certificate periodically. When it finds that a node certificate has expired, it raises the PKI_NODE_CHECK_FAILED event for that node, at Critical severity while TLS is required and at Warning severity while TLS is forbidden. The event is raised only after the certificate has expired. No event is raised before expiration, and no event is raised for CSR-signed or uploaded certificates.

Renewing Certificates

Table 2. How to replace each certificate before it expires
Certificate	How to replace it
Node certificate	Hammerspace 5.3 does not provide a way for administrators to renew node certificates. Contact Hammerspace Support well before the earliest node certificate expires.
Certificate signed from a CSR (clients only)	Generate a new CSR on the client, sign it with `cert-csr-sign` or on the Signed Certificates tab, and install the new certificate in place of the old one. If the old certificate was signed with `--track` or on the Signed Certificates tab, remove it from that tab or with `cert-remove`. Certificates signed from a CSR support client authentication only, so storage servers need a certificate from their own CA. See Manage Certificates and CAs.
Certificate or CA that you uploaded	Add the replacement before the old one expires: a root CA with `cert-add` or on the Trusted Certificates tab, and an intermediate CA or pinned certificate with `cert-add`, then remove the old one with `cert-remove`. Remove the old CA only after every client, storage system, and external mover that presents a certificate issued by it has a replacement.
System CA	Hammerspace 5.3 does not provide a way to replace the system CA. It is valid for 10 years from the day the cluster first ran Hammerspace 5.3.

A Data Instantiator in an external mover container reads its certificate and trusted CAs only when it starts. After you replace a mover’s certificate or add a CA to its trust store, restart the mover. See External Movers (DI and Cloud Mover Containers).