Date: Tue, 03 Mar 2020 23:26:36 -0800 From: Chris <bsd-lists@BSDforge.com> To: <freebsd-current@FreeBSD.org> Subject: Re: TLS certificates for NFS-over-TLS floating client Message-ID: <b9e34a9fdbaf094675d8266121351086@udns.ultimatedns.net> In-Reply-To: <20200304.133515.520383339344620673.hrs@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 04 Mar 2020 13:35:15 +0900 (JST) Hiroki Sato hrs@FreeBSD=2Eorg said
> Rick Macklem <rmacklem@uoguelph=2Eca> wrote
> in
> <YTBPR01MB3374EFF14948CB8FEA1B5CCDDDE50@YTBPR01MB3374=2ECANPRD01=2EPROD=2EOUTLO=
OK=2ECOM>:
>=20
> rm> Hi,
> rm>
> rm> I am slowly trying to understand TLS certificates and am trying to
> figure
> rm> out how to do the following:
> rm> -> For an /etc/exports file with=2E=2E=2E
> rm> /home -tls -network 192=2E168=2E1=2E0 -mask 255=2E255=2E255=2E0
> rm> /home -tlscert
> rm>
> rm> This syntax isn't implemented yet, but the thinking is that clients o=
n
> the
> rm> 192=2E168=2E1 subnet would use TLS, but would not require a certificate=2E
> rm> For access from anywhere else, the client(s) would be required to hav=
e a
> rm> certificate=2E
> rm>
> rm> A typical client mounting from outside of the subnet might be my lapt=
op,
> rm> which is using wifi and has no fixed IP/DNS name=2E
> rm> --> How do you create a certificate that the laptop can use, which th=
e
> NFS
> rm> server can trust enough to allow the mount?
> rm> My thinking is that a "secret" value can be put in the certificate th=
at
> the NFS
> rm> server can check for=2E
>=20
> I do not think it is a good idea to use a certificate with an
> embedded secret for authentication and/or authorization=2E
>=20
> In the case that the client offers a certificate upon establishing a
> TLS connection for authentication purpose, the authenticity will be
> checked on the server usually by using the CA certificate which was
> used to issue the client certificate=2E The CA cert must be put to
> somewhere the NFS server can read=2E
>=20
> The CA cert is secret=2E So if the NFS server can check the client
> certificate by the CA certificate, it means the NFS server can
> trust the client=2E I think no additional information is required=2E
>=20
> Authorization such as which mount point can be mounted by using the
> client cert can be implemented by using the CN field or other X=2E509
> attributes, of course=2E It can be just a clear text=2E
>=20
> I think this is one of the most reliable and straightforward ways
> because in most cases both NFS servers and the clients are under the
> sysadmin's control=2E
>=20
> rm> Now, I'm not sure, but I don't think this certificate can be created =
via
> rm> a trust authority such that it would "verify"=2E However, the server ca=
n
> rm> look for the "secret" in the certificate and allow the mount based on
> that=2E
>=20
> In the way described above, to use TLS client authentication, the NFS
> server admin has to have a certificate which allows to sign another
> certificate=2E This means that the admin must be a CA or trusted
> authority=2E
>=20
> In practice, one can generate a self-signed certificate by using
> openssl(1) and use it as its CA certificate=2E He can issue
> certificates signed by it for the NFS clients, and put his CA
> certificate to somewhere the NFS server can read=2E
>=20
> rm> Also, even if the NFS client/server have fixed IP addresses with well
> known
> rm> DNS names, it isn't obvious to me how signed certificates can be
> acquired
> rm> for them?
> rm> (Lets Encrypt expects the Acme protocol to work and that seems to be
> rm> web site/http specific?)
>=20
> TLS certificates do not always have (or do not need to have) a domain
> name as an attribute=2E Data in attributes are restricted depending on
> the purpose, so certificates issued by Let's Encrypt can have only
> domain names (CN or Subject Alternative Name), for example=2E An
> example which is not supported by Let's Encrypt is a certificate for
> S/MIME email encryption which has an email address=2E
FWIW here's an example from the headers coming from this list=2E
Received: from mx1=2Efreebsd=2Eorg (mx1=2Efreebsd=2Eorg [96=2E47=2E72=2E80])
(using TLSv1=2E3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
(Client CN "mx1=2Efreebsd=2Eorg", Issuer "Let's Encrypt Authority X3" (veri=
fied OK))
by mx2=2Efreebsd=2Eorg (Postfix) with ESMTPS id 1B07B7E9A8;
Wed, 4 Mar 2020 04:37:12 +0000 (UTC)
(envelope-from owner-freebsd-current@freebsd=2Eorg)
Not sure if it would help with your intent here=2E But there it is=2E :)
--Chris
>=20
> -- Hiroki
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b9e34a9fdbaf094675d8266121351086>