Author: buildbot
Date: Wed May 2 15:41:20 2012
New Revision: 815453
Log:
Staging update by buildbot for ace
Modified:
websites/staging/ace/trunk/content/ (props changed)
websites/staging/ace/trunk/content/dev-doc/design/using-client-certificates.html
Propchange: websites/staging/ace/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Wed May 2 15:41:20 2012
@@ -1 +1 @@
-1333075
+1333079
Modified:
websites/staging/ace/trunk/content/dev-doc/design/using-client-certificates.html
==============================================================================
---
websites/staging/ace/trunk/content/dev-doc/design/using-client-certificates.html
(original)
+++
websites/staging/ace/trunk/content/dev-doc/design/using-client-certificates.html
Wed May 2 15:41:20 2012
@@ -153,7 +153,7 @@
<h1>Using client certificate authentication</h1>
<div class="clear"></div>
<div id="content"><p><em>Using two-way SSL as authentication mechanism
in ACE</em></p>
-<p>Revision 0.9, last updated: May 2nd, 2012.</p>
+<p>Revision 1.0, last updated: May 2nd, 2012.</p>
<div class="toc">
<ul>
<li><a href="#introduction">Introduction</a></li>
@@ -168,7 +168,7 @@
</ul>
</div>
<h2 id="introduction">Introduction</h2>
-<p>One-way SSL authentication is used to let a client verify the identity of
the server it is communicating with. The server itself does not verify the
identity of the client. In two-way SSL authentication, a client first verifies
the identity of the server after which the server identifies the client. This
way, the identity of both the client and server can be established allowing a
trust relation can be created.<br />
+<p>One-way SSL authentication is used to let a client verify the identity of
the server it is communicating with. The server itself does not verify the
identity of the client. In two-way SSL authentication, a client first verifies
the identity of the server after which the server identifies the client. This
way, the identity of both the client and server can be established allowing a
trust relation to be created.<br />
This article describes how to configure the ACE server and the management
agent(s) in such way that they use two-way SSL authentication. The remainder of
this article assumes the reader has basic knowledge of the principles behind
ACE, and has basic knowledge about creating and using certificates. For this
article, the latest code of ACE (0.8.1-SNAPSHOT, rev.1332609) was used.</p>
<h2 id="outline">Outline</h2>
<p>As described in detail in [1], there are multiple communication paths that
can (and need) to be secured. For two-way SSL authentication, several scenarios
can be identified:</p>
@@ -198,7 +198,7 @@ The details on how to create a self-sign
<p><em>Note to double check the paths to both files, as there will not be
printed any error in case one of them points to an incorrect file!</em></p>
-<p>For the ACE server, the configuration is provided by means of a
property-file called <tt>platform.properties</tt>. Similar as the management
agent, we should add some additional properties to it:</p>
+<p>For the ACE server, the configuration is provided by means of a
property-file called <tt>platform.properties</tt>. Similar to the management
agent, we should add some additional properties to it:</p>
<div class="codehilite"><pre><span
class="na">-Dorg.osgi.service.http.port.secure</span><span
class="o">=</span><span class="s">8443</span>
<span class="na">-Dorg.apache.felix.https.enable</span><span
class="o">=</span><span class="s">true</span>
<span class="na">-Dorg.apache.felix.https.truststore</span><span
class="o">=</span><span class="s">/path/to/truststore</span>
@@ -209,7 +209,7 @@ The details on how to create a self-sign
</pre></div>
-<p>This will not only ensure that the Jetty container inside ACE will obtain
the correct keystore and truststore and start a listener on port <tt>8443</tt>,
but also mandates that all clients <strong>must</strong> provide a certificate
upon connecting (as denoted by the last property). Without this, client that do
not offer a client certificate will simply be accepted as well, hence resulting
in only one-way SSL authentication.<br />
+<p>This will not only ensure that the Jetty container inside ACE will obtain
the correct keystore and truststore and start a listener on port <tt>8443</tt>,
but also mandates that all clients <strong>must</strong> provide a certificate
upon connecting (as denoted by the last property). Without this, clients that
do not offer a certificate will simply be accepted as well, hence resulting in
only one-way SSL authentication.<br />
</p>
<p>In order to secure all internal communication paths as well, we need to
specify some additional properties in <tt>platform.properties</tt>:</p>
<div class="codehilite"><pre><span
class="na">-Djavax.net.ssl.keyStore</span><span class="o">=</span><span
class="s">/path/to/keystore-server</span>
@@ -258,6 +258,8 @@ Note that in order to let <strong>all</s
<dd>The user should have the same name as the common name of the certificate,
for example, <tt>localhost</tt> or <tt>10.0.1.16</tt>;</dd>
<dt>I've enabled two-way SSL authentication, but it doesn't work!</dt>
<dd>There can be many reasons for this, like, can the truststore and keystore
files be loaded (<em>no warnings or errors will be printed for this!</em>), or,
is the name of the certificate matching the name of the host, or � In
general, if it doesn't work, one should enable SSL-debugging in Java by adding
<tt>-Djavax.net.debug=ssl</tt> as system property. This will print
<em>lots</em> of information about the keystore and truststore, the
communication itself as well as detailed error messages. Also, the
authentication parts in ACE provide lots of debugging information, logged at
<tt>DEBUG</tt> level.</dd>
+<dt>What if my target runs on a machine with a dynamic IP address? Can I still
use client certificates for authentication?</dt>
+<dd>Not directly. Java uses the common name of the certificate and
<em>assumes</em> this to be a valid, resolvable, hostname. If not, it will fail
to accept the certificate as being valid. In the near future, ACE should <a
href="https://issues.apache.org/jira/browse/ACE-271";>support this
functionality</a>.</dd>
</dl>
<h2 id="references">References</h2>
<ol>
