Tim Quinn wrote on 07/08/2010 03:30 PM:
> Bill raised some interesting points about what would be in the keystores
> and truststores, esp. with respect to sync.
>
> Things actually get simpler if the DAS and the instances share the same
> keystore and truststore via the sync mechanism.
>
> First, looking separately at what the DAS needs and what an instance
> needs to mutually authenticate over SSL:
>
> | Req'd by DAS | Req'd by instance |
> =====================================================
> needed | | |
> in the | DAS private | instance private |
> keystore | key entry | key entry |
> -----------------------------------------------------
> needed | | |
> in the | instance trusted | DAS trusted |
> truststore | public cert entry | public cert entry |
> -----------------------------------------------------
>
> Second, let's say that all instances will use the same instance key
> pair. (This is a change from my earlier thoughts.)
>
> Now, during domain creation the DAS would create not only the key pair
> it will use for its own authentication but also the single key pair that
> all instances will use. It would store both private keys into its
> keystore and both trusted cert entries into its truststore.
>
> Then, the initial sync for the new instance will place a copy of the
> common keystore and truststore files in the instance's directory. This
> avoids the problem Bill alluded to of an instance-generated key that was
> stored in the (sync-ed) keystore being overwritten during a later sync.
> Also, the instance would not need to send the DAS its public key cert
> because the instance keys would not be unique and the DAS already knows
> the keys which all instances will use.
There's still the bootstrap/startup problem.
What authentication do you use for the first sync request? And where
do you get it? Before the sync, there is no keystore on the client.
Some choices are:
1. creating the instance ensures that the instance starts with a
keystore instead of starting with nothing.
2. we save the admin username and password in the das.properties file
and use that for authentication during synchronization.
3. we have a separate "node agent" keystore that contains the authentication
information we use during synchronization.
And don't forget that with whatever approach we choose there needs to be
a way to change the authentication information used for synchronization,
preferably without a manual step on each node.