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:
Richard W.M. Jones 2007-06-18 16:00:16 +00:00
parent af933f6ff0
commit 81bb16b302
2 changed files with 118 additions and 198 deletions

View File

@ -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

View File

@ -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>
&mdash; 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 &gt; 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 &gt; 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 &gt; 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>