<?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>question Re: Secure NiFi Site to Site (S2S) on standalone NiFi instance TLS/SSL configuration in Support Questions</title>
    <link>https://community.cloudera.com/t5/Support-Questions/Secure-NiFi-Site-to-Site-S2S-on-standalone-NiFi-instance-TLS/m-p/206489#M168451</link>
    <description>&lt;P&gt;D H,&lt;/P&gt;&lt;P&gt;You bring up a good point that the EKU restriction should probably be made more evident in the docs. It makes sense -- the certificates are used in both server and client identification roles, so the roles must both be present if either is populated, but many people are unfamiliar with the EKU behavior (or unaware that the certificates serve dual purposes). I hope you are able to resolve your issue quickly. &lt;/P&gt;</description>
    <pubDate>Thu, 24 Aug 2017 02:51:15 GMT</pubDate>
    <dc:creator>alopresto</dc:creator>
    <dc:date>2017-08-24T02:51:15Z</dc:date>
    <item>
      <title>Secure NiFi Site to Site (S2S) on standalone NiFi instance TLS/SSL configuration</title>
      <link>https://community.cloudera.com/t5/Support-Questions/Secure-NiFi-Site-to-Site-S2S-on-standalone-NiFi-instance-TLS/m-p/206481#M168443</link>
      <description>&lt;P&gt;Hi Guys,&lt;/P&gt;&lt;P&gt;I’m configuring a secure single NiFi instance (v1.3.0)
