No outbound calls to an external Certificate Authority (CA) or OCSP responder are made from the NFS TLS handshake path in 9.19.1. Chain and Subject Alternative Name (SAN) validation are performed locally against the SVM's installed certificate material.

NFSv3 and NFSv4 both encrypt the entire NFS payload after the first NULL Call/Response pair to TCP port 2049. The NULL call has the new AUTH_TLS credential flavor defined in RFC 9289 that signals the client's intention to use TLS. The server responds with a NULL reply that either accepts or rejects the TLS upgrade. If the client receives acceptance, it proceeds with the TLS 1.3 handshake over the same TCP connection. If the handshake completes successfully, all subsequent NFS RPCs are encapsulated in TLS records and encrypted in transit.

There is one difference between NFSv3 and NFSv4.x: NFSv3 relies on ancillary protocols--rpcbind (portmapper), mountd, NLM (Network Lock Manager), and NSM (Network Status Monitor)--that are not carried over the TLS-protected connection and are transmitted in the clear. Organizations with compliance requirements that mandate full encryption of storage traffic should account for this when choosing between NFSv3 and NFSv4.x. NFSv4.x eliminates these side-channel protocols; all NFSv4.x traffic is consolidated onto port 2049 and encrypted after the TLS handshake.

NFSv4.x does not use ancillary protocols, so all NFSv4.x RPCs are encrypted after the TLS handshake.

ONTAP terminates TLS at the NFS server on the node currently hosting the LIF. Above the transport, the NFS server processes RPCs identically to a non-TLS NFS connection.

Existing NFS-over-TLS sessions do not survive an HA takeover or unplanned node panic. TLS is a session-level transport built on TCP. When TCP connections drop with the node, the TLS sessions drop with them.

After takeover, clients reconnect and complete a fresh TLS 1.3 handshake. The partner node uses the same replicated TLS configuration—​certificate binding, host-auth setting, and SAN-validation setting—​because the configuration record is replicated cluster-wide.

TLS session tickets and pre-shared keys (PSKs) are node-local and do not transfer to the partner. Expect a reconnect storm with full TLS handshakes on takeover.

The TLS interface certificate and configuration replicate with the SVM via the standard SVM-DR and MetroCluster SVM-level replication path. After an identity-preserve switchover, the destination SVM carries the same per-LIF TLS configuration.

The -allow-nfs-tls-only field on the export-policy rule replicates with the rest of the export-policy rule through the standard export-policy replication path. In SVM-DR, the rule rides with the policy when the policy is replicated with the SVM.