[
https://issues.apache.org/jira/browse/CASSANDRA-13314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15905833#comment-15905833
]
Jason Brown commented on CASSANDRA-13314:
-----------------------------------------
See my comments on CASSANDRA-13259, but TL;DR netty doesn't use the
{{javax.net.ssl.*}} properties.
> Config file based SSL settings
> ------------------------------
>
> Key: CASSANDRA-13314
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13314
> Project: Cassandra
> Issue Type: Improvement
> Components: Configuration, Tools
> Reporter: Stefan Podkowinski
> Assignee: Stefan Podkowinski
> Priority: Minor
> Fix For: 4.x
>
>
> As follow up of CASSANDRA-13259, I'd like to continue discussing how we can
> make SSL less awkward to use and further move SSL related code out of our
> code base. Currently we construct our own SSLContext in SSLFactory based on
> EncryptionOptions passed by the MessagingService or any individual tool where
> we need to offer SSL support. This leads to a situation where the user has
> not only to learn how to enable the correct settings in cassandra.yaml, but
> these settings must also be reflected in each tool's own command line
> options. As argued in CASSANDRA-13259, these settings could be done as well
> by setting the appropriate system and security properties
> ([overview|http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#InstallationAndCustomization])
> and we should just point the user to the right files to do that (jvm.options
> and java.security) and make sure that daemon and all affected tools will
> source them.
> Since giving this a quick try on my WIP branch, I've noticed the following
> issues in doing so:
> * Keystore passwords will show up in process list
> (-Djavax.net.ssl.keyStorePassword=..). We should keep the password setting in
> cassandra.yaml and clis and do a System.setProperty() if they have been
> provided.
> * It's only possible to configure settings for a single default
> key-/truststore. Since we currently allow configuring both
> ServerEncryptionOptions and ClientEncryptionOptions with different settings,
> we'd have to make this a breaking change. I don't really see why you would
> want to use different stores for node-to-node and node-to-client, but that
> wouldn't be possible anymore.
> * This would probably only make sense if we really remove the affected CLI
> options, or we'll end up with just another way to configure this stuff. This
> will break existing scripts and obsolete existing documentation.
> Any opinions?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
