Nenhuma chamada de saída para uma Autoridade Certificadora (CA) externa ou respondedor OCSP é feita a partir do caminho de handshake TLS do NFS na versão 9.19.1. A validação da cadeia e do Subject Alternative Name (SAN) é realizada localmente em relação ao material de certificado instalado no SVM.

Tanto o NFSv3 quanto o NFSv4 criptografam toda a carga NFS após o primeiro par de chamada/resposta NULL para a porta TCP 2049. A chamada NULL possui o novo AUTH_TLS tipo de credencial definido na RFC 9289, que sinaliza a intenção do cliente de usar TLS. O servidor responde com uma resposta NULL que aceita ou rejeita a atualização para TLS. Se o cliente receber aceitação, ele prossegue com o handshake TLS 1.3 na mesma conexão TCP. Se o handshake for concluído com sucesso, todas as chamadas RPC NFS subsequentes são encapsuladas em registros TLS e criptografadas em trânsito.

Existe uma diferença entre NFSv3 e NFSv4.x: o NFSv3 depende de protocolos auxiliares -rpcbind (portmapper), mountd, NLM (Network Lock Manager) e NSM (Network Status Monitor), que não são transmitidos pela conexão protegida por TLS e são enviados em texto não criptografado. Organizações com requisitos de conformidade que exigem criptografia total do tráfego de armazenamento devem considerar isso ao escolher entre NFSv3 e NFSv4.x. O NFSv4.x elimina esses protocolos de canal lateral; todo o tráfego NFSv4.x é consolidado na porta 2049 e criptografado após o handshake TLS.

O NFSv4.x não utiliza protocolos auxiliares, portanto, todas as RPCs do NFSv4.x são criptografadas após o handshake TLS.

ONTAP encerra o TLS no servidor NFS do nó que atualmente hospeda a LIF. Acima da camada de transporte, o servidor NFS processa as chamadas de procedimento remoto (RPCs) de forma idêntica a uma conexão NFS sem TLS.

Sessões NFS sobre TLS existentes não sobrevivem a uma transição de alta disponibilidade (HA) ou a um pânico inesperado de nó. TLS é um transporte em nível de sessão construído sobre TCP. Quando as conexões TCP caem com o nó, as sessões TLS caem junto.

Após a aquisição, os clientes se reconectam e realizam um novo handshake TLS 1.3. O nó parceiro utiliza a mesma configuração TLS replicada — vinculação de certificado, configuração de autenticação de host e configuração de validação SAN — porque o registro de configuração é replicado em todo o cluster.

Os tickets de sessão TLS e as chaves pré-compartilhadas (PSKs) são locais ao nó e não são transferidos para o parceiro. Espere uma tempestade de reconexões com handshakes TLS completos na tomada de controle.

O certificado da interface TLS e a configuração são replicados com a SVM por meio do caminho de replicação padrão SVM-DR e de replicação em nível de SVM do MetroCluster. Após um switchover com preservação de identidade, a SVM de destino mantém a mesma configuração TLS por LIF.

O -allow-nfs-tls-only campo na regra de política de exportação é replicado juntamente com o restante da regra de política de exportação pelo caminho padrão de replicação de política de exportação. No SVM-DR, a regra acompanha a política quando a política é replicada com o SVM.