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

Rick Macklem wrote:
>Benjamin Kaduk wrote:
>>Rick Macklem wrote:
[stuff snipped]
>>> 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?
>>
>>You can give your laptop a certificate for an arbitrary name, provided that
>>the NFS server knows to "validate" that name in an appropriate fashion.  (I
>>don't remember what draft-ietf-nfsv4-rpc-tls says about this validation.)
The draft seems to just refer to RFC5280 and it seems to allow a local CA
(Page 12, 2nd (a) section on page). It does not seem to specify details w.r.t.
validation beyond that.

>As you note below, creating a site local CA is probably appropriate and the
>server should be able to check that the certificates were signed by this.
>(I haven't quite figured out how to do this yet. I think I've created the CA
>and used to sign a client certificate, but haven't yet gotten the server daemon
>to verify it. (Playing with SSL_set_verify_locations() to try to get it to work.;-)
Just fyi, I got this working. My mistake yesterday was that I created a certificate
for the client that had a SubjectName identical to the IssuerName. It happened
because I test on one machine (client and server) and I used the hostname as
the CN.
--> This resulted in SSL_get_verify_results() returning "self-signed".

Once I created a client certificate with a different CN in the SubjectName, it
validated ok.

Thanks everyone for your help sofar, rick

>> 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?
>
>It would be better to just make a site-local CA and trust everything it
>issues (which, admittedly, is not the greatest option itself.)
I had thought this would be too much work, but it seems fairly straightforward,
so this is what I am now working on.

>> 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?
>
>I'm not sure what goal you're trying to achieve by this "security through
>obscurity".
Yes. I now see it is the CA stuff that can stay secret.

>> 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?)
>
>RFC 8738 specifies the ACME protocol for validating IP addresses.
I had looked at an older RFC, where it seemed to be web site specific.
Since none of my stuff has fixed well known DNS names, I'm not going to
worry about using an established CA for now.

Thanks to everyone for their comments.
I may respond to some of the other posts, but I'm figuring things out for now.

rick

-Ben
_______________________________________________
freebsd-current_at_freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"