You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Keith Wall (Commented) (JIRA)" <ji...@apache.org> on 2012/02/09 20:42:00 UTC
[jira] [Commented] (QPID-3739) Java properties
qpid.ssl.keyStoreCertType and qpid.ssl.trustStoreCertType have misleading
names and would be better called
qpid.ssl.[Key|Trust]ManagerFactory.algorithm
[ https://issues.apache.org/jira/browse/QPID-3739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13204770#comment-13204770 ]
Keith Wall commented on QPID-3739:
----------------------------------
I'll remove the DEFAULT_ALGORITHM_NAME, we don't need it.
I decided to default the algorithm names using KeyManagerFactory#getDefaultAlgorithm() and TrustManagerFactory#getDefaultAlgorithm() rather than using the system properties ssl.KeyManagerFactory.algorithm and ssl.TrustManagerFactory.algorithm to avoid the possibility that those system properties can return null on some JVM platforms. I think it reasonable to assume that all platforms will return a default value.
The Jetty defect mentions the GnuJVM. The classpath docs say that getDefaultAlgorithm() returns JessieX509.
> Java properties qpid.ssl.keyStoreCertType and qpid.ssl.trustStoreCertType have misleading names and would be better called qpid.ssl.[Key|Trust]ManagerFactory.algorithm
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: QPID-3739
> URL: https://issues.apache.org/jira/browse/QPID-3739
> Project: Qpid
> Issue Type: Bug
> Components: Documentation, Java Broker, Java Client
> Affects Versions: 0.15
> Reporter: Keith Wall
> Assignee: Keith Wall
> Fix For: 0.15
>
>
> The Java client supports two system properties, {{qpid.ssl.trustStoreCertType}} and {{qpid.ssl.keyStoreCertType}} that the Programming-In-Apache-Qpid docbook describe as "the certificate type". These properties are defaulted to {{SunX509}} in ConnectionSettings.java and SSLContextFactory.java.
> Similarly, the Java broker supports a configuration item {{connector/ssl/certType}} which is again defaulted to {{SunX509}} in ServerConfiguration.
> On all code paths, these values are passed down to {{javax.net.ssl.KeyManagerFactory
> #getInstance()}} and {{javax.net.ssl.TrustManagerFactory#getInstance()}}
> The confusion is that {{KeyManagerFactory#getInstance()}}/{{TrustManagerFactory#getInstance()}} do not accept a certificate type at all. It accepts a key/trust manager factory algorithm name.
> It would be better if the existing property names were deprecated and a more accurate name used, such as
> qpid.ssl.KeyManagerFactory.algorithm/qpid.ssl.TrustManagerFactory.algorithm. We would continue to support the existing properties, with a warning for a time period.
> I also notice that other projects tend to default the algorithm to Security.getProperty("ssl.KeyManagerFactory.algorithm" and only fallback to SunX509 if that is null. This plays better with non Sun JDKs such as IBMs. See: http://jira.codehaus.org/browse/JETTY-70
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org