to use Site to Site (S2S) to ingest reporting tasks back to itself (monitor
disk usage, memory etc.) but have hit a hurdle.  S2S works successfully in unsecure
mode but not when I apply security to it. &lt;/P&gt;&lt;P&gt;My environment&lt;/P&gt;&lt;UL&gt;
&lt;LI&gt;NiFi 1.3.0 secured (LDAP authentication provider) and issue free&lt;/LI&gt;&lt;LI&gt;NiFi S2S working perfectly in unsecured mode and
ingesting reporting task messages as flow files&lt;/LI&gt;&lt;LI&gt;My secure S2S configuration uses a  SiteToSiteBullitenReportingTask in RAW mode with
a StandardSSLServiceContext (same issue using HTTPS transport protocol)&lt;/LI&gt;&lt;LI&gt;The StandardSSLServiceContext is using the exact
same keystore and truststore that were used in successfully securing the NiFi UI&lt;/LI&gt;&lt;LI&gt;Java details: java version "1.8.0_91",
Java(TM) SE Runtime Environment (build 1.8.0_91-tdc1-b14), Java HotSpot(TM)
64-Bit Server VM (build 25.91-b14, mixed mode)&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;In the StandardSSLServiceContext you have the ability to
specify the TLS version to use when making the connection.  I’ve tried all of the settings but toggle
between a broken pipe SocketException or a handshake_failure depending on the
choice.  I’ve lowered the log level to
DEBUG and can see the attempted handshake but my connection is always
terminated by the server.  Interestingly,
even with a working secure NiFi instance I’ve never been able to use the
openssl –sclient tool on the same server to successfully test the connection
but have never had a problem when accessing NiFi via the web UI.  Would the intelligent Hortonworks community have
any suggestions that might be able to assist my troubleshooting this issue?  &lt;/P&gt;&lt;P&gt;&lt;A href="https://community.cloudera.com/legacyfs/online/attachments/23487-s2s-stacktrace.txt"&gt;s2s-stacktrace.txt&lt;/A&gt;&lt;/P&gt;</description>
      <pubDate>Mon, 07 Aug 2017 13:27:12 GMT</pubDate>
      <guid>https://community.cloudera.com/t5/Support-Questions/Secure-NiFi-Site-to-Site-S2S-on-standalone-NiFi-instance-TLS/m-p/206481#M168443</guid>
      <dc:creator>dwanehall</dc:creator>
      <dc:date>2017-08-07T13:27:12Z</dc:date>
    </item>
    <item>
      <title>Re: Secure NiFi Site to Site (S2S) on standalone NiFi instance TLS/SSL configuration</title>
      <link>https://community.cloudera.com/t5/Support-Questions/Secure-NiFi-Site-to-Site-S2S-on-standalone-NiFi-instance-TLS/m-p/206482#M168444</link>
      <description>&lt;P&gt;Is there an error that is shown on the Remote Process Group? If so can you provide that error and possibly the stacktrace that goes with it from nifi-app.log?&lt;/P&gt;</description>
      <pubDate>Mon, 07 Aug 2017 20:43:27 GMT</pubDate>
      <guid>https://community.cloudera.com/t5/Support-Questions/Secure-NiFi-Site-to-Site-S2S-on-standalone-NiFi-instance-TLS/m-p/206482#M168444</guid>
      <dc:creator>bbende</dc:creator>
      <dc:date>2017-08-07T20:43:27Z</dc:date>
    </item>
    <item>
      <title>Re: Secure NiFi Site to Site (S2S) on standalone NiFi instance TLS/SSL configuration</title>
      <link>https://community.cloudera.com/t5/Support-Questions/Secure-NiFi-Site-to-Site-S2S-on-standalone-NiFi-instance-TLS/m-p/206483#M168445</link>
      <description>&lt;P&gt;Thanks for the quick reply Bryan. The errors are thrown by the SiteToSiteBulletinReportingTask Reporting Task when trying to use its configured SSL Context Service (StandardSSLContextService) Controller Service to define an input monitor port.  The configuration is the same as Pierre Villard's monitoring disk space example here (https://pierrevillard.com/2017/05/13/monitoring-nifi-site2site-reporting-tasks/) except I am using a single NiFi instance to both report and receive the monitor.  (Stack trace attached)&lt;/P&gt;</description>
      <pubDate>Tue, 08 Aug 2017 05:55:58 GMT</pubDate>
      <guid>https://community.cloudera.com/t5/Support-Questions/Secure-NiFi-Site-to-Site-S2S-on-standalone-NiFi-instance-TLS/m-p/206483#M168445</guid>
      <dc:creator>dwanehall</dc:creator>
      <dc:date>2017-08-08T05:55:58Z</dc:date>
    </item>
    <item>
      <title>Re: Secure NiFi Site to Site (S2S) on standalone NiFi instance TLS/SSL configuration</title>
      <link>https://community.cloudera.com/t5/Support-Questions/Secure-NiFi-Site-to-Site-S2S-on-standalone-NiFi-instance-TLS/m-p/206484#M168446</link>
      <description>&lt;P&gt;
	What issue do you get when using  
	&lt;CODE&gt;openssl s_client&lt;/CODE&gt;  ? You should definitely be able to connect using s_client, although you may need to provide &lt;CODE&gt;-CAfile&lt;/CODE&gt; option to trust the issued server certificate and &lt;CODE&gt;-cert&lt;/CODE&gt; and &lt;CODE&gt;-key&lt;/CODE&gt; options to provide a client certificate as below:
&lt;/P&gt;
&lt;P&gt;
	&lt;CODE&gt;openssl s_client -connect nifi.nifi.apache.org:9443 -debug -state -CAfile conf/nifi-cert.pem -cert conf/client.pem -key conf/client.key&lt;/CODE&gt;
&lt;/P&gt;
&lt;P&gt;
	As for the handshake_failure issue, this may be because:
&lt;/P&gt;
&lt;OL&gt;
	&lt;LI&gt;The certificate has expired or is invalid&lt;/LI&gt;
	&lt;LI&gt;The provided keystore or key password is incorrect and the controller service cannot access the keystore&lt;/LI&gt;
	&lt;LI&gt;The server and client cannot agree on a suitable cipher suite during negotiation&lt;/LI&gt;
&lt;/OL&gt;
&lt;P&gt;
	Diagnosing with s_client is definitely the correct tool. You can also enable TLS debugging via the &lt;CODE&gt;bootstrap.conf&lt;/CODE&gt; file with the line:
