NTLS vs STC on Luna HSMs: why your HSM connection dies after a DR failover

Your DR test went fine — until the application tried to talk to the HSM. The vault started, the CA service started, the network team confirmed routes, and then every cryptographic operation failed with a connection error. Four hours later someone noticed the problem was never the firewall. It was a certificate with the wrong name in it.

This chapter of the Luna Field Guide explains how trust actually works on a Luna Network HSM’s two client connection types — NTLS and STC — why NTLS trust quietly binds itself to your client’s hostname or IP address, and how to design client registration so a DR failover is a non-event instead of an incident. If you’re new to the platform, start with our Luna HSM design and operational guide and come back.

How NTLS trust actually binds

NTLS — the Network Trust Link Service — is the default way a client application reaches a partition on a Luna Network HSM. It is mutually authenticated TLS: the appliance presents a server certificate (server.pem), the client presents a client certificate, and each side must have registered the other’s certificate before a session is allowed. Once the link is up, PKCS#11 traffic flows over it to the partition.

The part that catches people out is how the client certificate is created. On the client you run:

vtl createCert -n <client_hostname_or_IP>

That -n value becomes the certificate’s common name, and it is not decorative. When the appliance administrator registers the client with client register, they must register it against the same hostname or the same IP address that was baked into the certificate. Thales’s own setup documentation is explicit: if the certificate was created with a hostname, register with -hostname; if it was created with an IP, register with -ip. The trust relationship is therefore a three-way binding: this certificate, for this client name, at this network identity.

On top of that, the appliance can enforce a source-IP check on incoming NTLS connections (the lunash ntls ipcheck setting). With the check active, a client presenting a perfectly valid, registered certificate from an unexpected source address is still refused. This is a sensible anti-spoofing control in a static data centre. It is also a landmine in any environment where addresses change — NAT, cloud, and, most relevantly here, DR.

The DR failover that kills the HSM connection

Here is a composite scenario we see repeatedly in regulated environments — assembled from community reports, vendor knowledge-base threads and field patterns, not from any specific engagement.

An agency runs its issuing CA and its privileged-access vault against a pair of Luna Network HSMs, one per site. An annual DR exercise fails the application tier over to the second data centre. The DR copies of the application servers come up on the DR subnet — different IP addresses, and in some shops a different hostname suffix too. The Luna appliance at the DR site is healthy, reachable, and has a perfectly good replica of the partition.

The application logs fill with slot-not-found and token-not-present errors. vtl verify on the client returns no usable slots. And because the symptom is “can’t reach a network service”, the incident call does what incident calls do: it becomes a firewall hunt. Rules are checked, packet captures are taken, port 1792 is confirmed open, the network team proves TCP connects fine — and it does, because the TCP and TLS layers are not the problem. Hours in, someone reads the NTLS logs on the appliance and finds the handshake being rejected: the client’s certificate says it is 10.10.20.15, and the connection is arriving from 10.60.20.15. The certificate is telling the truth about a server that no longer exists at that address.

Nothing is broken, in the sense that every component is doing exactly what it was configured to do. The trust anchor was simply bound to a network identity that DR was always going to change. If you run CyberArk against Luna HSMs, this is precisely the failure mode to design out — our guide to implementing CyberArk CorePAS across multiple sites covers the multi-site architecture side of the same problem.

Why this failure hides from you

Three properties make this failure unusually good at wasting an incident bridge’s time:

• TCP succeeds. Port 1792 answers, so every network-layer test passes. The rejection happens inside the TLS handshake or the NTLS client-mapping step, which ordinary connectivity checks never see.
• The client-side errors are generic. PKCS#11 applications report missing slots or tokens, not “your certificate CN no longer matches your address”. The informative log line is on the appliance, which the application team often can’t read.
• It only manifests at DR. The configuration is provably correct — it has worked in production for years. Nobody suspects config that has never failed.

The diagnostic shortcut worth institutionalising: if TCP to port 1792 works but vtl verify shows no slots, stop debugging the network and start comparing the client certificate’s CN with the address the appliance sees the connection arriving from. That one habit collapses a four-hour bridge into a ten-minute fix.

STC: a different trust model

