Red Hat Bugzilla – Bug 810491
RFE: Look for CA certs in system-wide CA certificate database
Last modified: 2016-04-18 21:22:55 EDT
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):
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
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
virsh finds CA cert in nss as trusted and uses it
* 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.
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.,
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
uri_aliases = [
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:
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.