Support for restricting client certificates trusted by server

[bwhacks]

Currently it appears that when the server is configured with "xprtsec=mtls", any client certificate issued by any CA in the system trust store will be accepted. I would guess that this is not what administrators would want from client authentication.

I would expect to be able to configure a server to trust only client certificates issued by a specific CA (perhaps an internal CA) and/or client certificates for hostnames with a specific domain. But it possibly makes sense to allow specifying required values for all of the standard subject fields.

[chucklever]

I would expect to be able to configure a server to trust only client certificates issued by a specific CA (perhaps an internal CA)

We have in the past discussed how to provide a particular narrow trust chain for kernel TLS consumers. This is particularly interesting if the server's certificate is self-signed.

• I think it would be possible, as a first pass, to specify a pathname to a bundle file in tlshd.conf.
• Alternatively, we can set up a keyring with the CA bundle on it, and pass that keyring's serial to tlshd for each handshake. That enables, say, each export to use it's own specific bundle.

I can discuss this feature request with our team.

and/or client certificates for hostnames with a specific domain.

So we would combine /etc/netgroup-style checking with certificate checking? Can you elaborate?

But it possibly makes sense to allow specifying required values for all of the standard subject fields.

This starts to make the export administrative interface quite unwieldy. I would need to see use cases to understand exactly what is required.

[bwhacks]

I would expect to be able to configure a server to trust only client certificates issued by a specific CA (perhaps an internal CA)

We have in the past discussed how to provide a particular narrow trust chain for kernel TLS consumers. This is particularly interesting if the server's certificate is self-signed.

• I think it would be possible, as a first pass, to specify a pathname to a bundle file in tlshd.conf.

That sounds good.

• Alternatively, we can set up a keyring with the CA bundle on it, and pass that keyring's serial to tlshd for each handshake. That enables, say, each export to use it's own specific bundle.

I don't know enough about keyrings to comment on this.

I can discuss this feature request with our team.

and/or client certificates for hostnames with a specific domain.

So we would combine /etc/netgroup-style checking with certificate checking? Can you elaborate?

As an example, I use something like this for SMTP among the computers in my own domain:

• I get a certificate for each of them. This could be done with a private CA but I use Let's Encrypt. For those that aren't public servers, I use the dns-01 challenge method.
• I configure exim on each computer to use this as a client certificate when sending over TLS.
• On the mail server, I allow relaying mail from clients that present a certificate (from any trusted CA, I think) with a name under my domain.
• Everywhere else, I configure exim to use that mail server as a smarthost with TLS required.

I could imagine some organisations wanting to authenticate NFS clients in a similar way. But I'm not a real sysadmin and I might have just invented something weird. :-)

But it possibly makes sense to allow specifying required values for all of the standard subject fields.

This starts to make the export administrative interface quite unwieldy. I would need to see use cases to understand exactly what is required.

Right, the problem is I don't think there's an established standard for how to validate client certificates. (Aside from: run your own CA and only trust certificates from that one.) So I don't know what options are actually needed!

[chucklever]

and/or client certificates for hostnames with a specific domain.

So we would combine /etc/netgroup-style checking with certificate checking? Can you elaborate?

As an example, I use something like this for SMTP among the computers in my own domain:

• I get a certificate for each of them. This could be done with a private CA but I use Let's Encrypt. For those that aren't public servers, I use the dns-01 challenge method.
• I configure exim on each computer to use this as a client certificate when sending over TLS.
• On the mail server, I allow relaying mail from clients that present a certificate (from any trusted CA, I think) with a name under my domain.
• Everywhere else, I configure exim to use that mail server as a smarthost with TLS required.

I could imagine some organisations wanting to authenticate NFS clients in a similar way. But I'm not a real sysadmin and I might have just invented something weird. :-)

The Linux NFS server has /etc/exports settings that allow filtering client access via IP address. That is a separate security policy mechanism that could be used in combination with certificate verification to achieve similar results, I would think.

[bwhacks]

The Linux NFS server has /etc/exports settings that allow filtering client access via IP address. That is a separate security policy mechanism that could be used in combination with certificate verification to achieve similar results, I would think.

I don't think that's particularly useful. If access to the network is strictly controlled then it could work but TLS is not really needed. If access to the network is not so well controlled, an attacker could attach their own device with an arbitrary client certificate for NFS, which would be accepted.

[chucklever]

If access to the network is strictly controlled then it could work but TLS is not really needed.

That's arguable. For instance, an RPC-with-TLS certificate can contain instructions to treat all RPCs from a particular client as coming from a specific AUTH_SYS user. TLS encryption can still protect against snooping by other clients, even if the server trusts those clients.

If access to the network is not so well controlled, an attacker could attach their own device with an arbitrary client certificate for NFS, which would be accepted.

I thought that was what the chain of trust was for? The server's client certificate verification process would prevent access by a client with an unrecognized signer, even if that client has an allowed IP address.