Re: Re : Generic keystore when enabling SSL

[sai krishnam raju potturi <ps...@gmail.com>]

hi Jacob;

     I would suggest you create your own Certificate Authority, and create
a generic keystore and trustore.

    Cassandra by default does not implement HostName Verification in it's
code. All it does is to check if it's peer certificate is signed by the
trusted authority ( the root CA in the truststore).

        In short; if you were to have a COMODO signed certificate, and i
have a COMODO signed certificate, i will be able to establish communication
with your node. The reason being, Cassandra only checks if the peer
certificate is signed by a trusted authority, which it'll be in this case.

       Even wild card certificates with multiple SAN's is of no use here,
as Cassandra does no SAN or CN verification.

   If you were to have your own CA, there will be no way for me to
establish the chain of trust.

thanks
Sai




On Fri, Oct 28, 2016 at 2:06 AM, Vladimir Yudovin <vl...@winguzone.com>
wrote:

> Hi Jacob,
>
> there is no problem to use the same certificate (whether issued by some
> authority or self signed) on all nodes until it's present in truststore. CN
> doesn't matter in this case, it can be any string you want.
>
> Would this impact client-to-node encryption
>
> Nu, but clients should either add nodes certificate to their truststore or
> disable validation (each Cassandra driver does this in its own way).
>
> Best regards, Vladimir Yudovin,
>
> *Winguzone <https://winguzone.com?from=list> - Hosted Cloud
> CassandraLaunch your cluster in minutes.*
>
>
> ---- On Thu, 27 Oct 2016 16:45:48 -0400*Jacob Shadix
> <jacobshadix@gmail.com <ja...@gmail.com>>* wrote ----
>
> I am interested if anyone has taken this approach to share the same
> keystore across all the nodes with the 3rd party root/intermediate CA
> existing only in the truststore. If so, please share your experience and
> lessons learned. Would this impact client-to-node encryption as the
> certificates used in internode would not have the hostnames represented in
> CN?
>
> -- Jacob Shadix
>
> On Wed, Sep 21, 2016 at 11:40 AM, sai krishnam raju potturi <
> pskraju88@gmail.com> wrote:
>
> hi Evans;
>    rather than having one individual certificate for every node, we are
> looking at getting one Comodo wild-card certificate, and importing that
> into the keystore. along with the intermediate CA provided by Comodo. As
> far as the trust-store is concerned, we are looking at importing the
> intermediate CA provided along with the signed wild-card cert by Comodo.
>
>    So in this case we'll be having just one keystore (generic), and
> truststore we'll be copying to all the nodes. We've run into issues
> however, and are trying to iron that out. Interested to know if anybody in
> the community has taken a similar approach.
>
>    We are pretty much going on the lines of following post by LastPickle
> http://thelastpickle.com/blog/2015/09/30/hardening-cassandra-
> step-by-step-part-1-server-to-server.html. Instead of creating our own
> CA, we are relying on Comodo.
>
> thanks
> Sai
>
>
> On Wed, Sep 21, 2016 at 10:30 AM, Eric Evans <jo...@gmail.com>
> wrote:
>
> On Tue, Sep 20, 2016 at 12:57 PM, sai krishnam raju potturi
> <ps...@gmail.com> wrote:
> > Due to the security policies in our company, we were asked to use 3rd
> party
> > signed certs. Since we'll require to manage 100's of individual certs, we
> > wanted to know if there is a work around with a generic keystore and
> > truststore.
>
> Can you explain what you mean by "generic keystore"?  Are you looking
> to create keystores signed by a self-signed root CA (distributed via a
> truststore)?
>
> --
> Eric Evans
> john.eric.evans@gmail.com
>
>
>

Re: Re : Generic keystore when enabling SSL

[Eric Evans <jo...@gmail.com>]

On Thu, Nov 17, 2016 at 10:52 AM, sai krishnam raju potturi
<ps...@gmail.com> wrote:
> I would suggest you create your own Certificate Authority, and create a
> generic keystore and trustore.

FWIW, that's what we (WMF) do: https://github.com/eevans/cassandra-ca-manager

-- 
Eric Evans
john.eric.evans@gmail.com