Bug 810491 - RFE: Look for CA certs in system-wide CA certificate database
RFE: Look for CA certs in system-wide CA certificate database
Status: NEW
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
unspecified
Unspecified Unspecified
medium Severity medium
: ---
: ---
Assigned To: Libvirt Maintainers
Virtualization Bugs
:
Depends On: 544376 846146
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-06 08:23 EDT by David Jaša
Modified: 2016-04-18 21:22 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Jaša 2012-04-06 08:23:02 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):
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
Comment 2 Daniel Berrange 2012-04-10 04:26:30 EDT
libvirt does *not* use NSS for its PKI support, so IMHO it is not appropriate to look in NSS directories for configuration.
Comment 3 David Jaša 2012-04-10 10:48:27 EDT
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.
Comment 6 chris 2012-08-13 13:57:18 EDT
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
Comment 7 Jiri Denemark 2012-08-14 11:18:25 EDT
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).
Comment 11 Cole Robinson 2016-03-23 16:39:40 EDT
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
Comment 12 Daniel Berrange 2016-03-29 05:01:20 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.