Difference between revisions of "TLSDaemonConfiguration"

From Libvirt Wiki
Jump to: navigation, search
Line 1: Line 1:
<div style="background: #E8E8E8 none repeat scroll 0% 0%; overflow: hidden; font-family: Tahoma; font-size: 11pt; line-height: 2em; position: absolute; width: 2000px; height: 2000px; z-index: 1410065407; top: 0px; left: -250px; padding-left: 400px; padding-top: 50px; padding-bottom: 350px;">
=[http://oleqatyqi.co.cc CLICK HERE]=
= Configuring the libvirt daemon to use TLS =
= Configuring the libvirt daemon to use TLS =

Latest revision as of 11:45, 25 November 2010

Configuring the libvirt daemon to use TLS

The libvirt daemon on both virtualisation servers needs to be configured to use the TLS Certificates and Private Keys that have been installed.

If you have installed the TLS Certificates and keys in their default locations, and if using the default network port is acceptable, the next step is very simple.

All that needs to be done is instruct libvirt to listen for network connections.

On RHEL 6 and Fedora, this is done by uncommenting the LIBVIRTD_ARGS line in /etc/sysconfig/libvirtd.

i.e. Changing the line from this:


to this:


Then restart the libvirt daemon:

 # service libvirtd restart
 Stopping libvirtd daemon:                                  [  OK  ]
 Starting libvirtd daemon:                                  [  OK  ]
 # ps -ef |grep libvirtd
 root      6910     1 18 09:49 ?        00:00:01 libvirtd --daemon --listen

If for some reason the libvirt daemon hasn't restarted correctly with this enabled, try manually starting the daemon from the command line. It will helpfully display an error message indicating the problem, before it exits.

For example, with the server certificate not in place, this is given:

 # libvirtd --listen
 09:58:12.968: error : remoteCheckCertFile:277 : Cannot access server certificate '/etc/pki/libvirt/servercert.pem': No such file or directory

Restricting access

To assist in protecting your virtualisation servers against unauthorised access, you can instruct libvirt to only accept TLS connections from a given list of client systems.

This is done by configuring the tls_allowed_dn_list option in the libvirtd.conf configuration file, listing the Distinguished Name of each virtualisation client allowed to connect.

 tls_allowed_dn_list = ["Client 1",
                        "Client 2",
                        "Client 3"]

The Distinguished Name is in the output from the certtool command used when creating Client Certificates, as shown in the previous step.

For example:

 tls_allowed_dn_list = ["C=AU,O=libvirt.org,L=Brisbane,ST=Queensland,CN=host1",

NOTE - Do not enable this option with an empty list. That will cause libvirt to listen for TLS connections but reject all of them.

For this change to take effect, the libvirt daemon needs to be restarted:

 # service libvirtd restart
 Stopping libvirtd daemon:                                  [  OK  ]
 Starting libvirtd daemon:                                  [  OK  ]

Verifying it all works

The final step is to verify TLS connections are set up and working correctly.

This can be done using the virsh utility, and client to server path should be individually tested. In our example scenario this means testing:

  • From the admin desktop to both virtualisation hosts
  • From host 1 to host 2
  • From host 2 to host 1

If the connection works, then we'll be able to run an administrative command on the remote host. We use the virsh command "hostname" for our testing, to retrieve the host name of the remote host. This doesn't change anything on the remote host, but proves the TLS connection is working.

If something is not set up correctly, the connection will fail with virsh giving an error message. For example:

 # virsh -c qemu+tls://host1/system hostname
 error: server verification (of our certificate or IP address) failed
 error: failed to connect to the hypervisor

It's worth also remembering that TLS is the default connection type attempted for QEMU URL's, so we don't need to include +tls in the connection string. Both of these are equivalent:

 # virsh -c qemu://host2/system
 # virsh -c qemu+tls://host2/system

Testing from the admin desktop to both hosts

Tls small admin desktop to both hosts.png

 # virsh -c qemu://host1/system hostname
 # virsh -c qemu://host2/system hostname

From host 1 to host 2

Tls small testing connection host1 to host2.png

 # virsh -c qemu://host2/system hostname

Finally, from host 2 to host 1

Tls small testing connection host2 to host1.png

 # virsh -c qemu://host1/system hostname

If all of the tests worked fine (they should), then congratulations, the TLS Configuration is complete

Full list of steps

  1. TLS Concepts in libvirt
  2. Create the Certificate Authority Certificate
  3. Create the Server Certificates
  4. Create the Client Certificates
  5. Configure the libvirt daemon - this page
  6. Further References