> On Sep 22, 2021, at 8:03 AM, Bowen Song wrote:
>
> Interesting. The better approach is to match the certificate's common name or
> SAN to the CQL username. This way the authorisation part, which depends on
> the CQL username, will continue to work as usual.
>
Yes, that is one way of
Hello Dinesh,
/> The client certificate can be used to ensure that it is a trusted
client. If a bad actor is able to not only obtain a valid client
certificate but also the private key pair then you have bigger issues :)/
Not really. As I said, it depends on the threat model. For example,
> On Sep 22, 2021, at 2:02 AM, Bowen Song wrote:
> Out of curiosity, I have two further questions.
>
> 1. I know the client can optionally provider a certificate for the TLS
> handshake, but is it possible to require the client to provide a certificate?
>
Yep, you can turn on
Out of curiosity, I have two further questions.
1. I know the client can *optionally* provider a certificate for the TLS
handshake, but is it possible to *require* the client to provide a
certificate?
2. Does Cassandra check that the username matches the client
certificate? E.g. TLS client
Thanks Dinesh.
That is ok. Having mutual TLS ensures that the clients authenticate
themselves by certificates too.
The other authentication of static username/password adds the next layer of
authentication.
That ways a hacker now needs two keys (certificate and password) to connect
to the cluster.
It sort of supports it. You still need to send in the username/password
credentials along with the client certificate to authenticate. Cassandra will
not derive the identity purely from the client certificate.
Dinesh
> On Sep 21, 2021, at 11:59 AM, S G wrote:
>
> Hello,
>
> Does anyone know
