From f7f0a31a82a10f5b7954ff74bb3a6847e8a78e54 Mon Sep 17 00:00:00 2001 From: "Richard W.M. Jones" Date: Mon, 11 Jun 2007 12:23:36 +0000 Subject: [PATCH] Mon Jun 11 13:22:00 BST 2007 Richard W.M. Jones * docs/libvir.html, docs/remote.html: Updated docs to reflect access control lists now based on Distinguished Names. --- ChangeLog | 5 ++++ docs/libvir.html | 65 +++++++++++++++++++++++++++++------------------- docs/remote.html | 62 ++++++++++++++++++++++++++------------------- 3 files changed, 82 insertions(+), 50 deletions(-) diff --git a/ChangeLog b/ChangeLog index ff115a1a13..7aea94704b 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +Mon Jun 11 13:22:00 BST 2007 Richard W.M. Jones + + * docs/libvir.html, docs/remote.html: Updated docs to reflect + access control lists now based on Distinguished Names. + Mon Jun 11 13:18:00 BST 2007 Richard W.M. Jones * configure.in: Add '--with-remote' flag. Add compatibility diff --git a/docs/libvir.html b/docs/libvir.html index ebda1426de..0d88211848 100644 --- a/docs/libvir.html +++ b/docs/libvir.html @@ -1683,10 +1683,8 @@ next section. Installed on the client Client's certificate signed by the CA (more info) - CommonName (CN) must be the client IP address as seen - by the server. Take particular care with IPv4 and IPv6 - addresses, and note that on some operating systems IPv4 addresses - may need to be encapsulated as ::ffff:a.b.c.d + Distinguished Name (DN) can be checked against an access + control list (tls_allowed_dn_list). @@ -2011,17 +2009,14 @@ which can be installed on the server as

For each client (ie. any program linked with libvirt, such as virt-manager) -you need to issue a certificate with the X.509 CommonName (CN) -field set to the IP address of the client as seen from the -server. +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:

-

-Normally then the CN will just be a string such as -"192.168.2.5". On machines with IPv6 enabled, -IPv4 addresses may appear embedded, for example: -"::ffff:a.b.c.d". -

+
+C=GB,ST=London,L=London,O=Red Hat,CN=name_of_client
+

The process is the same as for @@ -2036,8 +2031,7 @@ Make a private key and a request for a new certificate: 

 ./CA.pl -newreq
-You must set the CommonName (CN) field to be the -client's IP address as seen by the server. See notes above. +Set the DN fields as required.
  • @@ -2074,10 +2068,8 @@ cp clientcert.pem /etc/pki/libvirt/clientcert.pem

    On the server side, run the libvirtd server with the '--remote' and '--verbose' options while the -client is connecting. The verbose messages will tell -you the client's actual IP address versus what is -in the client's certificate. Also you will find out -common problems such as expired certificates. +client is connecting. The verbose log messages should +tell you enough to diagnose the problem.

    @@ -2189,18 +2181,41 @@ Blank lines and comments beginning with # are ignored. - tls_allowed_clients ["ip1", "ip2", "ip3"] - (none - any client can connect) + tls_allowed_dn_list ["DN1", "DN2"] + (none - DNs are not checked) + +

    + Enable an access control list of client certificate Distinguished + Names (DNs) which can connect to the TLS port on this server. +

    +

    + The default is that DNs are not checked. +

    +

    + This list may contain wildcards such as "C=GB,ST=London,L=London,O=Red Hat,CN=*" + See the POSIX fnmatch function for the format + of the wildcards. +

    +

    + Note that if this is an empty list, no client can connect. +

    +

    + Note also that GnuTLS returns DNs without spaces + after commas between the fields (and this is what we check against), + but the openssl x509 tool shows spaces. + + + + + tls_allowed_ip_list ["ip1", "ip2", "ip3"] + (none - clients can connect from anywhere)

    Enable an access control list of the IP addresses of clients who can connect to the TLS or TCP ports on this server.

    - The default is that any client can connect, but their - certificate must match their IP address and must be - issued by the trusted CA. If you use this option, then - in addition only the IP addresses listed may connect. + The default is that clients can connect from any IP address.

    This list may contain wildcards such as 192.168.* diff --git a/docs/remote.html b/docs/remote.html index 9da96dd1f8..750e631827 100644 --- a/docs/remote.html +++ b/docs/remote.html @@ -210,10 +210,8 @@ next section. Installed on the client Client's certificate signed by the CA (more info) - CommonName (CN) must be the client IP address as seen - by the server. Take particular care with IPv4 and IPv6 - addresses, and note that on some operating systems IPv4 addresses - may need to be encapsulated as ::ffff:a.b.c.d + Distinguished Name (DN) can be checked against an access + control list (tls_allowed_dn_list).

    Background to TLS certificates

    Libvirt supports TLS certificates for verifying the identity @@ -449,15 +447,12 @@ which can be installed on the server as

    Issuing client certificates

    For each client (ie. any program linked with libvirt, such as virt-manager) -you need to issue a certificate with the X.509 CommonName (CN) -field set to the IP address of the client as seen from the -server. -

    -Normally then the CN will just be a string such as -"192.168.2.5". On machines with IPv6 enabled, -IPv4 addresses may appear embedded, for example: -"::ffff:a.b.c.d". -

    +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=GB,ST=London,L=London,O=Red Hat,CN=name_of_client
+

    The process is the same as for setting up the server certificate so here we just briefly cover the @@ -467,8 +462,7 @@ Make a private key and a request for a new certificate: 

     ./CA.pl -newreq
    -You must set the CommonName (CN) field to be the -client's IP address as seen by the server. See notes above. +Set the DN fields as required.
  • @@ -499,10 +493,8 @@ cp clientcert.pem /etc/pki/libvirt/clientcert.pem

    On the server side, run the libvirtd server with the '--remote' and '--verbose' options while the -client is connecting. The verbose messages will tell -you the client's actual IP address versus what is -in the client's certificate. Also you will find out -common problems such as expired certificates. +client is connecting. The verbose log messages should +tell you enough to diagnose the problem.

    libvirtd configuration

    @@ -570,18 +562,38 @@ Blank lines and comments beginning with # are ignored. Change the path used to find the CA certificate revocation list (CRL) file. If you set this to an empty string, then no CRL is loaded. - tls_allowed_clients ["ip1", "ip2", "ip3"] - (none - any client can connect) + tls_allowed_dn_list ["DN1", "DN2"] + (none - DNs are not checked) + +

    + Enable an access control list of client certificate Distinguished + Names (DNs) which can connect to the TLS port on this server. +

    +

    + The default is that DNs are not checked. +

    +

    + This list may contain wildcards such as "C=GB,ST=London,L=London,O=Red Hat,CN=*" + See the POSIX fnmatch function for the format + of the wildcards. +

    +

    + Note that if this is an empty list, no client can connect. +

    +

    + Note also that GnuTLS returns DNs without spaces + after commas between the fields (and this is what we check against), + but the openssl x509 tool shows spaces. +

    + tls_allowed_ip_list ["ip1", "ip2", "ip3"] + (none - clients can connect from anywhere)

    Enable an access control list of the IP addresses of clients who can connect to the TLS or TCP ports on this server.

    - The default is that any client can connect, but their - certificate must match their IP address and must be - issued by the trusted CA. If you use this option, then - in addition only the IP addresses listed may connect. + The default is that clients can connect from any IP address.

    This list may contain wildcards such as 192.168.*