[
https://issues.apache.org/jira/browse/WSS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh updated WSS-184:
------------------------------------
Affects Version/s: 1.5.7
Fix Version/s: 1.6
> Specifying alternate cacerts keystore via properties?
> -----------------------------------------------------
>
> Key: WSS-184
> URL: https://issues.apache.org/jira/browse/WSS-184
> Project: WSS4J
> Issue Type: Improvement
> Components: WSS4J Core
> Affects Versions: 1.5.7
> Environment: Glassfish V2 UR2, Java 1.5
> Reporter: Andrew
> Assignee: Colm O hEigeartaigh
> Fix For: 1.6
>
>
> I'm wondering if it would be possible for the Crypto classes to be able to
> use an alternate cacerts file? As I use Glassfish for my application, it
> would be nice for me to be able to specify Glassfish's cacerts keystore as
> the one to use instead of the default Java one, for both certificate
> generation and certificate validation. Currently, AbstractCrypto has it
> essentially hard-coded as $JAVA_HOME/lib/security/cacerts, which isn't ideal.
> In an ideal world, this would also apply to WSHandler.verifyTrust (and so on).
> Is this a feasible idea? I'm not an expert in these things (at all. Not even
> close), so I'm not even sure if I should be using the Glassfish keystore for
> things other than the SSL key/cert. The answer is, I think, that I have to,
> regardless of whether or not it's a bad idea, as we don't necessarily have
> full control over the machines we use, and modifying the system-wide keystore
> could land me in a lot of trouble.
> Thanks all,
> - Andrew
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
