From owner-freebsd-current@freebsd.org Wed Mar 4 03:26:24 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9210F263204 for ; Wed, 4 Mar 2020 03:26:24 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 48XK6Q5Lwlz4bWX for ; Wed, 4 Mar 2020 03:26:22 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by udns.ultimatedns.net (8.15.2/8.15.2) with ESMTPS id 0243Qk6m024178 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 3 Mar 2020 19:26:53 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 Cc: In-Reply-To: From: Chris Reply-To: bsd-lists@BSDforge.com To: Rick Macklem Subject: Re: TLS certificates for NFS-over-TLS floating client Date: Tue, 03 Mar 2020 19:26:53 -0800 Message-Id: <4f1119e2d61d50fedc99b223fe8681d3@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 48XK6Q5Lwlz4bWX X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of bsd-lists@BSDforge.com has no SPF policy when checking 24.113.41.81) smtp.mailfrom=bsd-lists@BSDforge.com X-Spamd-Result: default: False [-1.34 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[bsd-lists@BSDforge.com]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.981,0]; IP_SCORE(-0.27)[ip: (-0.50), ipnet: 24.113.0.0/16(-0.25), asn: 11404(-0.57), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[BSDforge.com]; REPLYTO_ADDR_EQ_FROM(0.00)[]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-0.99)[-0.993,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2020 03:26:24 -0000 On Wed, 4 Mar 2020 03:15:48 +0000 Rick Macklem rmacklem@uoguelph=2Eca said > Hi, >=20 > 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=2E=2E=2E > /home -tls -network 192=2E168=2E1=2E0 -mask 255=2E255=2E255=2E0 > /home -tlscert >=20 > This syntax isn't implemented yet, but the thinking is that clients on th= e > 192=2E168=2E1 subnet would use TLS, but would not require a certificate=2E > For access from anywhere else, the client(s) would be required to have a > certificate=2E >=20 > A typical client mounting from outside of the subnet might be my laptop, > which is using wifi and has no fixed IP/DNS name=2E > --> How do you create a certificate that the laptop can use, which the NF= S > server can trust enough to allow the mount? > My thinking is that a "secret" value can be put in the certificate that t= he > NFS > server can check for=2E > The simplest way would be a fairly long list of random characters in the > organizationName and/or organizationUnitName field(s) of the subject name= =2E > Alternately, it could be a newly defined extension for X509v3, I think? >=20 > Now, I'm not sure, but I don't think this certificate can be created via > a trust authority such that it would "verify"=2E However, the server can > look for the "secret" in the certificate and allow the mount based on tha= t=2E >=20 > Does this sound reasonable? >=20 > Also, even if the NFS client/server have fixed IP addresses with well kno= wn > 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)=2E But I found in the case of (e)mail; that the cert(s) issued by LetsEncrypt also work well for all my MXs=2E Hope this is helpful! >=20 > Thanks for any help with this, rick >=20 --Chris