[
https://issues.apache.org/jira/browse/CASSANDRA-12109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-12109:
----------------------------------------
Fix Version/s: (was: 3.8)
(was: 3.7)
(was: 3.6)
3.x
3.0.x
> Configuring SSL for JMX connections forces requirement of local truststore
> --------------------------------------------------------------------------
>
> Key: CASSANDRA-12109
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12109
> Project: Cassandra
> Issue Type: Bug
> Components: Configuration, Lifecycle, Observability
> Reporter: Sam Tunnicliffe
> Assignee: Sam Tunnicliffe
> Fix For: 3.0.x, 3.x
>
>
> In CASSANDRA-10091 we changed the way the JMX server is constructed such that
> this is always done programatically, which gives us control over the
> authentication and authorization mechanisms. Previously, when
> {{LOCAL_JMX=no}}, Cassandra would allow the JMX setup to be done by the built
> in JVM agent, which delegates to
> {{sun.management.jmxremote.ConnectorBootstrap}} to do the actual JMX & RMI
> setup.
> This change has introduced a regression when SSL is enabled for JMX
> connections, namely that now it is not possible to start C* with only the
> server-side elements of the SSL setup specified. That is, if enabling SSL
> with {{com.sun.management.jmxremote.ssl=true}}, it should only be necessary
> to specify a keystore (via {{javax.net.ssl.keyStore}}), and a truststore
> should only be necessary if client authentication is also enabled
> ({{com.sun.management.jmxremote.ssl.need.client.auth=true}}).
> As it is, C* cannot currently startup without a truststore containing the
> server's own certificate, which is clearly a bug.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
