You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Sumanth Pasupuleti (Jira)" <ji...@apache.org> on 2021/06/07 15:17:00 UTC

[jira] [Updated] (CASSANDRA-16719) Allow for transitioning from using one SSLContextFactory implementation to another

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

Sumanth Pasupuleti updated CASSANDRA-16719:
-------------------------------------------
    Summary: Allow for transitioning from using one SSLContextFactory implementation to another  (was: Allow for transitioning from using one SSLFactory implementation to another)

> Allow for transitioning from using one SSLContextFactory implementation to another
> ----------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-16719
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-16719
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Sumanth Pasupuleti
>            Assignee: Sumanth Pasupuleti
>            Priority: Normal
>
> With CASSANDRA-16666 providing pluggable SSLContext, this ticket is to provide mechanics for being able to transparently transition from using one SSLContext implementation to another.
> As indicated in https://issues.apache.org/jira/browse/CASSANDRA-16666?focusedCommentId=17358655&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17358655,
> one could do the following on their cluster for moving from say Implementation1 to Implementation2
> Stage #1: Current state of being only Implementation1 aware. Use keystore and trustmanager of implementation1
> Stage #2: Start trusting both implementation1 and implementation2. Use keystore of implementation1, but use trustmanager of both implementation1 and implementation2 (using MultiTrustManagerFactory) (and perform a rolling restart of the cluster)
> Stage #3: Start using implementation2 for keystore, and perform a rolling restart of the cluster
> Stage #4: At this point, all nodes of the cluster are using implementation2 for keystore, but trust both implementation1 and implementation2, and we can now remove implementation1 from trustmanagers, and do a rolling restart.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org