Re: libvirt TLS certificates letsencrypt
On Tue, May 20, 2025 at 08:00:42AM +0200, Jani Heikkinen wrote:
Hello! I am part of infrastructure team at BFH and we are building
an
openstack installation.
A couple of months ago I was experimenting with setting up noVNC consoles
with encryption.
Connecting until the novncproxy service with TLS can be done with no issues,
but the connection between libvirt and the proxy turned out to be
problematic.
We would really love to use letsencrypt certificates which are generated for
each server/container, instead of relying on creating own CA and generate
certificates.
With libvirt, using letsencrypt is impossible, since the code does bunch of
checks for properties of the TLS certificates, see:
https://github.com/libvirt/libvirt/blob/bf79a021a6437b4f85469a53f650bff62...
Does anybody know, why these checks exist? They de facto prevent using
anything else than self-generated certificates for securing vnc console
traffic.
Well this is our documented TLS setup:
https://libvirt.org/kbase/tlscerts.html
and we've had sooooo many problems with people messing up their TLS setup
over the years, that we added validation that the certs are configured in
line with our documentation.
I wasn't aware that this would problems with LetsEncrypt, as it is not
common to use public CAs with private facing infrastructure.
Is using my own self-created CA somehow more trustworthy than
LetsEncrypt
root CA?
IIUC, you're talking about certs for *internal* (non-public facing)
machines.
LetsEncrypt originated as a means for providing certs for public facing
machines, that would be trusted by the browser vendor's default CA
bundles.
The public CA bundle has the significant security limitation that any
CA can issue a cert for any site. There's limited mechanisms to dicate
that site XX only expects to have certs issued by CA YY. There have
been high profile examples of rogue CAs issue certs for sites that
they are not associated with, and almost certainly many more such
attacks that have flown under the radar.
For internal infrastructure, which is non-browser based, it is highly
likely you'll already have deployment time configuration tasks, and
as such installing a private root CA cert for libvirt is not a major
additional burden. Using the private CA instead of relying on the
public CA bundle, eliminates the risk that any (compromised) public
CA can issues rogue certs as part of an attack on your internal infra.
So personally, yes, I would suggest that an internal CA has the
potential to be more secure than relying on the the public CA
cert bundle. Even if you deployed your systems such that it only
is given the LetsEncrypt CA cert, not the whole public CA cert
bundle, you've still extended your zone of trust to the entire
LetsEncrypt organization and their intrastucture.
The right answer here depends on your risk appetetite, balanced
against the burden of maintaining a CA in-house to your organization.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|