Re: [Libvir] [PATCH] Remote 3/8: Client-side
On Mon, 2007-05-14 at 10:01 +0100, Richard W.M. Jones wrote:
Mark McLoughlin wrote:
>> Note that libvirtd _doesn't_ quite support this sort of access because
>> it doesn't support wildcards in the commonNames in the client
>> certificates, but that would be a useful and simple addition.
>
> I don't grok this ... why would you want a wildcard in the subjectName
> of a client certificate?
>
> Or do you mean allowing wildcards in the access control list of client
> subjectNames?
At the moment: The server reliably knows only the IP address of the client.
It is given a certificate by the client, which it checks for validity
against the CA.
Yep.
It also checks the subjectAltName.iPAddress or
commonName field is the IP address (just using strcmp).
I don't think this is useful or good practice.
The IP address of the client is irrelevant, ignore it. Think about
clients connecting from behind NAT, for example.
It may also check that the client's IP address is on a whitelist
contained in the server configuration file, although by default this
check is switched off.
And this has nothing to do with TLS or X.509 certificates. It's no
different from e.g. libwrap.
So you can set up a CA and issue certificates to your clients to
control
access, but the certificates must contain the right IP address for the
client (the client cannot be mobile in other words).
Again, I don't think this is useful.
This weekend I was coincidentally looking at how client certification
works in browsers, and there authentication is based on all fields in
the Distinguished Name. So you can use any CA, and an access control
list of clients held on the server. See for example:
http://www.modssl.org/docs/2.8/ssl_howto.html#auth-particular
This looks essentially like a list of strings which will be compared
against the SubjectName field in certificates presented by clients.
It looks like it requires that the contents of the SubjectName is an
X.500 DN, which is probably sane, and allows matching against individual
fields in the DN which is similar to wildcards.
I think this is just another confirmation of what I was saying would be
a sane way to do this:
1) Validate the cert was issued by a trusted CA, deny if no
2) Ignore the IP address of client
3) First check whether the cert fingerprint is on the list of allowed
client fingerprints, allow if yes
4) Otherwise check whether the contents of the SubjectName name field
is on the list of allowed client SubjectNames, allow if yes, deny
if no
Postfix does (3), but not (4). Apache does (4), in a fairly fancy way,
but not (3).
Cheers,
Mark.