[
https://issues.apache.org/jira/browse/GEODE-419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15746498#comment-15746498
]
Udo Kohlmeyer commented on GEODE-419:
-------------------------------------
I believe that this anomaly has now been fixed with the new
SSLConfigurationFactory implementation. IF ssl is enabled (by either
ssl-enabled=true or *-ssl-enabled=true) the configuration will try all possible
avenues to configure the ssl properties. As a last resort it will use the
java.net.ssl.* properties.
Maybe we need to add a test to explicitly test this, but I believe it is now
resolved.
> javax.net.ssl.* gemfire properties ignored if ssl-enabled is false
> ------------------------------------------------------------------
>
> Key: GEODE-419
> URL: https://issues.apache.org/jira/browse/GEODE-419
> Project: Geode
> Issue Type: Bug
> Components: configuration
> Reporter: Darrel Schneider
> Priority: Minor
>
> You are supposed to be able to put javax.net.ssl.* system property
> definitions in your gemfire.properties and have them be used to configure ssl.
> They work ok if ssl-enabled is true and cluster-ssl-enabled is not set. But
> if you set cluster-ssl-enabled (to true or false) then the javax.net.ssl.*
> properties are ignored. The same is also true for http-service-ssl-enabled.
> This can be worked around by using the new cluster-ssl-keystore* and
> cluster-ssl-truststore* gemfire properties instead of javax.net.ssl.*.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
