[
https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17524704#comment-17524704
]
Dinesh Joshi commented on CASSANDRA-17513:
------------------------------------------
Hi [~maulin.vasavada] I've updated the title to reflect more clearly as per
your recommendation.
My preference is to stick to explicit vs implicit. This makes things very clear
for operators. There are no magical assumptions hidden in the code. So,
currently we have connection settings for native protocol and internode
communication. The native protocol further splits the settings into server and
client settings. I believe we should keep the same pattern as it maintains
consistency in the configuration. We could certainly use the same server/client
truststore/keystore across both native and internode configuration. Nothing
preventing us from doing that. So, at best the operator deals with one
truststore and one keystore across both settings blocks. This is no worse than
today. Now, if the operator can choose to generate a unique truststore and
keystore for native and internode configuration. In this situation its by
choice and nothing in Cassandra should force them to do this.
On the extendedKeyUsage, one big downside is that the server and client
certificates are stored in the same file on disk. Client certificates can
expire rather quickly and this will translate into more frequent updates to the
server certificates due to hot reloading. We will need to add additional logic
to the hot reloading code path to ensure we do not reload the server
certificate when the client certificate changes. This is undesirable behavior
IMHO. A number of systems may not support packing server and client
certificates into the same store file. We may actually cause additional burden
in that situation by requiring operators to write scripts to package both
server and client certificates in the same store file. This is unnecessary. I
am open to considering implementing this idea if we don't force operators to
explicitly a single store file i.e. maintain backward compatibility with what
we have. However, it feels like this should be out of scope here and we can
create a separate ticket to address it across both native and internode
configurations. WDYT?
> Adding support for TLS client authentication for internode communication
> ------------------------------------------------------------------------
>
> Key: CASSANDRA-17513
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17513
> Project: Cassandra
> Issue Type: Bug
> Reporter: Jyothsna Konisa
> Assignee: Jyothsna Konisa
> Priority: Normal
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Same keystore is being set for both Inbound and outbound connections but we
> should use a keystore with server certificate for Inbound connections and a
> keystore with client certificates for outbound connections. So we should add
> a new property in Cassandra.yaml to pass outbound keystore and use it in
> SSLContextFactory for creating outbound SSL context.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
