SSL Server Keystore (multiple entries)

What do you mean by 'only the trusstore nr1 works'?

I would say that is expected behaviour, and corresponds to what I said above. Both server certs have the same properties so the server is probably always choosing the first certificate, so only nr1 works at the client because only nr1 knows about the first server cert.

Why do you think you need two server certs with the same crypto properties?

ejpa at 2007-7-14 19:27:47 >

Then you are doing entirely the wrong thing. You need to do the following:

1. Create a set of client certs, each in a separate keystore.

2. Get them signed (export/signed by CA/reimport), or create them self-signed.

3. Export them to .cer files and import them into the server's truststore.

4. Distribute each keystyore to the corresponding client, and configure each client to treat this file as its keystore.

5. Set the server's SSLServerSocket to needClientAuth = true.

6. Have a single signed cert in the server's keystore, same process as at (1,2).

7. Export that to a .cer file and import it into a single truststore.

8. Distribute that same truststore to all clients and have them all use that file as their truststore.

OK? For non-Java clients you will have to do something different at step 4.

Then, when the server accepts a new connection, get the peer certificate or identity at the server either from the SSLSessionContext or a HandshakeCompletedEvent delivered to a HandshakeCompletedListener.

ejpa at 2007-7-14 19:27:47 >

Why not?

Normally you would do this if you were going to have a lot of variegated clients with different kinds, or levels, of crypto support (e.g. RSA, DSA). In this case you would need to have multiple signed private-key certificates to match all possible client configurations. What happens is this:

1. client sends ClientHello message, incorporating the crypto protocols the client can handle and a random number

2. server replies with ServerHello message, incorporating the ditto that the server can handle and a random number

3. server sends a certificate that matches the intersection of the protocols; in Java this comes from the server's keystore

4. If the server wants the client cert, it sends a CertRequest to the client, and the client responds with its cert chosen as in (3).; in Java this comes from the client's keystore.

5. Any cert that arrives at either end is checked against the local truststore.

So you see there is no sending of multiple certs, just one is sent (in each direction), and it has to match the intersection of the protocols as far as its crypto algorithms and key lengths &c are concerned.

ejpa at 2007-7-14 19:27:47 >