RPC.TLSCLNTD(8)

💅 RPC.TLSCLNTD — Sun RPC over TLS Client Daemon

okay so real talk, this is a page from the System Manager's Manual (section 8, the daemon zone 👑), and it's literally the manual for rpc.tlsclntd. bestie, if you're mounting NFS over TLS, this is the girl doing the handshake. let's get into it 🎀

✨ SYNOPSIS ✨

rpc.tlsclntd [-2] [-C available_ciphers] [-D certdir] [-d] [-l CAfile]
             [-m] [-p CApath] [-r CRLfile] [-v]

---

🦋 DESCRIPTION 🦋

So rpc.tlsclntd is the daemon that does the client side of the kernel Sun RPC over TLS implementation. no cap, this daemon must be running for the kernel RPC to be able to make a TLS connection to a server for an NFS over TLS mount. like, it's not optional. it's the main character of this operation 💅

couple of hard requirements, and I mean hard:

• the kernel needs to be built with options KERNEL_TLS, and
• it has to be running on an architecture such as amd64 that supports a direct map (not i386), with ktls(4) enabled.

now, the certificate tea ☕ — if either the -l or -p option has been specified, the daemon will require the server's certificate to verify and have a Fully Qualified Domain Name (FQDN) in it. that FQDN has to match the reverse DNS name for the IP address the server is using for the TCP connection. it can live in either the DNS field of the subjectAltName or the CN field of the subjectName in the certificate — but it cannot have a wildcard * in it. not even a little one. 🚫

SIGHUP behavior (iykyk): if a SIGHUP signal gets sent to the daemon, it will reload the CRLfile and will shut down any extant connections that presented certificates during the TLS handshake that have been revoked. and if the -r option was not specified? the SIGHUP signal just gets ignored. she's unbothered. 🙈

also, the daemon logs failed certificate verifications via syslogd(8) using LOG_INFO | LOG_DAEMON when the -l or -p option has been specified.

now the options, bestie, and there are nine of them so stay with me 🫶

---

🌸 OPTIONS 🌸

• -2, --usetls1_2 — specify the use of TLS version 1.2. by default the client uses TLS version 1.3, as required by the RFC — iconic, correct, standards-compliant. but early FreeBSD (13.0 and 13.1) servers require this option, since they only support TLS version 1.2. legacy vibes only 😭
• -C available_ciphers, --ciphers=available_ciphers — specify which ciphers are available during the TLS handshake. if you use this, SSL_CTX_set_ciphersuites() gets called with available_ciphers as the argument. if you don't, the cipher will be chosen by ssl(7), which should be adequate for most cases. the format for the available ciphers is a simple : separated list, in order of preference. and the command openssl ciphers -s -tls1_3 lists available ciphers. use it, queen. 🔥
• -D certdir, --certdir=certdir — use certdir instead of /etc/rpc.tlsclntd for the -m option.
• -d, --debuglevel — run in debug mode. in this mode, rpc.tlsclntd will not fork when it starts. she stays right there with you 💖
• -l CAfile, --verifylocs=CAfile — specifies the path name of a CAfile which holds the information for server certificate verification. this path name is used in the SSL_CTX_load_verify_locations(ctx,CAfile,NULL) and SSL_CTX_set0_CA_list(ctx,SSL_load_client_CA_file(CAfile)) openssl library calls. important note: this is a path name for the file and is not assumed to be in certdir. read that again 🫠
• -m, --mutualverf — enable support for mutual authentication. a certificate and associated key must be found in /etc/rpc.tlsclntd (or the directory specified by the -D option) in case a server requests a peer certificate. the first certificate needs to be in a file named cert.pem and the associated key in a file named certkey.pem. the mount_nfs(8) option -tlscertname can be used to override the default certificate for a given NFS mount, where the files use the alternate naming specified by the option. if there's a passphrase on the certkey.pem file, this daemon will prompt for the passphrase during startup. and the keys for alternate certificates cannot have passphrases. rules are rules 🎀
• -p CApath, --verifydir=CApath — similar to the -l option, but specifies the path of a directory with CA certificates in it. when this option is used, SSL_CTX_set0_CA_list(ctx,SSL_load_client_CA_file()) is not called, so a list of CA names is not passed to the server during the TLS handshake. the openssl documentation indicates this call is rarely needed. so like, no stress 💜
• -r CRLfile, --crl=CRLfile — specifies a Certificate Revocation List (CRL) file that is to be loaded into the verify certificate store and checked during verification of the server's certificate. ⚠️ this option is meaningless unless either the -l or -p have been specified. like it literally does nothing on its own.
• -v, --verbose — run in verbose mode. in this mode, rpc.tlsclntd will log activity messages to syslog using LOG_INFO | LOG_DAEMON, or to stderr if the -d option has also been specified. chatty and proud 🗣️

---

⭐ EXIT STATUS ⭐

the rpc.tlsclntd utility exits 0 on success, and >0 if an error occurs. simple as that, periodt.

---

🌈 SEE ALSO 🌈

openssl(1), ktls(4), ssl(7), mount_nfs(8), rpc.tlsservd(8), syslogd(8)

go read them, they're all bangers, fr fr 📚

---

👑 STANDARDS 👑

the implementation is based on the specification in "Towards Remote Procedure Call Encryption By Default", RFC 9289. she's certified, she's legit ✨

---

🧚 HISTORY 🧚

the rpc.tlsclntd manual page first appeared in FreeBSD 13.0. a legend was born 💫

---

💀 BUGS 💀

okay this one's serious, listen up:

This daemon cannot be safely shut down and restarted if there are any active RPC-over-TLS connections. doing so will orphan the KERNEL_TLS connections, so that they can no longer do upcalls successfully, since the SSL * structures in userspace have been lost. 😭

so like, don't do that. the SSL * structures are gone and they're not coming back. genuinely do not hit restart on her while she's working 🙏

---

that's the whole page bestie, you're officially fluent in rpc.tlsclntd 🎀 this beauty comes to you from the Debian crew — dated September 23, 2022 — and it lives at the very bottom of the page as RPC.TLSCLNTD(8). mwah 💋