From nobody Sat May 4 10:40:17 2024
Delivered-To: importer@patchew.org
Received-SPF: pass (zoho.com: domain of redhat.com designates 209.132.183.28
as permitted sender) client-ip=209.132.183.28;
envelope-from=libvir-list-bounces@redhat.com; helo=mx1.redhat.com;
Authentication-Results: mx.zohomail.com;
spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as
permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com
Return-Path: virConnectOpen
(or virsh -c ...).
For example, if you normally use
qemu:///system
to access the system-wide QEMU daemon, then to access
the system-wide QEMU daemon on a remote machine called
-oirase
you would use qemu://oirase/system
.
+compute1.libvirt.org
you would use qemu://compute1.libv=
irt.org/system
.
The section on remote URIs @@ -412,7 +412,9 @@ next section.
For each server (libvirtd) you need to issue a certificate -with the X.509 CommonName (CN) field set to the hostname -of the server. The CN must match the hostname which -clients will be using to connect to the server. +containing one or more hostnames and/or IP addresses. +Historically the CommonName (CN) field would contain the +hostname of the server, and would match the hostname used +in the URI that clients pass to libvirt. In most TLS impls +the CN field is considered legacy data, the Subject Alt Name +(SAN) extension fields we be preferentially validated against. +In the future use of the CN field for validation may be +discontinuned entirely, so it is strongly recommended to +include the SAN fields.
In the example below, clients will be connecting to the
server using a URI of
-xen://oirase/
, so the CN must be "oirase
".
+xen://virt.example/
, so the CN must be "oirase
".
Make a private key for the server: @@ -599,13 +607,25 @@ certtool --generate-privkey > serverkey.pem
and sign that key with the CA's private key by first
-creating a template file called server.info
-(only the CN field matters, which as explained above must
-be the server's hostname):
+creating a template file called server.info
.
+The 'cn' field should refer to the fully qualified public
+hostname of the server. For the SAN extension data, there
+must also be one or more 'dns_name' fields that contain all
+possible hostnames that can be reasonably used by clients
+to reach the server, both with and without domain name
+qualifiers. If clients are likely to connect to the server
+by IP address, then one or 'ip_address' fields should also
+be added.
organization =3D Name of your organization -cn =3D oirase +cn =3D compute1.libvirt.org +dns_name =3D compute1 +dns_name =3D compute1.libvirt.org +ip_address =3D 10.0.0.74 +ip_address =3D 192.168.1.24 +ip_address =3D 2001:cafe::74 +ip_address =3D fe20::24 tls_www_server encryption_key signing_key @@ -635,16 +655,28 @@ X.509 certificate info: =20 Version: 3 Serial Number (hex): 00 -Subject: O=3DRed Hat Emerging Technologies,CN=3Doirase -Issuer: CN=3DRed Hat Emerging Technologies +Subject: O=3DLibvirt Project,CN=3Dcompute1.libvirt.org +Issuer: CN=3DLibvirt Project Signature Algorithm: RSA-SHA Validity: Not Before: Mon Jun 18 16:34:49 2007 Not After: Tue Jun 17 16:34:49 2008 +Extensions: + Basic Constraints (critical): + Certificate Authority (CA): FALSE + Subject Alternative Name (not critical): + DNSname: compute1 + DNSname: compute1.libvirt.org + IPAddress: 10.0.0.74 + IPAddress: 192.168.1.24 + IPAddress: 2001:cafe::74 + IPAddress: fe20::24
-Note the "Issuer" CN is "Red Hat Emerging Technologies" (the CA) and -the "Subject" CN is "oirase" (the server). +Note the "Issuer" CN is "Libvirt Project" (the CA) and +the "Subject" CN is "compute1.libvirt.org" (the server). +Notice that the hostname listed in the CN must also +be duplicated as a DNSname entry
Finally we have two files to install: @@ -665,13 +697,13 @@ which can be installed on the server as
For each client (ie. any program linked with libvirt, such as -virt-manager) +virt-manager) you need to issue a certificate with the X.509 Distinguished Name (DN) set to a suitable name. You can decide this on a company / organisation policy. For example, I use:
-C=3DGB,ST=3DLondon,L=3DLondon,O=3DRed Hat,CN=3Dname_of_client +C=3DGB,ST=3DLondon,L=3DLondon,O=3DLibvirt Project,CN=3Dname_of_client= i>
The process is the same as for
@@ -692,7 +724,7 @@ Act as CA and sign the certificate. Create client.info=
containing:
country =3D GB
state =3D London
locality =3D London
-organization =3D Red Hat
+organization =3D Libvirt Project
cn =3D client1
tls_www_client
encryption_key
@@ -884,7 +916,7 @@ Blank lines and comments beginning with #
=
are ignored.
The default is that DNs are not checked.
- This list may contain wildcards such as "C=3DGB,ST=3DLondon,L=3DLo=
ndon,O=3DRed Hat,CN=3D*"
+ This list may contain wildcards such as "C=3DGB,ST=3DLondon,L=3DLo=
ndon,O=3DLibvirt Project,CN=3D*"
See the POSIX fnmatch
function for the format
of the wildcards.