Miroslav Lachman wrote: >Hiroki Sato wrote on 2020/03/04 05:35: > [...] > >> I do not think it is a good idea to use a certificate with an >> embedded secret for authentication and/or authorization. >> >> 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. The CA cert must be put to >> somewhere the NFS server can read. >> >> The CA cert is secret. So if the NFS server can check the client >> certificate by the CA certificate, it means the NFS server can >> trust the client. I think no additional information is required. > >NFS (or any other server) should check list of revoked certificates too. >Otherwise you will not be able to deny access to user which you no >longer want to have an access. Yes, good point. I won't claim to understand this stuff, but from what I can see, all that is done is the CRL is appended to the CAfile (the one with the CA certificates are in being used for certificate verification via SSL__CTX_load_verify_locations(). (https://raymii.org/s/articles/OpenSSL_manually_verify_a_certificate_against_a_CRL.html shows a CAfile and CRLfile being concatenated and then used to verify a certificate.)
There is code in sendmail that loads a CRL file separately, but it seems to just put it in the X509 store returned by SSL_CTX_get_cert_store(), which is the one where the CAfile certificates are stored via SSL_CTX_load_verify_locations(), I think? (It just seems easier to append it to CAfile than do this. The sendmail code uses poorly documented functions where the man page says "SSL_CTX_load_verify_locations()" normally takes care of this.) Does this sound right? rick > 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.509 > attributes, of course. It can be just a clear text. > > 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. > > 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". However, the server can > rm> look for the "secret" in the certificate and allow the mount based on > that. > > 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. This means that the admin must be a CA or trusted > authority. > > In practice, one can generate a self-signed certificate by using > openssl(1) and use it as its CA certificate. He can issue > certificates signed by it for the NFS clients, and put his CA > certificate to somewhere the NFS server can read. Take a look on easy-rsa https://www.freshports.org/security/easy-rsa/ It is used for example by OpenVPN to create private CA and sign certificates of clients. It is good starting point to understand what and how can work. > 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?) > > TLS certificates do not always have (or do not need to have) a domain > name as an attribute. 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. An > example which is not supported by Let's Encrypt is a certificate for > S/MIME email encryption which has an email address. Kind regards Miroslav Lachman _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
