tlshd links the .nfsd keyring into its session keyring at startup, and the handshake upcall protocol defines attributes for passing a certificate and private key serial number to the server-side handshake. However, the kernel's svc_tcp_handshake() never populates ta_my_cert and ta_my_privkey, so an NFS server has no path to present a certificate stored in the .nfsd keyring; tlshd always falls back to the certificate configured in /etc/tlshd.conf.
Making this work requires kernel changes (an administrative interface for nfsd to select keyring-resident authentication material, and svc_tcp_handshake() filling in the handshake args) in addition to whatever tlshd-side handling is missing. Once it does work, server-side keyring certificates have the same dual/PQ certificate gap tracked in #151.
Observed by Scott Mayhew while triaging the client-side keyring regression:
https://lore.kernel.org/all/afUKzeUYPhb97DX4@aion/
tlshd links the
.nfsdkeyring into its session keyring at startup, and the handshake upcall protocol defines attributes for passing a certificate and private key serial number to the server-side handshake. However, the kernel'ssvc_tcp_handshake()never populatesta_my_certandta_my_privkey, so an NFS server has no path to present a certificate stored in the.nfsdkeyring; tlshd always falls back to the certificate configured in /etc/tlshd.conf.Making this work requires kernel changes (an administrative interface for nfsd to select keyring-resident authentication material, and
svc_tcp_handshake()filling in the handshake args) in addition to whatever tlshd-side handling is missing. Once it does work, server-side keyring certificates have the same dual/PQ certificate gap tracked in #151.Observed by Scott Mayhew while triaging the client-side keyring regression:
https://lore.kernel.org/all/afUKzeUYPhb97DX4@aion/