#1 is not an option. We removed the normal Bouncy Castle distribution from AG 1.0-M5, due to included code with IP restrictions that required users to acquire an IDEA license. Only a few portions of Bouncy Castle that was needed and did not have IP restrictions was pulled into the geronimo source tree under modules/util.

Where is JKS hard-coded? Can you not override JKS in var/config/config.xml to use your different provider? If not, then please open a JIRA issue with details on the problems you run into.


-Donald


Nikolay Chugunov wrote:
Hello The name of Sun-specific key store type is hardcoded in the sources, so it might not work on non-Sun VMs.
From my point of view, there are two ways to fix this problem:

1. Always use BKS key store of Bouncy Castle ( http://www.bouncycastle.org) security provider, because it is open-source project. Geronimo can use BKS if I just replace JKS word to BKS of in the source of Geronimo. In this case Bouncy Castle security provider should be in class path in Geronimo.

2. Change sources so Geronimo will use a key store type which exists in VM. Key store type existing in VM can be discovered by invoking KeyStore.getDefaultType() method. Disadvantage of this way: if I build Geronimo on Sun VM, it generates JKS key store file, which might not be read by other VM, because of lack JKS key store implementation. So binary builds might not work on other VMs.

Can you advise which way Geronimo should use?

**** **Nikolay *Chugunov** *
****** *Intel* Middleware Product Division*** .*

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to