[
https://issues.apache.org/jira/browse/QPID-3739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-3739:
-----------------------------
Description:
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
was:
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
.KeyManagerFactory.getInstance().
The confusion is that KeyManagerFactory.getInstance() does not accept a
certificate type at all. It accepts a key manager factory algorithm.
It would be better if the existing property names where deprecated and a more
accurate name used, such as
qpid.ssl.keyManagerFactory.algorithm. We would continue to support the
existing properties, with a warning for a time period.
It is not clear to me that the we need a separate truststore and keystore
versions of this property.
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
Fix Version/s: 0.15
Assignee: Keith Wall
Summary: Java properties qpid.ssl.keyStoreCertType and
qpid.ssl.trustStoreCertType have misleading names and would be better called
qpid.ssl.[Key|Trust]ManagerFactory.algorithm (was: Java properties
qpid.ssl.keyStoreCertType and qpid.ssl.trustStoreCertType have misleading names
and would be better called qpid.ssl.keyManagerFactory.algorithm)
Committed patch.
* Introduced two properties qpid.ssl.KeyManagerFactory.algorithm and
qpid.ssl.TrustManagerFactory.algorithm to allow a client user to override the
algorithm name used w
* Continued to support qpid.ssl.keyStoreCertType and
qpid.ssl.trustStoreCertType (now marked as deprecated)
* Introduced a new Java Broker configuration key
connector/ssl/keyManagerFactoryAlgorithm
* Continued to support broker configuration key connector/ssl/certType (now
marked as deprecated and will issue warning if used).
* Changed the default from hardcoded 'SunX509' to the value(s) returned by
KeyManagerFactory#getDefaultAlgorithm() and
TrustManagerFactory#getDefaultAlgorithm(). This
* Updated client docbook documentation.
Tested both Java Broker and Client on IBM JDK and ensured all 0-10 and
0-9-1 profiles pass (including SSLTest which was failing prior to this change).
> 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]
