Re: TLS certificates for NFS-over-TLS floating client

On Wed, 4 Mar 2020 03:15:48 +0000 Rick Macklem rmacklem_at_uoguelph.ca said

> Hi,
> 
> I am slowly trying to understand TLS certificates and am trying to figure
> out how to do the following:
> -> For an /etc/exports file with...
> /home -tls -network 192.168.1.0 -mask 255.255.255.0
> /home -tlscert
> 
> This syntax isn't implemented yet, but the thinking is that clients on the
> 192.168.1 subnet would use TLS, but would not require a certificate.
> For access from anywhere else, the client(s) would be required to have a
> certificate.
> 
> A typical client mounting from outside of the subnet might be my laptop,
> which is using wifi and has no fixed IP/DNS name.
> --> How do you create a certificate that the laptop can use, which the NFS
>       server can trust enough to allow the mount?
> My thinking is that a "secret" value can be put in the certificate that the
> NFS
> server can check for.
> The simplest way would be a fairly long list of random characters in the
> organizationName and/or organizationUnitName field(s) of the subject name.
> Alternately, it could be a newly defined extension for X509v3, I think?
> 
> Now, I'm not sure, but I don't think this certificate can be created via
> a trust authority such that it would "verify". However, the server can
> look for the "secret" in the certificate and allow the mount based on that.
> 
> Does this sound reasonable?
> 
> Also, even if the NFS client/server have fixed IP addresses with well known
> DNS names, it isn't obvious to me how signed certificates can be acquired
> for them?
> (Lets Encrypt expects the Acme protocol to work and that seems to be
> web site/http specific?)
I can only speak to the LetsEncrypt part of your question(s);
There are additional verification methods available beyond www/httpd(s).
But I found in the case of (e)mail; that the cert(s) issued by LetsEncrypt
also work well for all my MXs.

Hope this is helpful!
> 
> Thanks for any help with this, rick
> 
--Chris