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

Outline

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:

@@ -198,7 +198,7 @@ The details on how to create a self-sign

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 platform.properties. 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 platform.properties. Similar to the management agent, we should add some additional properties to it:

-Dorg.osgi.service.http.port.secure=8443
 -Dorg.apache.felix.https.enable=true
 -Dorg.apache.felix.https.truststore=/path/to/truststore
@@ -209,7 +209,7 @@ The details on how to create a self-sign

This will not only ensure that the Jetty container inside ACE will obtain the correct keystore and truststore and start a listener on port 8443, 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 8443, 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 platform.properties:

-Djavax.net.ssl.keyStore=/path/to/keystore-server
@@ -258,6 +258,8 @@ Note that in order to let allThe user should have the same name as the common name of the certificate, for example, localhost or 10.0.1.16;
 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 -Djavax.net.debug=ssl 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 DEBUG 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.
 
 References

Using client certificate authentication

Introduction

Outline

References