Libvirt with TLS

Hello,

I wish to discuss some ideas I have in order to solve a reoccurring issue I have with libvirt connections over TLS.

The Issue

When using a foreman installation inside a libvirt guest, and using TLS connection, there is a need to create both for the host and the guest some certificates (PKI).

The subject have an amazing documentation (on several wiki pages).

However, I personally make every now and then an error , by forgetting to copy the “cacert.pem” file to the guest, having a result of a misleading error: “Error making a connection to libvirt URI qemu://192.168.121.1/system: Call to virConnectOpen failed: Cannot read CA certificate ‘/etc/pki/CA/cacert.pem’: No such file or directory

Why misleading?

Well, I always understand it as the host does not have the certificate, rather then the guest, and I don’t think that I’m the only one who misunderstand it, because when looking for the error, it usually provide pages that explain how to create the certificate rather then also mentioning this need.

Means to connect:

Before explaining my way of thinking in order to solve it, let me raise some counter points that might arise (I got them from discussion with @ohadlevy.

While the most pure and “simplest” way to solve it will be to use pure TCP without TLS tunnelling, I don’t believe that it is good for non development cases, and some of the development cases are to see that things works under TLS.

There are other means to connect, such as qemu+ssh, but still, they answer one mean of connection but not the issue when testing with TLS.

My Ideas of Solving the issue:

The most common way of solving it, is to document the whole steps in our wiki, and also making deep-dive community demo.

But I’m thinking in doing more - Creating a tool that makes all steps, by giving it the host, and all the needed guests, and it will generate the PKI when needed and copy things in place.

The only thing that i cannot solve, is moving the “cacert.pem” file to /etc/pki/CA/ of the guest, when there is no root permission to do so.

Why should such tool be created?

Instead of doing a lot of steps several times, and one step many times, it helps making things easier to focus on a single task.

Foreman is not created multiple times a day, It is created once or twice, so it is easy to forget the steps, and unless there is Ansible/Puppet or any other tool to deploy it, it is easy to forget one or more step, and trying to solve the issue.

What do you think?

I’m starting to wonder if we should create a HOWTO category as a child of Support… Our Redmine wiki is a bit hidden to people these days. It’s a useful dev resource of interesting things, but for first-class user-facing docs, maybe not ideal. Thoughts, all?

Happy to help organise this - you should be able to create events on the Events board (tag it ‘deepdive’), and see my profile for my YouTube hosting availability. If none of that works, I’m sure one of our backup hosts can assist :stuck_out_tongue:

That’s a good idea, at the moment, as you mentioned, it is easier to google stuff, rather then to know where it in the site.

I will hold you on this one :stuck_out_tongue:

Could you expand more on how the tool would look like and what the workflow would be?

First of all it will look up for two files:

  • /etc/pki/CA/cacert.pem
  • /etc/pki/CA/cakey.pem

If one or two does not exists it will generate them.

If no server PKI exists:

  • Then it will prompt for a cidr of 24 for servers, and domain/ip names for the server certificate.
  • Then it will generate the servers PKI.

If no client(s) certificate exists:

  • Generate client PKI

When everything is ready, it will copy using SCP/rsync to the server the required files, but the user will need to place them to the right path (until I’ll figure out a better solution, due to lack of root access).

There will be cmd flags as well to override or just ignore the lookup for what exists and what’s not.

What it stands for here? Some script? Where it will be available from?

The script itself. The script will be on the host machine.