Re: TLS certificates for NFS-over-TLS floating client

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