Print

[javacfish]

Hi lolo,

Thanks for you help. I had deployed the source code of JPPF. Now I has another questions:

Can server node distinguish the nodes and clients through the SSL certificate? I think it is important for the secure tasks submission. If the server nodes could recognize the nodes and clients by reading the different SSL certificates of nodes and clients, so only the people, who obtain the client SSL certificate, can submit the tasks.

How do you think? What is your opinions?

Thanks!

Sincerely,
javacfish

[lolo]

Hello javacfish,

This can be accomplished by enabling ssl client authentication in the JPPF driver's configuration, as described here:

Code: [Select]

jppf.ssl.client.auth = need
Additionally, for this to work you will need to add the JPPF nodes and clients SSL certificates to the JPPF server's trust store. You will thus need to create the server trust store, import the certifactes into it, and finally configure its location.

I hope this clarifies,
-Laurent

[javacfish]

Thanks lolo.

Maybe I do not express my ideas clearly. It seems the nodes and clients has the same SSL keystore in the server part. You know, the nodes could deploy many different computers. If I get the keystores of nodes, I will has the keystore of clients.

My means:

Could the server create two kinds of keystores: one is only for the nodes, another is only for client which is used to submit the task?  if the clients only get the keystores of nodes, the client still do not connect to the server.

Can the JPPF solve this problem?

Thanks

Sincerely,
javacfish

[lolo]

Hello,

I think you misunderstand how SSL authentication works. Here's how the JPPF configuration must be in the 1-way and 2-way authentication scenarios

1) 1 way authentication for nodes and clients: in this scenario the nodes and clients check that the server is really who it pretends to be.
- the server has its own key store, which contains a private/public key pair. The server doesn't need a trust store
- each node and client has a trust store which contains a server certifcate generated from the server's public key. They don't need to have their own key store.
Keep in mind that a trust store is a container for certificates only, whereas the key store is a container for private/public key pairs.

2) 2 way authentication: in addition to the nodes/clients checking that the server can be trusted, the server will also check that each node or client can be trusted. For this you need:
- for each node or client, a key store containing a private/public key pair for that specific node or client. This is in addition to the trust store which contains the server certificate.
- for the server, a trust store which contains the certificates of all the nodes and clients which are allowed to connect. Each of these certificates is generated from the corresponding node or client's public key. In addition, you still need to have the server key store with the server's private/public key pair.
In this configuration, what will determine if a node or client can connect is if the server has the corresponding valid certificate in its trust store.
If all you need is to distinguish between nodes and clients, then you can just create 2 private/public key pairs along with the corresponding key stores: one for the nodes and one for the clients. From these 2 key stores, you will generate a node-specific certificate and a client-specific certificate, and add these 2 certificates to the server trust store.

If this is still not clear, I invite you to read more on SSL authentication. For instance, I found this article to be a good introduction.

Sincerely,
-Laurent

[javacfish]

Thanks lolo, Your help is very useful. I would read it clearly.

My purpose: I would supply nodes for everyone to download for constructing my own grid computing. In this situation, the directory of "config/ssl" of nodes will expose for everyone.

I do experiment:

I generate two trust store for clients and nodes, respectively, then:

1. Delete the files "keystores.ks" and "truststore.ks" of "config/ssl" in clients
2. Download the nodes which I supplied.
3. Copy the files "keystores.ks" and "truststore.ks" of nodes into the clients.

The clients still can connect to the server and submitted the task into the server.

It means JPPF could not distinguish the nodes and clients clearly. Anyone, who get the files of "config/ssl" of nodes, could submit their jobs. It would be trouble with managing the grid network.

So how do JPPF only let the client connect to sever with the client's own trust store rather than node's own trust store?

I do not know how to solve this problem? Or could you give me some suggestions?

Thanks again!

Sincerely,
javacfish 

[lolo]

Thanks for clarifying the use case.

Well, indeed this is not supported by JPPF. This is definitely a flaw in how we handle SSL authentication, and I registered a bug report: JPPF-186 SSL services unable to distinguish between client and node certificates. We will release a fix for the next maintenance release JPPF v3.3.6. This means you will have to upgrade to this version: we will not backport the fix for earlier versions, as it is a major change of the existing code.

As you suggested earlier, the fix will probably be to enable, in the driver's configuration, to specify whether to use separate trust stores for nodes and clients that connect to the server. So, we will add a boolean property to specify this, plus additional properties to specify the nodes and clients trust stores sources, along with their corresponding password sources. When the boolean property is set to false (the default), then the server will perform as in earlier versions (same trust store for nodes and clients).

We will release v3.3.6 in the month of September, 2013. I cannot yet be more precise than this.

Sincerely,
-Laurent