I should mention, when toggling disablebinary/enablebinary between instances, you will probably want to give some time between doing this so connections can reestablish, and you will want to verify that the connections can actually reestablish. You also need to be mindful of this being disruptive to inflight queries (if your client is configured for retries it will probably be fine). Semantically to your applications it should look a lot like a rolling cluster bounce.
Thanks, Andy On Mon, Apr 15, 2024 at 11:39 AM pabbireddy avinash <pabbireddyavin...@gmail.com> wrote: > > Thanks Andy for your reply . We will test the scenario you mentioned. > > Regards > Avinash > > On Mon, Apr 15, 2024 at 11:28 AM, Tolbert, Andy <x...@andrewtolbert.com> > wrote: >> >> Hi Avinash, >> >> As far as I understand it, if the underlying keystore/trustore(s) >> Cassandra is configured for is updated, this *will not* provoke >> Cassandra to interrupt existing connections, it's just that the new >> stores will be used for future TLS initialization. >> >> Via: >> https://cassandra.apache.org/doc/4.1/cassandra/operating/security.html#ssl-certificate-hot-reloading >> >> > When the files are updated, Cassandra will reload them and use them for >> > subsequent connections >> >> I suppose one could do a rolling disablebinary/enablebinary (if it's >> only client connections) after you roll out a keystore/truststore >> change as a way of enforcing the existing connections to reestablish. >> >> Thanks, >> Andy >> >> >> On Mon, Apr 15, 2024 at 11:11 AM pabbireddy avinash >> <pabbireddyavin...@gmail.com> wrote: >> > >> > Dear Community, >> > >> > I hope this email finds you well. I am currently testing SSL certificate >> > hot reloading on a Cassandra cluster running version 4.1 and encountered a >> > situation that requires your expertise. >> > >> > Here's a summary of the process and issue: >> > >> > Reloading Process: We reloaded certificates signed by our in-house >> > certificate authority into the cluster, which was initially running with >> > self-signed certificates. The reload was done node by node. >> > >> > Truststore and Keystore: The truststore and keystore passwords are the >> > same across the cluster. >> > >> > Unexpected Behavior: Despite the different truststore configurations for >> > the self-signed and new CA certificates, we observed no breakdown in >> > server-to-server communication during the reload. We did not upload the >> > new CA cert into the old truststore.We anticipated interruptions due to >> > the differing truststore configurations but did not encounter any. >> > >> > Post-Reload Changes: After reloading, we updated the cqlshrc file with the >> > new CA certificate and key to connect to cqlsh. >> > >> > server_encryption_options: >> > >> > internode_encryption: all >> > >> > keystore: ~/conf/server-keystore.jks >> > >> > keystore_password: XXXX >> > >> > truststore: ~/conf/server-truststore.jks >> > >> > truststore_password: XXXX >> > >> > protocol: TLS >> > >> > algorithm: SunX509 >> > >> > store_type: JKS >> > >> > cipher_suites: [TLS_RSA_WITH_AES_256_CBC_SHA] >> > >> > require_client_auth: true >> > >> > client_encryption_options: >> > >> > enabled: true >> > >> > keystore: ~/conf/server-keystore.jks >> > >> > keystore_password: XXXX >> > >> > require_client_auth: true >> > >> > truststore: ~/conf/server-truststore.jks >> > >> > truststore_password: XXXX >> > >> > protocol: TLS >> > >> > algorithm: SunX509 >> > >> > store_type: JKS >> > >> > cipher_suites: [TLS_RSA_WITH_AES_256_CBC_SHA] >> > >> > Given this situation, I have the following questions: >> > >> > Could there be a reason for the continuity of server-to-server >> > communication despite the different truststores? >> > Is there a possibility that the old truststore remains cached even after >> > reloading the certificates on a node? >> > Have others encountered similar issues, and if so, what were your >> > solutions? >> > >> > Any insights or suggestions would be greatly appreciated. Please let me >> > know if further information is needed. >> > >> > Thank you >> > >> > Best regards, >> > >> > Avinash
