<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Replicate Kafka target with publicly-trusted TLS/SSL certificate: ca path? in Qlik Replicate</title>
    <link>https://community.qlik.com/t5/Qlik-Replicate/Replicate-Kafka-target-with-publicly-trusted-TLS-SSL-certificate/m-p/1732641#M361</link>
    <description>&lt;P&gt;In Replicate Kafka endpoint we use librdkafka as our client library. We truly and mandatory verify the existence of the CA file. The new librdkafka allows you to set the&lt;EM&gt; ssl.sa.location&lt;/EM&gt; as &lt;EM&gt;&lt;STRONG&gt;probe&amp;nbsp;&lt;/STRONG&gt;&lt;/EM&gt;and it allows you to use known CA cert paths.&lt;/P&gt;&lt;P&gt;Quoting librdkafka v1.5:&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;EM&gt;&lt;FONT face="impact,chicago"&gt;&lt;FONT face="terminal,monaco"&gt;If OpenSSL is linked statically, or&amp;nbsp;ssl.ca.location=&lt;STRONG&gt;probe&amp;nbsp;&lt;/STRONG&gt;is configured,&lt;/FONT&gt;&lt;BR /&gt;&lt;FONT face="terminal,monaco"&gt;librdkafka will probe known CA certificate paths and automatically use the&lt;/FONT&gt;&lt;BR /&gt;&lt;FONT face="terminal,monaco"&gt;first one found. This should alleviate the need to configure&lt;/FONT&gt;&lt;BR /&gt;&lt;FONT face="terminal,monaco"&gt;ssl.ca.location&amp;nbsp;when the statically linked OpenSSL's OPENSSLDIR differs&lt;/FONT&gt;&lt;BR /&gt;&lt;FONT face="terminal,monaco"&gt;from the system's CA certificate path.&lt;/FONT&gt;&lt;/FONT&gt;&lt;/EM&gt;&lt;/P&gt;&lt;P&gt;Currently, our compiled librdkafka is v1.3, which does not support this option.&lt;/P&gt;&lt;P&gt;I think this is a legitimate request and I suggest you add it as a "new idea" (in Community &amp;gt; Qlik Product Insight &amp;amp; Ideas), where the PM can gather votes and then consider pushing it into the work-plan. Eventually, we will upgrade our librdkafka to the most innovative and open this option for the users, but this "new idea" may promote it and may focus us on the list of recently supported features that our customers really need.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Sun, 02 Aug 2020 15:49:58 GMT</pubDate>
    <dc:creator>EyalSilner</dc:creator>
    <dc:date>2020-08-02T15:49:58Z</dc:date>
    <item>
      <title>Replicate Kafka target with publicly-trusted TLS/SSL certificate: ca path?</title>
      <link>https://community.qlik.com/t5/Qlik-Replicate/Replicate-Kafka-target-with-publicly-trusted-TLS-SSL-certificate/m-p/1709315#M244</link>
      <description>&lt;P&gt;I have a question about using a Replicate Kafka target, which is protected with TLS/SSL with a publicly-trusted X.509 certificate - that is, one that your web-browser would trust if it were talking HTTPS, since the certificate is ultimately signed by a trusted root certificate.&amp;nbsp; Example of such a service - Confluent Cloud Kafka cluster endpoints.&lt;/P&gt;&lt;P&gt;If I connect to this endpoint using e.g. openssl, on Linux this will load a standard set of trusted root cacerts, and the handshake will be trusted.&lt;/P&gt;&lt;P&gt;In Replicate Kafka target, if using TLS/SSL, the "CA file" field becomes mandatory - is there any option to avoid the need to locate a PEM-encoded certificate-chain, instead trusting via a local root-certificate store?&lt;/P&gt;&lt;P&gt;This question extends to using the excellent Replicate Test Drive - if I want to connect from that hosted environment to a Confluent Cloud TLS Kafka bootstrap/broker - is there any path on the server that will work for "CA path" which includes the trusted roots, or if not, can I upload one?&lt;/P&gt;</description>
      <pubDate>Tue, 09 Jun 2020 09:08:01 GMT</pubDate>
      <guid>https://community.qlik.com/t5/Qlik-Replicate/Replicate-Kafka-target-with-publicly-trusted-TLS-SSL-certificate/m-p/1709315#M244</guid>
      <dc:creator>brett</dc:creator>
      <dc:date>2020-06-09T09:08:01Z</dc:date>
    </item>
    <item>
      <title>Re: Replicate Kafka target with publicly-trusted TLS/SSL certificate: ca path?</title>
      <link>https://community.qlik.com/t5/Qlik-Replicate/Replicate-Kafka-target-with-publicly-trusted-TLS-SSL-certificate/m-p/1732641#M361</link>
      <description>&lt;P&gt;In Replicate Kafka endpoint we use librdkafka as our client library. We truly and mandatory verify the existence of the CA file. The new librdkafka allows you to set the&lt;EM&gt; ssl.sa.location&lt;/EM&gt; as &lt;EM&gt;&lt;STRONG&gt;probe&amp;nbsp;&lt;/STRONG&gt;&lt;/EM&gt;and it allows you to use known CA cert paths.&lt;/P&gt;&lt;P&gt;Quoting librdkafka v1.5:&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;EM&gt;&lt;FONT face="impact,chicago"&gt;&lt;FONT face="terminal,monaco"&gt;If OpenSSL is linked statically, or&amp;nbsp;ssl.ca.location=&lt;STRONG&gt;probe&amp;nbsp;&lt;/STRONG&gt;is configured,&lt;/FONT&gt;&lt;BR /&gt;&lt;FONT face="terminal,monaco"&gt;librdkafka will probe known CA certificate paths and automatically use the&lt;/FONT&gt;&lt;BR /&gt;&lt;FONT face="terminal,monaco"&gt;first one found. This should alleviate the need to configure&lt;/FONT&gt;&lt;BR /&gt;&lt;FONT face="terminal,monaco"&gt;ssl.ca.location&amp;nbsp;when the statically linked OpenSSL's OPENSSLDIR differs&lt;/FONT&gt;&lt;BR /&gt;&lt;FONT face="terminal,monaco"&gt;from the system's CA certificate path.&lt;/FONT&gt;&lt;/FONT&gt;&lt;/EM&gt;&lt;/P&gt;&lt;P&gt;Currently, our compiled librdkafka is v1.3, which does not support this option.&lt;/P&gt;&lt;P&gt;I think this is a legitimate request and I suggest you add it as a "new idea" (in Community &amp;gt; Qlik Product Insight &amp;amp; Ideas), where the PM can gather votes and then consider pushing it into the work-plan. Eventually, we will upgrade our librdkafka to the most innovative and open this option for the users, but this "new idea" may promote it and may focus us on the list of recently supported features that our customers really need.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Sun, 02 Aug 2020 15:49:58 GMT</pubDate>
      <guid>https://community.qlik.com/t5/Qlik-Replicate/Replicate-Kafka-target-with-publicly-trusted-TLS-SSL-certificate/m-p/1732641#M361</guid>
      <dc:creator>EyalSilner</dc:creator>
      <dc:date>2020-08-02T15:49:58Z</dc:date>
    </item>
    <item>
      <title>Re: Replicate Kafka target with publicly-trusted TLS/SSL certificate: ca path?</title>
      <link>https://community.qlik.com/t5/Qlik-Replicate/Replicate-Kafka-target-with-publicly-trusted-TLS-SSL-certificate/m-p/1741122#M459</link>
      <description>&lt;P&gt;To connect Qlik Replicate with Confluent Cloud, what you need to do is use the default root CA pem file for your openssl version next to the checked SSL box where it says CA Path.&lt;/P&gt;&lt;P&gt;You can get this by doing:&lt;/P&gt;&lt;PRE&gt;&lt;SPAN class="pln"&gt;openssl  version &lt;/SPAN&gt;&lt;SPAN class="pun"&gt;-&lt;/SPAN&gt;&lt;SPAN class="pln"&gt;a&lt;/SPAN&gt;&lt;/PRE&gt;&lt;P&gt;On linux boxes the path will be &lt;STRONG&gt;/etc/pki/tls/cert.pem&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;Make sure you have an up to date version of Attunity (Qlik Replicate) where you can specify SASL/PLAIN as the Authentication type.&lt;/P&gt;&lt;P&gt;The same path is used for Schema Registry.&lt;/P&gt;&lt;P&gt;Just transferred 1.8M rows in about 1 minute, works like a champ.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Chris&lt;/P&gt;</description>
      <pubDate>Thu, 03 Sep 2020 20:27:48 GMT</pubDate>
      <guid>https://community.qlik.com/t5/Qlik-Replicate/Replicate-Kafka-target-with-publicly-trusted-TLS-SSL-certificate/m-p/1741122#M459</guid>
      <dc:creator>chrislarsen3</dc:creator>
      <dc:date>2020-09-03T20:27:48Z</dc:date>
    </item>
  </channel>
</rss>

