Date: Thu, 19 Mar 2020 02:09:08 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Miroslav Lachman <000.fbsd@quip.cz>, Hiroki Sato <hrs@FreeBSD.org> Cc: "freebsd-current@FreeBSD.org" <freebsd-current@FreeBSD.org> Subject: Re: TLS certificates for NFS-over-TLS floating client Message-ID: <YTBPR01MB3374BB2A3ED8435FFEDEA18EDDF40@YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <c07496fe-357d-43c6-86fb-17b04e60ea26@quip.cz> References: <YTBPR01MB3374EFF14948CB8FEA1B5CCDDDE50@YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM> <20200304.133515.520383339344620673.hrs@FreeBSD.org>, <c07496fe-357d-43c6-86fb-17b04e60ea26@quip.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
Miroslav Lachman wrote:=0A= >Hiroki Sato wrote on 2020/03/04 05:35:=0A= >=0A= [...]=0A= >=0A= >> I do not think it is a good idea to use a certificate with an=0A= >> embedded secret for authentication and/or authorization.=0A= >>=0A= >> In the case that the client offers a certificate upon establishing a= =0A= >> TLS connection for authentication purpose, the authenticity will be=0A= >> checked on the server usually by using the CA certificate which was=0A= >> used to issue the client certificate. The CA cert must be put to=0A= >> somewhere the NFS server can read.=0A= >>=0A= >> The CA cert is secret. So if the NFS server can check the client=0A= >> certificate by the CA certificate, it means the NFS server can=0A= >> trust the client. I think no additional information is required.=0A= >=0A= >NFS (or any other server) should check list of revoked certificates too.= =0A= >Otherwise you will not be able to deny access to user which you no=0A= >longer want to have an access.=0A= Yes, good point.=0A= I won't claim to understand this stuff, but from what I can see, all that i= s=0A= done is the CRL is appended to the CAfile (the one with the CA certificates= =0A= are in being used for certificate verification via SSL__CTX_load_verify_loc= ations().=0A= (https://raymii.org/s/articles/OpenSSL_manually_verify_a_certificate_agains= t_a_CRL.html=0A= shows a CAfile and CRLfile being concatenated and then used to verify a cer= tificate.)=0A= =0A= There is code in sendmail that loads a CRL file separately, but it seems to= =0A= just put it in the X509 store returned by SSL_CTX_get_cert_store(), which= =0A= is the one where the CAfile certificates are stored via SSL_CTX_load_verify= _locations(),=0A= I think?=0A= (It just seems easier to append it to CAfile than do this. The sendmail cod= e uses=0A= poorly documented functions where the man page says=0A= "SSL_CTX_load_verify_locations()" normally takes care of this.)=0A= =0A= Does this sound right? rick=0A= =0A= > Authorization such as which mount point can be mounted by using the=0A= > client cert can be implemented by using the CN field or other X.509=0A= > attributes, of course. It can be just a clear text.=0A= >=0A= > I think this is one of the most reliable and straightforward ways=0A= > because in most cases both NFS servers and the clients are under the=0A= > sysadmin's control.=0A= >=0A= > rm> Now, I'm not sure, but I don't think this certificate can be created = via=0A= > rm> a trust authority such that it would "verify". However, the server ca= n=0A= > rm> look for the "secret" in the certificate and allow the mount based on= that.=0A= >=0A= > In the way described above, to use TLS client authentication, the NFS= =0A= > server admin has to have a certificate which allows to sign another=0A= > certificate. This means that the admin must be a CA or trusted=0A= > authority.=0A= >=0A= > In practice, one can generate a self-signed certificate by using=0A= > openssl(1) and use it as its CA certificate. He can issue=0A= > certificates signed by it for the NFS clients, and put his CA=0A= > certificate to somewhere the NFS server can read.=0A= =0A= Take a look on easy-rsa=0A= https://www.freshports.org/security/easy-rsa/=0A= =0A= It is used for example by OpenVPN to create private CA and sign=0A= certificates of clients. It is good starting point to understand what=0A= and how can work.=0A= =0A= > rm> Also, even if the NFS client/server have fixed IP addresses with well= known=0A= > rm> DNS names, it isn't obvious to me how signed certificates can be acqu= ired=0A= > rm> for them?=0A= > rm> (Lets Encrypt expects the Acme protocol to work and that seems to be= =0A= > rm> web site/http specific?)=0A= >=0A= > TLS certificates do not always have (or do not need to have) a domain= =0A= > name as an attribute. Data in attributes are restricted depending on= =0A= > the purpose, so certificates issued by Let's Encrypt can have only=0A= > domain names (CN or Subject Alternative Name), for example. An=0A= > example which is not supported by Let's Encrypt is a certificate for=0A= > S/MIME email encryption which has an email address.=0A= =0A= Kind regards=0A= Miroslav Lachman=0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTBPR01MB3374BB2A3ED8435FFEDEA18EDDF40>