[libvirt] Using TLS with chained certs?
I've got a setup where a given cert (for a machine) is issued randomly by one of three CA's, all of which are signed by a root CA. When using this with libvirt, it will refuse to start if the cert is signed by a CA other than the top one in the /etc/pki/CA/cacert.pem file, and if the client cert is issued by a different CA than the server cert (quite the possibility), then obviously that connection is rejected. It looks like in src/rpc/virnettlscontext.c we're using gnutls_x509_crt_import() instead of gnutls_x509_crt_list_import() which would account for this behavior.
On 07/18/2013 02:19 PM, Jon Stanley wrote:
I've got a setup where a given cert (for a machine) is issued randomly by one of three CA's, all of which are signed by a root CA.
When using this with libvirt, it will refuse to start if the cert is signed by a CA other than the top one in the /etc/pki/CA/cacert.pem file, and if the client cert is issued by a different CA than the server cert (quite the possibility), then obviously that connection is rejected.
It looks like in src/rpc/virnettlscontext.c we're using gnutls_x509_crt_import() instead of gnutls_x509_crt_list_import() which would account for this behavior.
Are you able to propose a patch to use the better interface? -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Thu, Jul 18, 2013 at 04:19:02PM -0400, Jon Stanley wrote:
I've got a setup where a given cert (for a machine) is issued randomly by one of three CA's, all of which are signed by a root CA.
When using this with libvirt, it will refuse to start if the cert is signed by a CA other than the top one in the /etc/pki/CA/cacert.pem file, and if the client cert is issued by a different CA than the server cert (quite the possibility), then obviously that connection is rejected.
It looks like in src/rpc/virnettlscontext.c we're using gnutls_x509_crt_import() instead of gnutls_x509_crt_list_import() which would account for this behavior.
This is a known limitation that I'm working on fixing. It is not quite as simple as just replacing the method call, because it has ripple effects into other areas of code, and also neeeds to have some significant test coverage added. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Fri, Jul 19, 2013 at 5:02 AM, Daniel P. Berrange <berrange@redhat.com> wrote:
This is a known limitation that I'm working on fixing. It is not quite as simple as just replacing the method call, because it has ripple effects into other areas of code, and also neeeds to have some significant test coverage added.
Yeah, I could imagine. I'm not the best C programmer in the world (if libvirt were only in Python..... :D), so I'm afraid that my ability to offer up a patch is limited. Since you're working on it, I'd obviously be very interested in testing any code that you may need tested :)
participants (3)
-
Daniel P. Berrange -
Eric Blake -
Jon Stanley