[
https://issues.apache.org/jira/browse/CASSANDRA-13259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15905828#comment-15905828
]
Jason Brown edited comment on CASSANDRA-13259 at 3/11/17 2:49 AM:
------------------------------------------------------------------
wrt {{store_type}}, can java8 correctly figure out the difference between a
PKCS12 and JKS? Further, what if somebody went bananas and used a JCEKS (I'm
not totally sure this case applies to TLS)? I agree with you that one declared
{{store_type}} is not correct for all situations (covering both the key and
trust stores), but that leads us logically to having a separate {{store_type}}
config option for both keystore and truststore. The {{javax.net.ssl.*}} allow a
differentiation of the store types, but see next paragraph.
wrt JVM-based properties ({{javax.net.ssl.*}}), we currently allow users to
have a different configuration for client-server and internode (peero-to-peer)
communications. By removing both options in favor of using the JVM-based
properties, operators who previously had separate configs are now forced to use
the same config for both, and I'm not sure how big of a breakage that is (in
terms of the actual number of opertators/clusters affected).
Also, I spoke with one of the netty developers, and they ignore the
{{javax.net.ssl.*}} properties. Thus I don't think the JVM-based properties is
the way to go.
UPDATE: We could *still* use the {{javax.net.ssl.*}} properties, but we would
need to plumb them through ourselves to netty. So perhaps there's an advantage
for the the operator (using the properties is "consistent" with JVM
conventions), but we incur a larger cost of supporting those options and
correctly translating those to netty-land.
was (Author: jasobrown):
wrt {{store_type}}, can java8 correctly figure out the difference between a
PKCS12 and JKS? Further, what if somebody went bananas and used a JCEKS (I'm
not totally sure this case applies to TLS)? I agree with you that one declared
{{store_type}} is not correct for all situations (covering both the key and
trust stores), but that leads us logically to having a separate {{store_type}}
config option for both keystore and truststore. The {{javax.net.ssl.*}} allow a
differentiation of the store types, but see next paragraph.
wrt JVM-based properties ({{javax.net.ssl.*}}), we currently allow users to
have a different configuration for client-server and internode (peero-to-peer)
communications. By removing both options in favor of using the JVM-based
properties, operators who previously had separate configs are now forced to use
the same config for both, and I'm not sure how big of a breakage that is (in
terms of the actual number of opertators/clusters affected).
Also, I spoke with one of the netty developers, and they ignore the
{{javax.net.ssl.*}} properties. Thus I don't think the JVM-based properties is
the way to go.
> Use platform specific X.509 default algorithm
> ---------------------------------------------
>
> Key: CASSANDRA-13259
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13259
> Project: Cassandra
> Issue Type: Improvement
> Components: Configuration
> Reporter: Stefan Podkowinski
> Assignee: Stefan Podkowinski
> Priority: Minor
> Fix For: 4.x
>
>
> We should replace the hardcoded "SunX509" default algorithm and use the JRE
> default instead. This implementation will currently not work on less popular
> platforms (e.g. IBM) and won't get any further updates.
> See also:
> https://bugs.openjdk.java.net/browse/JDK-8169745
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
