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/bf79a021a6437b4f85469a53f650bff62db5f674/src/rpc/virnettlscert.c#L165 > > 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 :|
