cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Carlise <>
Subject unable to gossip with peers exception when internode encryption is set to any setting other than 'none'
Date Mon, 26 Aug 2019 20:55:48 GMT
I originally opened this issue on stackoverflow (

However, I haven't gotten any responses in over a week.  I'm going to post
it here and maybe someone will have an idea on where I can look.

We currently run a multi region cassandra cluster in AWS. It runs in four
regions, 12 nodes per region. It runs without node to node encryption (or
client encryption either). We are trying to enable inter datacenter node to
node encryption. However, when we flip encryption over we get an exception
that nodes are unable to gossip with any peers.

It could possibly be that we didn't build our jks keystore/truststores
correctly (more on how we built these files below). But, we additionally do
not see intra datacenter communication working (which should be set to
unencrypted communication). Additionally, cqlsh cannot connect to the node
either; even though we have (by default) client_auth_required set to false.

ERROR [main] 2019-08-15 18:46:32,241 -
Exception encountered during startup
java.lang.RuntimeException: Unable to gossip with any peers
        at org.apache.cassandra.gms.Gossiper.doShadowRound(
        at org.apache.cassandra.service.StorageService.checkForEndpointCollision(
        at org.apache.cassandra.service.StorageService.prepareToJoin(
        at org.apache.cassandra.service.StorageService.initServer(
        at org.apache.cassandra.service.StorageService.initServer(
        at org.apache.cassandra.service.CassandraDaemon.setup(
        at org.apache.cassandra.service.CassandraDaemon.activate(
        at org.apache.cassandra.service.CassandraDaemon.main(
INFO  [main] 2019-08-15 18:47:07,384 -
Configuration location: file:/etc/cassandra/cassandra.yaml

Something to note is that this error message occurs after a few minutes of
the node being up. (i.e. there is a delay between start up before this
exception is thrown).

*Information about our cassandra setup*

cassandra version: 3.11.4
JDK version: openjdk-8.
Linux: Ubuntu 18.04 (bionic).


endpoint_snitch: Ec2MultiRegionSnitch

  internode_encryption: dc
  keystore: <omitted>
  keystore_password: <omitted>
  truststore: <omitted>
  truststore_password: <omitted>

  enabled: false



*No obvious errors with SSH output*

When starting cassandra with JVM_OPTS="$JVM_OPTS" added
to we see SSL logs printed to stdout (*Note: Subject and
Issuer were omitted on purpose)*.

found key for : cassy-us-west-2
adding as trusted cert:
  Subject: ...
  Issuer:  ...
  Algorithm: RSA; Serial number: 0xdad28d843fc73325d4c1a75207d4e74
  Valid from Fri May 27 00:00:00 UTC 2016 until Tue May 26 23:59:59 UTC 2026


trigger seeding of SecureRandom
done seeding SecureRandom

Looking at Java SE SSL/TLS connection debugging
this looks correct. But to note, we see this series of messages (along with
the RSA key signature output) repeated several times in rapid fire. We
never observe any messages about the trust store being added; however that
might be something that occurs only on client initiation (?)

Additionally, we do see cassandra report that the Encrypted Messaging
service has been started.

INFO  [main] 2019-08-15 18:45:31,022 -
Starting Encrypted Messaging Service on SSL port 7001

*Doesn't appear to be a cassandra.yaml configuration problem*

We can bring the node back online by simply configuring internode_encryption:
none. This action seems to rule out a broadcast_address or rpc_address
configuration problem.

*How we built our keystore/truststores*

We followed the basic template datastax docs for preparing SSL certificates
One minor difference was that our private key and CSRs were generated using
openssl. One per each region (we plan to share key/signed certs across
nodes in regions). This was created using a command template as:

openssl req -new -newkey rsa:2048 -out cassy-<region>.csr -keyout
cassy-<region>.key -config cassy-<region>.conf -subj "..." -nodes

The generated CSR was then signed by an internal root CA. Because we
generated our files using openssl, we had to build our jks files by
importing our certs into them.

*Commands to generate truststore*

We distribute this one file to all nodes.

keytool -importcert
    -keystore generic-server-truststore.jks
    -alias rootCa
    -file rootCa.crt
    -keypass omitted
    -storepass omitted

*Commands to generate keystore*

This was done one per region; but essentially we created a keystore with
keytool, then deleted the key entry and then imported our key entry using
keytool from a pkcs12 file.

keytool -genkeypair -keyalg RSA -alias cassy-${region} -keystore
cassy-${region}.jks -storepass omitted -keypass omitted -validity 365
-keysize 2048 -dname "..."

keytool -delete -alias cassy-${region} -keystore cassy-${region}.jks
-storepass omitted

openssl pkcs12 -export -in signed_certs/${region}.pem -inkey
keys/cassandra.${region}.key -name cassy-${region} -out ${region}.p12

keytool -importkeystore -deststorepass omitted -destkeystore
cassy-${region}.jks -srckeystore ${region}.p12 -srcstoretype PKCS12

keytool -importcert -keystore cassy-${region}.jks -alias rootCa -file
ca.crt -noprompt -keypass omitted -storepass omitted

Looking back at this, I don't remember why we used keytool to generate a
keypair/keystore, then deleted and imported. I think it was because the
keytool importkeystore command refused to run if the keystore didn't
already exist.

*ca.crt and pem file*

The ca.crt file contains the root certificate and the intermediate
certificate that was used to sign the CSR. The pem file contains the signed
CSR returned to us, the intermediate cert, and the root CA (in that order).

*openssl verify ca.crt and pem*

openssl verify -CAfile ca.crt us-west-2.pem
signed_certs/us-west-2.pem: OK

*Command output after enabling encryption*

*nodetool status (output truncated)*

Datacenter: us-east
|/ State=Normal/Leaving/Joining/Moving
--  Address         Load       Tokens       Owns (effective)  Host ID
?N    ?          256          25.4%             null
?N  ?          256          23.2%             null
Datacenter: us-west-2
|/ State=Normal/Leaving/Joining/Moving
--  Address         Load       Tokens       Owns (effective)  Host ID
?N    ?          256          26.5%             null
UN    105.99 GiB  256          23.7%             null
?N  ?          256          24.7%             null

With the online node being the node with encryption set.

*cqlsh to localhost*

cassy-node6:~$ cqlsh
Connection error: ('Unable to connect to any servers', {'':
error(111, "Tried connecting to [('', 9042)]. Last error:
Connection refused")})

*cqlsh to remote node* Remote node is a node with encryption enabled

cassy-node6:~$ cqlsh
Connection error: ('Unable to connect to any servers', {'':
error(111, "Tried connecting to [('', 9042)]. Last error:
Connection refused")})

View raw message