[Libvir] [PATCH] Remote 3/8: Client-side
markmc at redhat.com
Mon May 14 09:44:12 UTC 2007
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.
> 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:
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
Postfix does (3), but not (4). Apache does (4), in a fairly fancy way,
but not (3).
More information about the libvir-list