[ 
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:[email protected]

Reply via email to