The Sun implementation of the
keytool utility is useful in many circumstances
where users have disjoint databases. In Figure 11.1
we showed just such an example, and we mentioned that this example
was set up in such a way that the code signer and the end user could
have different key databases.
This is not to say, however, that those two databases could not have been the same database—that is, one that is shared by the signer and the end user. Since access to the private key of the signer is protected by a password, the signer and the end user are able to share a single database without concern that the end user may obtain access to the signer’s private key (assuming that she keeps her password secret, of course). In the case of a corporate network, this flexibility is important, since an enterprise may want to maintain a single database that contains the private keys of all of its employees as well as the certificates of all known external entities.
We could have these users share the
keystore by using the appropriate filename in the application and the
java.policy files. But sharing the keytool
database by a file is somewhat inefficient. If the global file is on
a machine in New York and is referenced by a user in Tokyo,
you’ll want to use a better network protocol to access it than
a file-based protocol. In addition, the
load() method reads in the entire file. If there are 10,000 users in your corporate keystore database, you shouldn’t need to read ...