Cassandra SSL authentication in a nutshell

Steven Lacerda
2 min readJan 9, 2020

--

SSL is terribly difficult to understand, so I thought I would teach myself, and in the process hopefully help some of you.

First, you need to understand who the client is in a client/server relationship because the client may not always be the client and the server may not always be the server. In all cases, the client is the node requesting the SSL verification, and the server is responding with its certifcation.

In terms of Cassandra, for one way authentication, you have a client (java driver) and a server (cassandra cluster node):

  1. The client sends a request to the server requesting SSL.
  2. The server responds with its public certificate.
  3. The client verifies the server’s SSL certificate with the certificate authority that issued it. This confirms that the server is who it says it is, and that the client is interacting with the actual owner of the domain.
  4. If the certificate checks out, the client sends a random string of bytes, the “premaster secret.” The premaster secret is encrypted with the public key and can only be decrypted with the private key by the server.
  5. The server decrypts the premaster secret.
  6. If everything checks out, we have authentication and encryption now.

Now, in two-way authentication, or if require_client_auth: true is set in cassandra.yaml, then the client also is authenticated. Thus, in step 2, when the server responds with its public certificate, it asks the client for the same. Thus, both sides verify the authenticity of the other sides' certificates.

Some things to recognize. The private key is private, it’s never sent anywhere other than the client…NEVER. And all private things, along with their public portion are kept in a Keystore. And what I mean by public, is that when a private key is generated, it has a public portion also, this is the portion of the certificate that gets sent off to the CA for signing via a CSR. Thus, a keystore is what that node owns, and only what that node owns.

Public certificates, from other nodes, are kept in the truststore, not the Keystore. This is where the server checks for certificates when it wants to verify client certificates. It does NOT check its Keystore, because that is private and only used by the client. The truststore contains the certificates of nodes that you trust (intermediate and root certificates, you don’t need the nodes public certificate).

In short, a Keystore holds certificates that identify us, a truststore holds certificates that identify others.

--

--

Steven Lacerda
Steven Lacerda

Written by Steven Lacerda

Steve Lacerda is a software engineer specializing in web development. His favorite 80’s song is Let’s Put the X in Sex by Kiss.

No responses yet