cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ron Blechman (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-13314) Config file based SSL settings
Date Tue, 06 Feb 2018 17:43:00 GMT


Ron Blechman commented on CASSANDRA-13314:

Adding the ability for Cassandra to use SSLContext.getDefault() and/or SSLFactory.getDefault()
would be helpful here, particularly in cases where one would like to implement additional
checking / custom implementations for certificate validation (i.e. certificate revocation,
host name validation, etc.)

> Config file based SSL settings
> ------------------------------
>                 Key: CASSANDRA-13314
>                 URL:
>             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
and we should just point the user to the right files to do that (jvm.options and
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 (
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
> * 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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message