[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

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 0.15
• Fix Version/s: 0.15
• Component/s: Broker-J, Java Documentation, JMS AMQP 0-x
• Assignee: Keith Wall
• Reporter: Keith Wall
• Created: 10/Jan/12 09:10
• Updated: 11/Feb/15 20:07
• Resolved: 14/Feb/12 10:32

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