[jira] [Updated] (CASSANDRA-12109) Configuring SSL for JMX connections forces requirement of local truststore

["Sam Tunnicliffe (JIRA)" <ji...@apache.org>]

     [ 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)