Description of problem: virsh has a fixed location list where it searches for CA certificates, system-wide database at /etc/pki/nssdb unfortunately does not to be one of those places. Version-Release number of selected component (if applicable): libvirt-client-0.9.10-9.el6.x86_64 How reproducible: always Steps to Reproduce: 1. configure libvirtd to listen on tls port, add necessary client cert/keys 2. add CA used to sign libvirt host cert to nss trust store on the client: certutil -A -d /etc/pki/nssdb -n "<custom CA name>" -t "CT,C,C" -i <ca_file> 3. connect to the host: virsh -c qemu+tls://<host>/system Actual results: virsh complains about missing CA: error: Cannot read CA certificate '/etc/pki/CA/cacert.pem': No such file or directory error: failed to connect to the hypervisor Expected results: virsh finds CA cert in nss as trusted and uses it Additional info: * there is also per-user store at ~/.pki/nssdb * probably, the client cert could be also retrieved from nssdb but I don't know nss enough to tell this for sure * if virt-viewer does not share the code in question with virsh, the bug should also be cloned to it
libvirt does *not* use NSS for its PKI support, so IMHO it is not appropriate to look in NSS directories for configuration.
After looking a bit deeper (and some conversation with tmraz), the issue is that there is no centralized place for CA certificates with some means of distinction of what a specific CA can be trusted. It's well known however and targeted for 6.4 to be finally fixed: https://bugzilla.redhat.com/show_bug.cgi?id=544376 Based on that, I'm keeping this open and targeted for 6.4, making subject more accurate and making this bug depend on bug above.
This is not the only problem. The "certificate" stuff is "hard coded" and derives from 'src/remote/remote_driver.h' even if you define other PATH's in libvirtd.conf for libvirtd. Example: (changed paths in libvirtd.conf) tyan:/etc/libvirt # grep _file libvirtd.conf #key_file = "/etc/pki/libvirt/private/serverkey.pem" key_file = "/etc/libvirt/ssl.key/chris.example.com.pem" #cert_file = "/etc/pki/libvirt/servercert.pem" cert_file = "/etc/libvirt/ssl.crt/chris.example.com.crt" #ca_file = "/etc/pki/CA/cacert.pem" ca_file = "/etc/libvirt/ssl.cacert/Bundle.crt" #crl_file = "/etc/pki/CA/crl.pem" but 'virsh' is still looking here: tyan:/etc/libvirt # virsh -c xen+tls://tyan/system Fehler: Cannot access CA certificate '/etc/pki/CA/cacert.pem': Datei oder Verzeichnis nicht gefunden Fehler: Verbindung zum Hypervisor scheiterte All this "certificate" stuff should be "configurable". Perhaps as "configure" options before compile. --with-cacert=/etc/libvirt/ssl.cacert/cacert.pem --with-clientkey=/etc/libvirt/ssl.key/clientkey.pem --with-clientcert=/etc/libvirt/ssl.crt/clientcert.pem --with-serverkey=/etc/libvirt/ssl.key/server.pem --with-servercert=/etc/libvirt/ssl.crt/servercert.pem
Chris, libvirtd.conf is a configuration file for the deamon and no client (incl. virsh) is supposed to read it. It would make even less sense for remote connections where libvirtd.conf may not even be present on localhost. Clients may specify certificate locations as part of the connection URI, e.g., xen+tls://tyan/system?pkipath=/etc/libvirt/pki/client However, client key and certificate must be stored in pkipath as clientkey.pem and clientcert.pem, respectively. For more details about remote access, see http://www.libvirt.org/remote.html To avoid typing such long URIs, one can setup aliases in /etc/libvirt/libvirt.conf: uri_aliases = [ "tyan=xen+tls://tyan/system?pkipath=/etc/libvirt/pki/client" ] and then just use virsh -c tyan If this solution does not satisfy your needs, feel free to file a new bug requesting better options to configure paths to various PKI files. But, please, don't use this bug for that as this bug covers different issue (although also related to PKI).
The RHEL bug is lax on details, but there seems to be a lot of info here: https://fedoraproject.org/wiki/Features/SharedSystemCertificates Not positive it's relevant to us though
Allowing use of central certificate database is ok *provided* it is an explicit choice - ie if the user has setup dedicated libvirt certs we must *never* load the central CA database.
Thank you for reporting this issue to the libvirt project. Unfortunately we have been unable to resolve this issue due to insufficient maintainer capacity and it will now be closed. This is not a reflection on the possible validity of the issue, merely the lack of resources to investigate and address it, for which we apologise. If you none the less feel the issue is still important, you may choose to report it again at the new project issue tracker https://gitlab.com/libvirt/libvirt/-/issues The project also welcomes contribution from anyone who believes they can provide a solution.