Hi Andy, Internode encryption is not possible without downtime prior to Apache Cassandra 4.0. As there is no optional option before 4.0 under server_encryption_options, If you try to enable it, cassandra running on version 3.x wouldn't start as the property isnt available. optional is only available client_encryption_options for the clusters running < 4.0 (prior 4.0).
E.g., Exception encountered during startup: Invalid yaml. Please remove properties [optional] from your cassandra.yaml Below link clearly gives idea about the fix in 4.0 and states why it's not possible to implement internode encryption without down time before 4.0. https://issues.apache.org/jira/browse/CASSANDRA-10404 By Any chance, did you try to enable internode encryption in 3.x without downtime and were successful? Can you please confirm. Best Regards, Kiran.M.K. On Wed, Nov 10, 2021 at 12:04 PM Tolbert, Andy <x...@andrewtolbert.com> wrote: > > Hi Shaurya, > > On Tue, Nov 9, 2021 at 11:57 PM Shaurya Gupta <shaurya.n...@gmail.com> wrote: >> >> Hi, >> >> We want to enable node-to-node SSL on a live cluster. Could it be done >> without any down time ? > > > Yup, this is definitely doable for both internode and client connections. > You will have to bounce your cassandra nodes, but you should be able to > achieve this operation without any downtime. See server_encryption_options > in cassandra.yaml > (https://cassandra.apache.org/doc/4.0/cassandra/configuration/cass_yaml_file.html#server_encryption_options) > >> >> Would the nodes which have been restarted be able to communicate with the >> nodes which have not yet come up and vice versa ? > > > The idea would be to: > > 1. Set optional to true in server_encryption_options and bounce the cluster > safely into it. As nodes come up, they will first attempt to connect to > other nodes via ssl, and fallback on the unencrypted storage_port. > 2. Once you have bounced the entire cluster once, switch optional to false > and then bounce the cluster again. > > Before 4.0, a separate port (ssl_storage_port) was used for connecting with > internode via ssl. In 4.0, storage_port can be used for both unencrypted and > encrypted connections, and enable_legacy_ssl_storage port can be used to > maintain ssl_storage_port. Once the entire cluster is on 4.0 you can set this > option to false so storage_port is used over ssl_storage_port. > > One important thing to point out is that prior to C* 4.0, Cassandra does not > hot reload keystore changes, so whenever you update the certificates in your > keystores (e.g. to avoid your certificates expiring) you would need to bounce > your cassandra instances. See: > https://cassandra.apache.org/doc/4.0/cassandra/operating/security.html#ssl-certificate-hot-reloading > for explanation on how that works. > > Thanks, > Andy > >> >> >> Regards >> -- >> Shaurya Gupta >> >> -- Best Regards, Kiran.M.K.
