[Libvir] [PATCH] Remote 3/8: Client-side

Richard W.M. Jones rjones at redhat.com
Tue May 8 11:20:17 UTC 2007

Daniel P. Berrange wrote:
> On Sat, May 05, 2007 at 12:17:44PM +0100, Richard W.M. Jones wrote:
>> (1) remoteOpen and associated, GnuTLS initialisation
> I've got a question about this comment
>         /* XXX This loop contains a subtle problem.  In the case
>          * where a host is accessible over IPv4 and IPv6, it will
>          * try the IPv4 and IPv6 addresses in turn.  However it
>          * should be able to present different client certificates
>          * (because the commonName field in a client cert contains
>          * the client IP address, which is different for IPv4 and
>          * IPv6).  At the moment we only have a single client
>          * certificate, and no way to specify what address family
>          * that certificate belongs to.
>          */
> It is my understanding that the 'commonName' should be the public user
> facing name of the server. eg, if the user is accessing
>    https://foo.example.com/
> Then commonName in the certificate would be 'foo.example.com'. The commonName
> should be verified against the user supplied address, which in this case
> would also be  foo.example.com.

Right, but this comment is about the client's certificate which is 
presented to and checked by the server.

The server knows only the IP address of the client (well, it could do a 
DNS PTR lookup, but it shouldn't trust the results since they are under 
the control of the client too!)

But what is the real solution here?  Either allow the client to have 
multiple certificates (of course marked as IPv4 or IPv6 certificates, 
and perhaps other namespaces too?!), or else do some name-mangling so 
that IPv4 and IPv6 addresses can be compared, prepending or removing 
::ffff: as appropriate?


More information about the libvir-list mailing list