I just tried setting up a virtualization host with TLS "auth". I've set up a CA, verified that the certificates are good. I've configured libvirt to listen on a socket and pointed it at the right certificate and key files. When I try to connect from my client (an F11 machine) using either virt-manager or virsh, it fails. The error from virt-manager is this: Unable to open connection to hypervisor URI 'qemu+tls://salusa/system': <class 'libvirt.libvirtError'> unable to connect to 'salusa': Invalid argument None ...on the server side, I see this error in /var/log/messages: 2009-05-16T10:00:32.638817-04:00 salusa libvirtd: remoteCheckCertificate: the client certificate is not trusted. 2009-05-16T10:00:32.638904-04:00 salusa libvirtd: remoteCheckCertificate: failed to verify client's certificate I've tried setting up tls_allowed_dn_list on the server to explicitly allow this cert, but that didn't make any difference. I've also put both client and server in SELinux permissive mode, but that also didn't make any difference. Finally, I tried running libvirtd in the foreground with --verbose set, but that didn't make it log anything more helpful. Attaching my libvirtd.conf file from the server. The cert and key files are all in their default locations.
For the record, I went ahead and used the certtool util to verify the certs: client: $ certtool --verify-chain --infile /etc/pki/libvirt/clientcert.pem --infile /etc/pki/CA/cacert.pem | grep Verif Verification output: Verified. server: $ certtool --verify-chain --infile /etc/pki/libvirt/servercert.pem --infile /etc/pki/CA/cacert.pem | grep Verif Verification output: Verified.
You don't appear to have attached anything as per comment #0. Can you provide * /etc/libvirt/libvirtd.conf * /etc/hosts * Output from 'hostname' command * Full unedited output from LIBVIRT_DEBUG=1 virsh -c qemu+tls://salusa/system * Full log from libvirtd, after settting log_level=1 in libvirtd.conf, and then running LIBVIRT_DEBUG=1 /usr/sbin/libvirtd and stop the log after a connection attempt Also can you also verify that running 'host salusa' returns an IP address, and that then running 'host $IP' returns 'salusa', and that 'salusa' matches the fully qualified hostname configured for the machine as per the 'hostname' command.
Created attachment 344440 [details] server side log
Created attachment 344441 [details] client side log
It turns out that my libvirtd.conf is actually blank once you strip out comments, so I won't bother attaching it. Server-side hostname: # hostname salusa.poochiereds.net # host salusa salusa.poochiereds.net has address 192.168.1.2 # host 192.168.1.2 2.1.168.192.in-addr.arpa domain name pointer salusa.poochiereds.net. Similar results for the client. Certificates being used specify the FQDN's of the client and server.
Created attachment 344442 [details] /etc/hosts from server
Created attachment 344443 [details] libvirtd.conf Actually, I did make a few changes to make it so that I didn't need root privs to run virt-manager locally. Here's what I'm using now. I don't think those changes make much difference in cert handling though.
Ahh, in your initial comment you indicate you're using the URI: 'qemu+tls://salusa/system' Since your hostname is salusa.poochiereds.net, you should be using that in the URI, not the short form. Can you try connecting using 'virsh -c qemu+tls://salusa.poochiereds.net/system'
Created attachment 344444 [details] client side log (connecting to fqdn) Sorry, should have made it clear that I tried that already. The results are the same, here's the client-side log from the fqdn connect attempt.
Hmmm, are the clocks on the client and server hosts in sync with each other ?
Jeff?
Sorry, missed the query before. Yes, clocks are synched between client and server -- the server in this case is an ntp server as well and the client syncs to it.
I have the exactly same problem and after some investigation it seems like a bug somewhere between gnutls and libvirt. Google suggests that TLS might be broken in this case.
We've recently come across an issue that looks very similar to your bug. Did you by chance generate your CA certificate using OpenSSL ? Can you run # certtool -i --infile <CA-CERT-FILE> And paste in the output from the 'Extensions' block. What we expect to see is: Extensions: Basic Constraints (critical): Certificate Authority (CA): TRUE Key Usage (critical): Certificate signing. Subject Key Identifier (not critical): f2a0611cc5f3d8491e225bb215cff6a64192db5f if the extensions field is empty then that would be the cause of this problem.
Haven't played with this in a while so I don't know whether it's still a problem or not... Yes, I did generate my cacert with openssl. Here's the extensions block in the output: Extensions: Basic Constraints (not critical): Certificate Authority (CA): FALSE Unknown extension 2.16.840.1.113730.1.13 (not critical): ASCII: ..OpenSSL Generated Certificate Hexdump: 161d4f70656e53534c2047656e657261746564204365727469666963617465 Subject Key Identifier (not critical): b531b908954ead69b372b42a25a83b940e82f888 Authority Key Identifier (not critical): b531b908954ead69b372b42a25a83b940e82f888
Ok, this is the problem: Certificate Authority (CA): FALSE your CA certificate is claiming that it is not to be used as a CA certificate. GNUTLS enforces this when checking the certificate chains on a connection, hence why its saying "client certificate is not trusted." even though certtool says the cert is valid. So if you re-create your CA cert ensuring is has "Certificate Authority (CA): TRUE", then it will work with libvirt. We have another BZ open about giving a better error message diagnostic for this scenario: https://bugzilla.redhat.com/show_bug.cgi?id=529179