mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2025-01-03 11:35:19 +00:00
Mon Jun 18 16:59:00 BST 2007 Richard W.M. Jones <rjones@redhat.com>
* docs/libvir.html (Remote): Updated certificate documentation to use GnuTLS certtool instead of CA.pl / openssl.
This commit is contained in:
parent
af933f6ff0
commit
81bb16b302
@ -1,3 +1,8 @@
|
|||||||
|
Mon Jun 18 16:59:00 BST 2007 Richard W.M. Jones <rjones@redhat.com>
|
||||||
|
|
||||||
|
* docs/libvir.html (Remote): Updated certificate documentation
|
||||||
|
to use GnuTLS certtool instead of CA.pl / openssl.
|
||||||
|
|
||||||
Mon Jun 18 10:32:14 CEST 2007 Daniel Veillard <veillard@redhat.com>
|
Mon Jun 18 10:32:14 CEST 2007 Daniel Veillard <veillard@redhat.com>
|
||||||
|
|
||||||
* src/virsh.c: applied SetMem cleanup patch from Mark Johnson
|
* src/virsh.c: applied SetMem cleanup patch from Mark Johnson
|
||||||
|
311
docs/libvir.html
311
docs/libvir.html
@ -1376,15 +1376,6 @@ too if the issue looks serious, thanks !</p>
|
|||||||
|
|
||||||
<h2><a name="Remote">Remote support</a></h2>
|
<h2><a name="Remote">Remote support</a></h2>
|
||||||
|
|
||||||
<p>
|
|
||||||
<b>NB. Remote support is available only as a <a
|
|
||||||
href="https://www.redhat.com/archives/libvir-list/">series of
|
|
||||||
patches posted on libvir-list</a> against <a
|
|
||||||
href="http://libvirt.org/downloads.html">libvirt CVS</a>. It is only
|
|
||||||
for experimental use at the moment.</b>
|
|
||||||
— Richard Jones, 2007-04-18.
|
|
||||||
</p>
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
Libvirt allows you to access hypervisors running on remote
|
Libvirt allows you to access hypervisors running on remote
|
||||||
machines through authenticated and encrypted connections.
|
machines through authenticated and encrypted connections.
|
||||||
@ -1735,89 +1726,58 @@ permissive, depending on your needs.
|
|||||||
|
|
||||||
<p>
|
<p>
|
||||||
You will need the <a
|
You will need the <a
|
||||||
href="http://www.openssl.org/docs/apps/CA.pl.html">OpenSSL CA.pl Perl
|
href="http://www.gnu.org/software/gnutls/manual/html_node/Invoking-certtool.html">GnuTLS
|
||||||
script documented here</a>. In Fedora, it is in the
|
certtool program documented here</a>. In Fedora, it is in the
|
||||||
<code>openssl-perl</code> package. In Debian and derivatives, it is
|
<code>gnutls-utils</code> package.
|
||||||
in the base <code>openssl</code> package.
|
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<p>Notes:</p>
|
<p>
|
||||||
|
Create a private key for your CA:
|
||||||
|
</p>
|
||||||
|
|
||||||
|
<pre>
|
||||||
|
certtool --generate-privkey > cakey.pem
|
||||||
|
</pre>
|
||||||
|
|
||||||
|
<p>
|
||||||
|
and self-sign it by creating a file with the
|
||||||
|
signature details called
|
||||||
|
<code>ca.info</code> containing:
|
||||||
|
</p>
|
||||||
|
|
||||||
|
<pre>
|
||||||
|
cn = <i>Name of your organization</i>
|
||||||
|
ca
|
||||||
|
cert_signing_key
|
||||||
|
</pre>
|
||||||
|
|
||||||
|
and sign:
|
||||||
|
|
||||||
|
<pre>
|
||||||
|
certtool --generate-self-signed --load-privkey cakey.pem \
|
||||||
|
--template ca.info --outfile cacert.pem
|
||||||
|
</pre>
|
||||||
|
|
||||||
|
<p>
|
||||||
|
(You can delete <code>ca.info</code> file now if you
|
||||||
|
want).
|
||||||
|
</p>
|
||||||
|
|
||||||
|
<p>
|
||||||
|
Now you have two files which matter:
|
||||||
|
</p>
|
||||||
|
|
||||||
<ul>
|
<ul>
|
||||||
<li>
|
<li>
|
||||||
You may find it
|
<code>cakey.pem</code> - Your CA's private key (keep this very secret!)
|
||||||
better to start with the basic <code>CA.pl</code> script from OpenSSL
|
|
||||||
itself, as Linux distributors seem to supply a hacked/broken one.
|
|
||||||
</li>
|
</li>
|
||||||
<li>
|
<li>
|
||||||
A second confounding factor may be the default
|
<code>cacert.pem</code> - Your CA's certificate (this is public).
|
||||||
<code>openssl.cnf</code> file supplied with your
|
|
||||||
Linux distribution. You can switch to a custom
|
|
||||||
file by doing:
|
|
||||||
<pre>
|
|
||||||
export SSLEAY_CONFIG="-config your_config_file"
|
|
||||||
</pre>
|
|
||||||
</li>
|
</li>
|
||||||
</ul>
|
</ul>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
These instructions assume that <code>CA.pl</code> is in an empty
|
<code>cacert.pem</code> has to be installed on clients and
|
||||||
directory (because you will probably need to edit this script).
|
|
||||||
Please read the <a
|
|
||||||
href="http://www.openssl.org/docs/apps/CA.pl.html">CA.pl manpage</a>
|
|
||||||
carefully before starting.
|
|
||||||
</p>
|
|
||||||
|
|
||||||
<p>
|
|
||||||
Copy CA.pl into an empty directory and edit it. Near the top you will
|
|
||||||
find various variables:
|
|
||||||
</p>
|
|
||||||
|
|
||||||
<p>
|
|
||||||
<code>$DAYS</code> defaults to <code>"-days 365"</code>. You may wish
|
|
||||||
to increase this, otherwise your CA and certificates will expire after
|
|
||||||
a year, suddenly leaving your systems unmanageable.
|
|
||||||
</p>
|
|
||||||
|
|
||||||
<p>
|
|
||||||
<code>$CATOP</code> may be set to <code>"./demoCA"</code> or some
|
|
||||||
other directory. If you want you can change the name to a suitable
|
|
||||||
directory name for your organisation.
|
|
||||||
</p>
|
|
||||||
|
|
||||||
<p>
|
|
||||||
Now run:
|
|
||||||
</p>
|
|
||||||
|
|
||||||
<pre>
|
|
||||||
<b>./CA.pl -newca</b>
|
|
||||||
CA certificate filename (or enter to create)
|
|
||||||
<b>[press enter key]</b>
|
|
||||||
Making CA certificate ...
|
|
||||||
Generating a 1024 bit RSA private key
|
|
||||||
...++++++
|
|
||||||
.......................++++++
|
|
||||||
writing new private key to './demoCA/private/cakey.pem'
|
|
||||||
Enter PEM pass phrase: <b>[type a passphrase]</b>
|
|
||||||
Verifying - Enter PEM pass phrase: <b>[type a passphrase]</b>
|
|
||||||
</pre>
|
|
||||||
|
|
||||||
<p>
|
|
||||||
It will ask some further questions about your organisation and then
|
|
||||||
create a CA directory structure (usually called <code>demoCA</code>
|
|
||||||
unless you changed it above). Some highlights of this directory:
|
|
||||||
</p>
|
|
||||||
|
|
||||||
<pre>
|
|
||||||
demoCA/newcerts Certificates issued by the CA
|
|
||||||
demoCA/crl Certificates revoked by the CA
|
|
||||||
demoCA/cacert.pem The CA's own certificate (this is public)
|
|
||||||
demoCA/private/cakey.pem The CA's private key (keep this secret)
|
|
||||||
</pre>
|
|
||||||
|
|
||||||
<p>
|
|
||||||
The important file is <code>cacert.pem</code> which is your new CA's
|
|
||||||
X.509 certificate. This file has to be installed on clients and
|
|
||||||
server(s) to let them know that they can trust certificates issued by
|
server(s) to let them know that they can trust certificates issued by
|
||||||
your CA.
|
your CA.
|
||||||
</p>
|
</p>
|
||||||
@ -1832,26 +1792,25 @@ To see the contents of this file, do:
|
|||||||
</p>
|
</p>
|
||||||
|
|
||||||
<pre>
|
<pre>
|
||||||
<b>openssl x509 -in demoCA/cacert.pem -text</b>
|
<b>certtool -i --infile cacert.pem</b>
|
||||||
Certificate:
|
|
||||||
Data:
|
|
||||||
Version: 3 (0x2)
|
|
||||||
Serial Number:
|
|
||||||
dd:b4:0f:d0:58:0e:08:fa
|
|
||||||
Signature Algorithm: sha1WithRSAEncryption
|
|
||||||
Issuer: C=GB, ST=London, L=London, O=Red Hat UK Ltd, OU=Emerging Technologies, CN=Red Hat/emailAddress=rjones@redhat.com
|
|
||||||
Validity
|
|
||||||
Not Before: May 10 10:26:47 2007 GMT
|
|
||||||
Not After : May 7 10:26:47 2017 GMT
|
|
||||||
Subject: C=GB, ST=London, L=London, O=Red Hat UK Ltd, OU=Emerging Technologies, CN=Red Hat/emailAddress=rjones@redhat.com
|
|
||||||
|
|
||||||
|
X.509 certificate info:
|
||||||
|
|
||||||
|
Version: 3
|
||||||
|
Serial Number (hex): 00
|
||||||
|
Subject: CN=Red Hat Emerging Technologies
|
||||||
|
Issuer: CN=Red Hat Emerging Technologies
|
||||||
|
Signature Algorithm: RSA-SHA
|
||||||
|
Validity:
|
||||||
|
Not Before: Mon Jun 18 16:22:18 2007
|
||||||
|
Not After: Tue Jun 17 16:22:18 2008
|
||||||
<i>[etc]</i>
|
<i>[etc]</i>
|
||||||
</pre>
|
</pre>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
This is all that is required to set up your CA. Keep this directory
|
This is all that is required to set up your CA. Keep the CA's private
|
||||||
structure and the passphrase safe as you will require them later when
|
key carefully as you will need it when you come to issue certificates
|
||||||
issuing certificates.
|
for your clients and servers.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<h4><a name="Remote_TLS_server_certificates">Issuing server certificates</a></h4>
|
<h4><a name="Remote_TLS_server_certificates">Issuing server certificates</a></h4>
|
||||||
@ -1870,121 +1829,74 @@ server using a <a href="#Remote_URI_reference">URI</a> of
|
|||||||
</p>
|
</p>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
First move to the directory above the CA directory (from the example
|
Make a private key for the server:
|
||||||
in the last section, <code>demoCA</code> would be a subdirectory).
|
|
||||||
</p>
|
|
||||||
|
|
||||||
<p>
|
|
||||||
Make a private key and a request for a new certificate:
|
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<pre>
|
<pre>
|
||||||
<b>./CA.pl -newreq</b>
|
certtool --generate-privkey > serverkey.pem
|
||||||
Generating a 1024 bit RSA private key
|
|
||||||
...++++++
|
|
||||||
....................++++++
|
|
||||||
writing new private key to 'newreq.pem'
|
|
||||||
Enter PEM pass phrase: <b>[enter a passphrase]</b>
|
|
||||||
Verifying - Enter PEM pass phrase: <b>[enter a passphrase]</b>
|
|
||||||
</pre>
|
</pre>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
You will be asked additional details about the certificate.
|
and sign that key with the CA's private key by first
|
||||||
The single important field is "Common Name" which as explained
|
creating a template file called <code>server.info</code>
|
||||||
above <b>must</b> contain the server's hostname as clients
|
(only the CN field matters, which as explained above must
|
||||||
see it.
|
be the server's hostname):
|
||||||
</p>
|
|
||||||
|
|
||||||
<p>
|
|
||||||
The operation creates a request file called <code>newreq.pem</code>
|
|
||||||
which has both the private key and the unsigned certificate.
|
|
||||||
In the situation of a "real" CA, you would send the certificate
|
|
||||||
part off to be signed (along with lots of $$$). Instead we are
|
|
||||||
going to act as CA and sign it ourselves:
|
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<pre>
|
<pre>
|
||||||
<b>./CA.pl -signreq</b>
|
organization = <i>Name of your organization</i>
|
||||||
Enter pass phrase for demoCA/private/cakey.pem: <b>[enter CA passphrase]</b>
|
cn = oirase
|
||||||
Check that the request matches the signature
|
tls_www_server
|
||||||
Signature ok
|
encryption_key
|
||||||
Certificate Details:
|
signing_key
|
||||||
Serial Number:
|
|
||||||
dd:b4:0f:d0:58:0e:08:fb
|
|
||||||
Validity
|
|
||||||
Not Before: May 10 11:10:40 2007 GMT
|
|
||||||
Not After : May 9 11:10:40 2008 GMT
|
|
||||||
Subject:
|
|
||||||
countryName = GB
|
|
||||||
stateOrProvinceName = London
|
|
||||||
localityName = London
|
|
||||||
organizationName = Red Hat UK Ltd
|
|
||||||
organizationalUnitName = Emerging Technologies
|
|
||||||
commonName = oirase
|
|
||||||
emailAddress = rjones@redhat.com
|
|
||||||
X509v3 extensions:
|
|
||||||
X509v3 Basic Constraints:
|
|
||||||
CA:FALSE
|
|
||||||
Netscape Comment:
|
|
||||||
OpenSSL Generated Certificate
|
|
||||||
X509v3 Subject Key Identifier:
|
|
||||||
DE:08:0D:12:73:76:06:97:EC:57:EF:8D:1B:48:ED:53:9A:1A:FE:7F
|
|
||||||
X509v3 Authority Key Identifier:
|
|
||||||
keyid:F6:84:4C:1B:2B:59:10:89:3F:0B:AB:05:7F:57:85:A6:33:C7:7A:60
|
|
||||||
|
|
||||||
Certificate is to be certified until May 9 11:10:40 2008 GMT (365 days)
|
|
||||||
Sign the certificate? [y/n]:<b>y</b>
|
|
||||||
|
|
||||||
|
|
||||||
1 out of 1 certificate requests certified, commit? [y/n]<b>y</b>
|
|
||||||
Write out database with 1 new entries
|
|
||||||
Data Base Updated
|
|
||||||
Signed certificate is in newcert.pem
|
|
||||||
</pre>
|
</pre>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
This step generates a server certificate signed by the CA
|
and sign:
|
||||||
for the server <code>oirase</code> (NB. the commonName field
|
|
||||||
above). We can examine this certificate and its signature:
|
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<pre>
|
<pre>
|
||||||
<b>openssl x509 -in newcert.pem -text</b>
|
certtool --generate-certificate --load-privkey serverkey.pem \
|
||||||
Certificate:
|
--load-ca-certificate cacert.pem --load-ca-privkey cakey.pem \
|
||||||
Data:
|
--template server.info --outfile servercert.pem
|
||||||
Version: 3 (0x2)
|
|
||||||
Serial Number:
|
|
||||||
dd:b4:0f:d0:58:0e:08:fb
|
|
||||||
Signature Algorithm: sha1WithRSAEncryption
|
|
||||||
Issuer: C=GB, ST=London, L=London, O=Red Hat UK Ltd, OU=Emerging Technologies, CN=Red Hat/emailAddress=rjones@redhat.com
|
|
||||||
Validity
|
|
||||||
Not Before: May 10 11:10:40 2007 GMT
|
|
||||||
Not After : May 9 11:10:40 2008 GMT
|
|
||||||
Subject: C=GB, ST=London, L=London, O=Red Hat UK Ltd, OU=Emerging Technologies, CN=oirase/emailAddress=rjones@redhat.com
|
|
||||||
</pre>
|
</pre>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
Note the "Issuer" CN is "Red Hat" (the CA) and the "Subject" CN is
|
This gives two files:
|
||||||
"oirase" (the server).
|
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
|
<ul>
|
||||||
|
<li>
|
||||||
|
<code>serverkey.pem</code> - The server's private key.
|
||||||
|
</li>
|
||||||
|
<li>
|
||||||
|
<code>servercert.pem</code> - The server's public key.
|
||||||
|
</li>
|
||||||
|
</ul>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
At this point we have <code>newreq.pem</code> which contains the
|
We can examine this certificate and its signature:
|
||||||
private key and unsigned certificate and <code>newcert.pem</code>
|
|
||||||
which contains the signed certificate. For the server we need just
|
|
||||||
the private key and signed certificate. For the clients we need just
|
|
||||||
the signed certificate. So there is one final step which is to
|
|
||||||
extract the private key from <code>newreq.pem</code>:
|
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<pre>
|
<pre>
|
||||||
<b>openssl rsa -in newreq.pem -out serverkey.pem</b>
|
<b>certtool -i --infile servercert.pem</b>
|
||||||
Enter pass phrase for newreq.pem:
|
X.509 certificate info:
|
||||||
writing RSA key
|
|
||||||
|
|
||||||
<b>mv newcert.pem servercert.pem</b>
|
Version: 3
|
||||||
|
Serial Number (hex): 00
|
||||||
|
Subject: O=Red Hat Emerging Technologies,CN=oirase
|
||||||
|
Issuer: CN=Red Hat Emerging Technologies
|
||||||
|
Signature Algorithm: RSA-SHA
|
||||||
|
Validity:
|
||||||
|
Not Before: Mon Jun 18 16:34:49 2007
|
||||||
|
Not After: Tue Jun 17 16:34:49 2008
|
||||||
</pre>
|
</pre>
|
||||||
|
|
||||||
|
<p>
|
||||||
|
Note the "Issuer" CN is "Red Hat Emerging Technologies" (the CA) and
|
||||||
|
the "Subject" CN is "oirase" (the server).
|
||||||
|
</p>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
Finally we have two files to install:
|
Finally we have two files to install:
|
||||||
</p>
|
</p>
|
||||||
@ -2027,26 +1939,29 @@ steps.
|
|||||||
|
|
||||||
<ol>
|
<ol>
|
||||||
<li>
|
<li>
|
||||||
Make a private key and a request for a new certificate:
|
Make a private key:
|
||||||
<pre>
|
<pre>
|
||||||
./CA.pl -newreq
|
certtool --generate-privkey > clientkey.pem
|
||||||
</pre>
|
|
||||||
Set the DN fields as required.
|
|
||||||
</li>
|
|
||||||
|
|
||||||
<li>
|
|
||||||
Act as CA and sign the certificate:
|
|
||||||
<pre>
|
|
||||||
./CA.pl -signreq
|
|
||||||
</pre>
|
</pre>
|
||||||
</li>
|
</li>
|
||||||
|
|
||||||
<li>
|
<li>
|
||||||
Extract the private key for the client and rename the
|
Act as CA and sign the certificate. Create client.info containing:
|
||||||
signed certificate:
|
|
||||||
<pre>
|
<pre>
|
||||||
openssl rsa -in newreq.pem -out clientkey.pem
|
country = GB
|
||||||
mv newcert.pem clientcert.pem
|
state = London
|
||||||
|
locality = London
|
||||||
|
organization = Red Hat
|
||||||
|
cn = client1
|
||||||
|
tls_www_client
|
||||||
|
encryption_key
|
||||||
|
signing_key
|
||||||
|
</pre>
|
||||||
|
and sign by doing:
|
||||||
|
<pre>
|
||||||
|
certtool --generate-certificate --load-privkey clientkey.pem \
|
||||||
|
--load-ca-certificate cacert.pem --load-ca-privkey cakey.pem \
|
||||||
|
--template client.info --outfile clientcert.pem
|
||||||
</pre>
|
</pre>
|
||||||
</li>
|
</li>
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user