cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "T Jake Luciani (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-12109) Configuring SSL for JMX connections forces requirement of local truststore
Date Thu, 07 Jul 2016 17:58:11 GMT

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

T Jake Luciani updated CASSANDRA-12109:
---------------------------------------
    Status: Open  (was: Patch Available)

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

Mime
View raw message