You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wss4j-dev@ws.apache.org by "Andrew (JIRA)" <ji...@apache.org> on 2009/05/05 12:15:30 UTC
[jira] Created: (WSS-184) Specifying alternate cacerts keystore via
properties?
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
Environment: Glassfish V2 UR2, Java 1.5
Reporter: Andrew
Assignee: Ruchith Udayanga Fernando
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: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Resolved: (WSS-184) Specifying alternate cacerts keystore
via properties?
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colm O hEigeartaigh resolved WSS-184.
-------------------------------------
Resolution: Fixed
I've just commited a fix to trunk to allow you to specify a truststore. Example configuration:
org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin
org.apache.ws.security.crypto.merlin.truststore.password=security
org.apache.ws.security.crypto.merlin.truststore.file=keys/wss40CA.jks
If you could grab the latest trunk, compile it and test it that'd be great!
Colm.
> 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: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Assigned: (WSS-184) Specifying alternate cacerts keystore
via properties?
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colm O hEigeartaigh reassigned WSS-184:
---------------------------------------
Assignee: Colm O hEigeartaigh (was: Ruchith Udayanga Fernando)
> 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: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Updated: (WSS-184) Specifying alternate cacerts keystore via
properties?
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ 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: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Closed: (WSS-184) Specifying alternate cacerts keystore via
properties?
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colm O hEigeartaigh closed WSS-184.
-----------------------------------
> 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: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org