[
https://issues.apache.org/jira/browse/GERONIMO-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562806#action_12562806
]
Vasily Zakharov commented on GERONIMO-3757:
-------------------------------------------
Summarizing, it seems we can assume the following things to be true:
- KeyStore.getDefaultType() is never null,
- KeyStore.getInstance(KeyStore.getDefaultType()) doesn't throw exceptions,
- KeyStore.getDefaultType() value is always present in providers list.
Right?
With these taken into account, we probably could use the following code for
initialization:
{code:java}
static {
// Get all the KeyStore algorithms supported.
keystoreTypes = new HashSet<String>();
defaultType = KeyStore.getDefaultType();
Provider[] providers = Security.getProviders();
char[] emptystore = "emptystore".toCharArray();
for(Provider provider: providers) {
for(Provider.Service service: provider.getServices()) {
if(service.getType().equals("KeyStore")) {
// Not all types of keystores can be saved to disk when
empty.
// Do not add those types that will fail creation of an
empty keystore.
ByteArrayOutputStream baos = null;
try {
KeyStore ks = KeyStore.getInstance(type);
ks.load(null);
baos = new ByteArrayOutputStream();
ks.store(baos, emptystore);
String type = service.getAlgorithm();
keystoreTypes.add(type);
} catch(Throwable t) {
} finally {
if(baos != null) {
try {baos.close();} catch(Exception ignored){}
}
}
}
}
}
}
{code}
Objections?
As of loading keystore files, using default or file extensions sounds ok, but
it seems still possible to try to determine the keystore file type by trying to
load it with all available providers. What are disadvantages of this idea? It
seems pretty reliable. What about an algorithm like the following:
- Check file extension, if provider with such name exist, use that type.
- If extension is not identified, try to load with all available providers.
- If failed, use default type.
Considerations?
> KeyStore type can't be changed
> ------------------------------
>
> Key: GERONIMO-3757
> URL: https://issues.apache.org/jira/browse/GERONIMO-3757
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: security
> Affects Versions: 2.0.2, 2.0.x, 2.1
> Reporter: Vasily Zakharov
> Attachments: Geronimo-3757-trunk.patch, Geronimo-3757.patch,
> Geronimo-3757.patch, GERONIMO-3757.patch
>
>
> For now (r612905), Geronimo is hardcoded to use JKS keystore type, which
> prevents Geronimo from running on Harmony or other JDKs that have no JKS
> implementation:
> org.apache.geronimo.security.keystore.FileKeystoreInstance, line 635:
> KeyStore tempKeystore = KeyStore.getInstance(JKS);
> org.apache.geronimo.security.keystore.FileKeystoreManager, line 364:
> KeyStore keystore =
> KeyStore.getInstance(FileKeystoreInstance.JKS);
> To workaround this issue, one can change JKS to KeyStore.getDefaultType()
> (this returns "BKS" for Harmony) or particular other keystore type, but this
> requires source recompilation. Replacing
> var/security/keystores/geronimo-default with the proper keystore type file is
> not a problem.
> A proper solution seems to apply the fix above to use the JDK-default
> keystore type, and provide FileKeystoreInstance with an additional
> configuration option, keystoreType, that would allow to change the keystore
> type through config.xml without recompilation, like this:
> <module name="org.apache.geronimo.configs/server-security-config/2.0.2/car">
> <gbean name="geronimo-default">
> <attribute name="keystoreType">PKCS12</attribute>
> <attribute
> name="keystorePath">var/security/keystores/geronimo-pkcs12</attribute>
> </gbean>
> </module>
> This issue if a follow up to GERONIMO-2015.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
