You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Michael Shuler (JIRA)" <ji...@apache.org> on 2016/08/17 00:01:43 UTC

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

     [ https://issues.apache.org/jira/browse/CASSANDRA-12109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Shuler updated CASSANDRA-12109:
---------------------------------------
    Fix Version/s:     (was: 3.9)
                   3.8

> 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.8
>
>
> 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)