Author: jawi
Date: Wed May 2 15:41:02 2012
New Revision: 1333079
URL: http://svn.apache.org/viewvc?rev=1333079&view=rev
Log:
Some typos fixed and a new FAQ entry added.
Modified:
ace/site/trunk/content/dev-doc/design/using-client-certificates.mdtext
Modified: ace/site/trunk/content/dev-doc/design/using-client-certificates.mdtext
URL:
http://svn.apache.org/viewvc/ace/site/trunk/content/dev-doc/design/using-client-certificates.mdtext?rev=1333079&r1=1333078&r2=1333079&view=diff
==============================================================================
--- ace/site/trunk/content/dev-doc/design/using-client-certificates.mdtext
(original)
+++ ace/site/trunk/content/dev-doc/design/using-client-certificates.mdtext Wed
May 2 15:41:02 2012
@@ -2,13 +2,13 @@ Title: Using client certificate authenti
_Using two-way SSL as authentication mechanism in ACE_
-Revision 0.9, last updated: May 2nd, 2012.
+Revision 1.0, last updated: May 2nd, 2012.
[TOC]
## Introduction
-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.
+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.
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.
@@ -45,7 +45,7 @@ For the management agent, we need to add
*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!*
-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:
+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:
:::properties
-Dorg.osgi.service.http.port.secure=8443
@@ -56,7 +56,7 @@ For the ACE server, the configuration is
-Dorg.apache.felix.https.keystore.password=secret
-Dorg.apache.felix.https.clientcertificate=needs
-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 **must** 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.
+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 **must** 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.
In order to secure all internal communication paths as well, we need to
specify some additional properties in <tt>platform.properties</tt>:
@@ -114,6 +114,9 @@ How should I name the users that are aut
I've enabled two-way SSL authentication, but it doesn't work!
: There can be many reasons for this, like, can the truststore and keystore
files be loaded (*no warnings or errors will be printed for this!*), 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 *lots* 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.
+What if my target runs on a machine with a dynamic IP address? Can I still use
client certificates for authentication?
+: Not directly. Java uses the common name of the certificate and *assumes*
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 [support this
functionality](https://issues.apache.org/jira/browse/ACE-271).
+
## References
@@ -128,3 +131,4 @@ I've enabled two-way SSL authentication,
[^2]: Using a self-signed CA for two-way SSL authentication is not that much
of a problem as one needs to make the certificate of the client available to
the server, and the other way around. When both certificates are signed by the
same CA, and both sides also trust this self-signed CA, the trust relation
between client and server can be established as well.
[^3]: Based on the certificate in the truststore, each side will be able to
validate the certificate of the other side.
+