&lt;/P&gt;
&lt;P&gt;
	&lt;CODE&gt;java.arg.15=-Djavax.net.debug=ssl,handshake&lt;/CODE&gt;
&lt;/P&gt;
&lt;P&gt;
	This output will be in &lt;CODE&gt;logs/nifi-bootstrap.log&lt;/CODE&gt;.
&lt;/P&gt;</description>
      <pubDate>Tue, 08 Aug 2017 07:19:26 GMT</pubDate>
      <guid>https://community.cloudera.com/t5/Support-Questions/Secure-NiFi-Site-to-Site-S2S-on-standalone-NiFi-instance-TLS/m-p/206484#M168446</guid>
      <dc:creator>alopresto</dc:creator>
      <dc:date>2017-08-08T07:19:26Z</dc:date>
    </item>
    <item>
      <title>Re: Secure NiFi Site to Site (S2S) on standalone NiFi instance TLS/SSL configuration</title>
      <link>https://community.cloudera.com/t5/Support-Questions/Secure-NiFi-Site-to-Site-S2S-on-standalone-NiFi-instance-TLS/m-p/206485#M168447</link>
      <description>&lt;P&gt;Thanks for the logging tip Andy this has been very useful.  I had previously tried the openssl s_client command you mention above with the same, cert, key, and CA and connected without issue to another service on the server (knox) so I was confident of valid credentials. The bootstrap log is now showing a &lt;STRONG&gt;SSL_NULL_WITH_NULL_NULL&lt;/STRONG&gt; and &lt;EM&gt;NiFi Web Server-228, fatal error: 40: no cipher suites in common&lt;/EM&gt; which I was unable to see before.  I'll explore further tomorrow and get back with a confirmation.  Thanks again I appreciate the assistance.&lt;/P&gt;</description>
      <pubDate>Tue, 08 Aug 2017 14:26:31 GMT</pubDate>
      <guid>https://community.cloudera.com/t5/Support-Questions/Secure-NiFi-Site-to-Site-S2S-on-standalone-NiFi-instance-TLS/m-p/206485#M168447</guid>
      <dc:creator>dwanehall</dc:creator>
      <dc:date>2017-08-08T14:26:31Z</dc:date>
    </item>
    <item>
      <title>Re: Secure NiFi Site to Site (S2S) on standalone NiFi instance TLS/SSL configuration</title>
      <link>https://community.cloudera.com/t5/Support-Questions/Secure-NiFi-Site-to-Site-S2S-on-standalone-NiFi-instance-TLS/m-p/206486#M168448</link>
      <description>&lt;P&gt;Hi Andy, unfortunately I'm still having TLS cipher connection compatibility problems. NiFi always appears to present a ClientHello TLSv1.2 message irrespective of my selection on the StandardSSLContextService (v1.3.0) SSL Protocol. I assume the ClientHello is launched by NiFi using a java SSL connection and has no dependency on my underlying openssl version (OpenSSL 0.9.8j-fips)?&lt;/P&gt;</description>
      <pubDate>Fri, 11 Aug 2017 06:56:46 GMT</pubDate>
      <guid>https://community.cloudera.com/t5/Support-Questions/Secure-NiFi-Site-to-Site-S2S-on-standalone-NiFi-instance-TLS/m-p/206486#M168448</guid>
      <dc:creator>dwanehall</dc:creator>
      <dc:date>2017-08-11T06:56:46Z</dc:date>
    </item>
    <item>
      <title>Re: Secure NiFi Site to Site (S2S) on standalone NiFi instance TLS/SSL configuration</title>
      <link>https://community.cloudera.com/t5/Support-Questions/Secure-NiFi-Site-to-Site-S2S-on-standalone-NiFi-instance-TLS/m-p/206487#M168449</link>
      <description>&lt;P&gt;Hi DH. &lt;/P&gt;&lt;P&gt;As of Apache NiFi 1.2.0, only TLSv1.2 is supported for incoming connections [&lt;A target="_blank" href="https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.2.0"&gt;Release Notes&lt;/A&gt; - Security]. This is independent of the version of OpenSSL installed, and unrelated to the selection of TLS/SSL protocol in StandardSSLContextService (see discussion on &lt;A target="_blank" href="https://github.com/apache/nifi/pull/1986#issuecomment-317590710"&gt;PR 1986&lt;/A&gt; about removing invalid protocol version options from the dropdown because they are not supported). However, because your client should be the same instance as your server (the SiteToSite reporting task is pointing back to itself, correct?) the same protocol versions and cipher suites should be available to both roles. Can you do a remote debugging session and trace the outgoing connection to determine what protocol versions and cipher suites are available to the SSLContext object at that time?&lt;/P&gt;</description>
      <pubDate>Sat, 12 Aug 2017 01:54:59 GMT</pubDate>
      <guid>https://community.cloudera.com/t5/Support-Questions/Secure-NiFi-Site-to-Site-S2S-on-standalone-NiFi-instance-TLS/m-p/206487#M168449</guid>
      <dc:creator>alopresto</dc:creator>
      <dc:date>2017-08-12T01:54:59Z</dc:date>
    </item>
    <item>
      <title>Re: Secure NiFi Site to Site (S2S) on standalone NiFi instance TLS/SSL configuration</title>
      <link>https://community.cloudera.com/t5/Support-Questions/Secure-NiFi-Site-to-Site-S2S-on-standalone-NiFi-instance-TLS/m-p/206488#M168450</link>
      <description>&lt;P&gt;Thanks for the info Andy this is good to know.  I'm very close to getting there and now have a successful handshake taking place between NiFi and itself thanks to your useful advice (I've learnt more about SSL debugging in the process than I'd care to admit!).  The problem has been the strict format required for the NiFi certs which were issued to us by our CA team and not generated using the NiFi toolkit.  This has been complicated by not having a recent version of openssl capable of debugging the TLS1.2 version the Jetty server requires.  For interest and other users out there make sure your certs have an EKU of both clientAuth and serverAuth specified (if your EKU is critical) and your KU has DigitalSignature specified.  I've now hit the same problem as you've assisted with here so I'll try to work through your suggestions (http://apache-nifi.1125220.n5.nabble.com/NiFi-1-1-1-Secure-Cluster-Setup-Issue-HTTPS-Wrong-Hostname-wrong-should-be-lt-my-ip-address-gt-td15361.html). Thanks again.&lt;/P&gt;</description>
      <pubDate>Wed, 23 Aug 2017 09:19:55 GMT</pubDate>
      <guid>https://community.cloudera.com/t5/Support-Questions/Secure-NiFi-Site-to-Site-S2S-on-standalone-NiFi-instance-TLS/m-p/206488#M168450</guid>
      <dc:creator>dwanehall</dc:creator>
      <dc:date>2017-08-23T09:19:55Z</dc:date>
    </item>
    <item>
      <title>Re: Secure NiFi Site to Site (S2S) on standalone NiFi instance TLS/SSL configuration</title>
      <link>https://community.cloudera.com/t5/Support-Questions/Secure-NiFi-Site-to-Site-S2S-on-standalone-NiFi-instance-TLS/m-p/206489#M168451</link>
      <description>&lt;P&gt;D H,&lt;/P&gt;&lt;P&gt;You bring up a good point that the EKU restriction should probably be made more evident in the docs. It makes sense -- the certificates are used in both server and client identification roles, so the roles must both be present if either is populated, but many people are unfamiliar with the EKU behavior (or unaware that the certificates serve dual purposes). I hope you are able to resolve your issue quickly. &lt;/P&gt;</description>
      <pubDate>Thu, 24 Aug 2017 02:51:15 GMT</pubDate>
      <guid>https://community.cloudera.com/t5/Support-Questions/Secure-NiFi-Site-to-Site-S2S-on-standalone-NiFi-instance-TLS/m-p/206489#M168451</guid>
      <dc:creator>alopresto</dc:creator>
      <dc:date>2017-08-24T02:51:15Z</dc:date>
    </item>
  </channel>
</rss>

