[ 
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)

Reply via email to