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.
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"
