ace-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From j...@apache.org
Subject svn commit: r1333079 - /ace/site/trunk/content/dev-doc/design/using-client-certificates.mdtext
Date Wed, 02 May 2012 15:41:02 GMT
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.
+



Mime
View raw message