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
