3:05 a.m.
Two minor improvements for the TLS setup documentation.
Sebastian Mitterle (2):
docs/tlscerts: document need for socket activation
docs/tlscerts: mention dropped 'encryption_key'
docs/kbase/tlscerts.rst | 42 +++++++++++++++++++++++++++++++++++++----
1 file changed, 38 insertions(+), 4 deletions(-)
--
2.50.1
3:05 a.m.
New subject: [PATCH v1 2/2] docs/tlscerts: mention dropped 'encryption_key'
Older libvirt versions still only work if 'encryption_key' is enabled
in the server and client certificates. Add a note.
Suggested-by: Daniel P. Berrangé <berrange(a)redhat.com>
Signed-off-by: Sebastian Mitterle <smitterl(a)redhat.com>
---
docs/kbase/tlscerts.rst | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/docs/kbase/tlscerts.rst b/docs/kbase/tlscerts.rst
index 5a1cb4be0d..2104e7a88b 100644
--- a/docs/kbase/tlscerts.rst
+++ b/docs/kbase/tlscerts.rst
@@ -104,6 +104,18 @@ connect provided they have a valid certificate issued by the CA for
their own IP
address. You may want to change this to make it less (or more) permissive,
depending on your needs.
+The following sections will describe how to created the data needed for the TLS
+setup. They use templates to create Certificate Authority, server and client
+certificates.
+
+Important: versions of libvirt before 11.6.0 also required the ``encryption_key``
+flag in the server and client template. This is no longer mandated since it is
+not applicable for use with many modern cryptographic algorithms, but it is
+harmless if present as it will be ignored. If compatibility with both old and
+new libvirt versions is required, then this extra flag must be added when
+creating the certificate.
+
+
Setting up a Certificate Authority (CA)
---------------------------------------
--
2.50.1
3:10 a.m.
New subject: [PATCH v1 1/2] docs/tlscerts: document need for socket activation
Mention that the tls socket needs to be started and the libvirtd
or virtproxyd service might have to be started.
If this is not done the user might run into connection issues and
it seems this is not mentioned elsewhere in the docs.
Suggested-by: Daniel P. Berrangé <berrange(a)redhat.com>
Signed-off-by: Sebastian Mitterle <smitterl(a)redhat.com>
---
docs/kbase/tlscerts.rst | 30 ++++++++++++++++++++++++++----
1 file changed, 26 insertions(+), 4 deletions(-)
diff --git a/docs/kbase/tlscerts.rst b/docs/kbase/tlscerts.rst
index 215d454998..5a1cb4be0d 100644
--- a/docs/kbase/tlscerts.rst
+++ b/docs/kbase/tlscerts.rst
@@ -317,10 +317,32 @@ briefly cover the steps.
Troubleshooting TLS certificate problems
----------------------------------------
-failed to verify client's certificate
- On the server side, run the libvirtd server with the '--listen' and
- '--verbose' options while the client is connecting. The verbose log messages
- should tell you enough to diagnose the problem.
+* TLS socket
+
+ After setting up your sever certificates you'll have to start libvirt's
+ tls socket and restart the corresponding daemon if it was already running,
+ i.e.
+
+ * for modular daemon setup run
+
+ ::
+
+ systemctl start virtproxyd-tls.socket
+ systemctl try-start virtproxyd.service
+
+ * for monolithic daemon setup run
+
+ ::
+
+ systemctl start libvirtd-tls.socket
+ systemctl try-start libvirtd.service
+
+
+* failed to verify client's certificate
+
+ On the server side, run the libvirtd server with the '--listen' and
+ '--verbose' options while the client is connecting. The verbose log messages
+ should tell you enough to diagnose the problem.
You can use the virt-pki-validate shell script to analyze the setup on the
client or server machines, preferably as root. It will try to point out the
--
2.50.1
7
days inactive
7
days old
2 comments
1 participants
participants (1)
-
Sebastian Mitterle