Secure Trusted Channel (STC) is the other way a Luna client can talk to a partition, and it makes fundamentally different trust decisions. Where NTLS terminates its encryption at the appliance’s network interface, STC establishes an encrypted, integrity-protected, replay-protected channel that terminates inside the HSM. And where NTLS identifies a client by a certificate naming its hostname or IP, STC identifies a client by a cryptographic identity — an RSA key pair held in a client token, registered against the partition itself.

Practically, an STC setup exchanges identities rather than address-bearing certificates: the client creates its identity in LunaCM (stc identitycreate), the partition’s identity is exported from the appliance and registered on the client, and the client’s public key is registered against the partition. The trust anchor is the key pair, not the network location. By default the client’s private key lives in a software token on disk; where the client platform supports it, a hardware token can hold it non-extractably.

The trade-offs are real, which is why STC is not simply “NTLS but better”:

	NTLS	STC
Encryption terminates	Appliance network interface	Inside the HSM
Client identity	Certificate bound to hostname/IP	Key pair (client token)
Performance	Recommended for high-throughput workloads	Additional per-message overhead; suits moderate throughput
Message integrity / anti-replay	TLS session protection only	Per-message signing and replay protection
IPv6	Supported	Not supported — IPv6 links must use NTLS
Typical fit	Data-centre applications, performance-sensitive CAs	Cloud/virtualised clients, multi-tenant service models, links crossing lower-trust networks

One constraint to plan around: all links between a given client and a given appliance must be the same type — you cannot mix NTLS and STC partitions from one client to one appliance. And note that STC’s implementation changed materially across Luna 7 releases (the identity-export commands differ between 7.4 and 7.7+, and later firmware transports STC differently), so check the documentation for your exact appliance software before committing to a design.

For the DR question specifically: because STC’s client identity is a key pair rather than an address-bound certificate, a client changing IP address does not invalidate the identity itself in the way an NTLS CN mismatch does. That does not make STC a free DR fix — the transport still has to be re-established and version-dependent behaviour applies — but it removes the specific trap that burns NTLS deployments.

Designing client registration so DR doesn’t break it

Most organisations should stay on NTLS for performance and simplicity — and simply stop binding trust to addresses that change. Four design rules do the work:

• Register by DNS name, not IP. Create the client certificate against a stable FQDN and register it with -hostname. If the DR copy of the server keeps its name and DNS resolves correctly at the DR site, the certificate binding survives the move. The name in the certificate must exactly match what the client OS reports as its hostname.
• Pre-register the DR identity. Where DR servers have different names or addresses, generate and register a second client entry — the DR identity — on every appliance now, and assign it to the same partitions. Failover then requires zero HSM administration. The how-to companion to this chapter walks through the exact commands.
• Decide the ipcheck question deliberately. The appliance’s NTLS source-IP verification is a genuine control; disabling it is a genuine risk decision. In ISM-aligned environments, document it either way — an IRAP assessor will ask why the setting is what it is, and “it broke DR once” is not a design rationale.
• Test the trust path, not just the app. Add “vtl verify returns the expected slots from the DR host” to the DR runbook as an explicit checkpoint before application start-up. It is the single fastest discriminator between a network problem and a trust problem.

The firewall and port picture

For completeness, because every DR runbook needs it written down: NTLS listens on TCP 1792 on the appliance by default (it is configurable via the lunash ntls commands). Client-to-appliance traffic on 1792 must be open from both the production and DR client subnets to every appliance the client may use — a rule that is obvious in a diagram and routinely missing in at least one direction in real firewall estates. Appliance administration runs over SSH on TCP 22, which your admin jump hosts need but your application servers should not. If you use HA groups across sites, every member client needs 1792 to every member appliance, or synchronisation degrades in ways that only surface under failure.

A clean firewall picture also keeps the diagnostic shortcut honest: when 1792 is definitively open and verified, a dead connection is a trust problem, and you can say so in the first fifteen minutes of the bridge.

---

Where this leaves you

Your client connections can now survive a failover — but the partitions behind them have their own trap: partition software versions and the Scalable Key Storage master key (SMK) interact badly with appliance upgrades, and a mismatched upgrade can strand your backups just as effectively as a bad certificate strands your clients. That’s the next chapter. From here the guide also opens its CyberArk arc — putting the vault’s server key on the HSM — which builds directly on the connection work you’ve just done; the background is in our CyberArk CorePAS guide for security architects. All chapters live at The Luna Field Guide.