[ https://issues.apache.org/jira/browse/KAFKA-7685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16815466#comment-16815466 ]
Jorg Heymans commented on KAFKA-7685: ------------------------------------- Alternatively, also consider accepting just an InputStream pointing to the location of the truststore. The classpath is definitely not the only place people are storing certificate stores. {code:java} Inputstream trustStoreInputStream = ... props.put(SSL_TRUSTSTORE_LOCATION_CONFIG, trustStoreInputStream);{code} > Support loading trust stores from classpath > ------------------------------------------- > > Key: KAFKA-7685 > URL: https://issues.apache.org/jira/browse/KAFKA-7685 > Project: Kafka > Issue Type: Improvement > Components: clients > Affects Versions: 2.1.0 > Reporter: Noa Resare > Priority: Minor > > Certificate pinning as well as authenticating kafka brokers using a > non-public CA certificate maintained inside an organisation is desirable to a > lot of users. This can be accomplished today using the > {{ssl.truststore.location}} configuration property. Unfortunately, this value > is always interpreted as a filesystem path which makes distribution of such > an alternative truststore a needlessly cumbersome process. If we had the > ability to load a trust store from the classpath as well as from a file, the > trust store could be shipped in a jar that could be declared as a regular > maven style dependency. > If we did this by supporting prefixing {{ssl.truststore.location}} with > {{classpath:}} this could be a backwards compatible change, one that builds > on prior design patterns established by for example the Spring project. -- This message was sent by Atlassian JIRA (v7.6.3#76005)