[PATCH 63/67] docs: kbase/tlscerts: Fix links

Peter Krempa pkrempa at redhat.com
Tue May 31 15:06:38 UTC 2022


Most of the links were broken by moving the article into kbase, but in
this case we need to also fix the anchor names.

Signed-off-by: Peter Krempa <pkrempa at redhat.com>
---
 docs/kbase/tlscerts.rst | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/docs/kbase/tlscerts.rst b/docs/kbase/tlscerts.rst
index 962253e853..e4aa5bb3c9 100644
--- a/docs/kbase/tlscerts.rst
+++ b/docs/kbase/tlscerts.rst
@@ -84,12 +84,12 @@ clients. There are two distinct checks involved:
 -  The client should know that it is connecting to the right server. Checking
    done by client by matching the certificate that the server sends to the
    server's hostname. May be disabled by adding ``?no_verify=1`` to the `remote
-   URI <uri.html#Remote_URI_parameters>`__.
+   URI <../uri.html#tls-transport>`__.

 -  The server should know that only permitted clients are connecting. This can
    be done based on client's IP address, or on client's IP address and client's
    certificate. Checking done by the server. May be enabled and disabled in the
-   `libvirtd.conf file <remote.html#libvirtd-configuration-file>`__.
+   `libvirtd.conf file <../remote.html#libvirtd-configuration-file>`__.

 For full certificate checking you will need to have certificates issued by a
 recognised `Certificate Authority
@@ -99,7 +99,7 @@ CA, you can set up your own CA and tell your server(s) and clients to trust
 certificates issues by your own CA. Follow the instructions in the next section.

 Be aware that the `default configuration for
-libvirtd <remote.html#libvirtd-configuration-file>`__ allows any client to
+libvirtd <../remote.html#libvirtd-configuration-file>`__ allows any client to
 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.
@@ -180,7 +180,7 @@ for validation may be discontinued 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 <uri.html#URI_remote>`__ of ``qemu://compute1.libvirt.org/system``, so the
+`URI <../uri.html#remote-uris>`__ of ``qemu://compute1.libvirt.org/system``, so the
 CN must be "``compute1.libvirt.org``".

 Make a private key for the server:
-- 
2.35.3



More information about the libvir-list mailing list