I’d like to clarify some of the details here to ensure that Brajendra and other 
community users who find this have the correct information.

The decision of which SSL/TLS protocol version (SSLv3, TLSv1, TLSv1.1, TLSv1.2) 
to use is made in conjunction by the server and the client (in this case NiFi 
and the user’s browser). TLS public certificates (the data presented by the 
server during TLS handshake negotiation) wrap a public RSA or DSA key, and do 
not have an inherent TLS protocol version associated with them [1].

In general, a server can support many different protocol versions at once, and 
during the ClientHello portion of the negotiation, the client sends the maximum 
protocol version it can support, and a list of cipher suites it can support, in 
order of preference [2]. The server then selects one of its protocols that 
meets the client requirements, as well as a cipher suite that does the same. If 
there is no overlap between these two lists, the client will receive a “no 
cipher suites in common” error message and the handshake will fail.

Once the client and server agree on a protocol version and cipher suite, more 
information is exchanged, such as the client certificate (if requested), 
Diffie-Hellman key exchange, etc.

In NiFi’s specific case, NiFi versions 1.2.0 and later only support TLSv1.2 for 
incoming HTTPS connections [3]. This means that the UI and API are always 
protected with TLSv1.2 if HTTPS is enabled. NiFi can still perform outgoing 
requests to legacy servers using older protocol versions if necessary. SSLv3 
protocol is not used to serve NiFi resources at all.

You’ll need to provide further stacktraces from NiFi in order for anyone to 
diagnose what issues you are encountering. You can enable Java SSL debugging by 
adding the following line to bootstrap.conf and restarting:

> java.arg.15=-Djavax.net.debug=ssl,handshake


[1] https://www.globalsign.com/en/blog/ssl-vs-tls-difference/ 
<https://www.globalsign.com/en/blog/ssl-vs-tls-difference/>
[2] https://security.stackexchange.com/a/20847/16485 
<https://security.stackexchange.com/a/20847/16485>
[3] 
https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.2.0
 
<https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.2.0>

Andy LoPresto
[email protected]
[email protected]
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

> On May 23, 2018, at 5:17 AM, Milan Das <[email protected]> wrote:
> 
> I use the following script the generate certificate
> 
> openssl req -new -keyout out/$I.key -out out/$I.request -days 365 -nodes 
> -subj "/C=US/ST=California/L=Irvine/O=example com/CN=${I}" -newkey rsa:2048
> 
> My complete script I use (you can refer but I can not support the script for 
> your need)
> https://github.com/dmilan77/scripts/blob/master/ssl/createSSLCert.sh
> 
> 
> You can verify using nmap or oepnssl
> 
> openssl s_client -connect hostname:443 -tls1_2
> 
> nmap --script ssl-enum-ciphers -p 443 hostname
> 
> 
> 
> Regards,
> Milan Das
> 
> 
> On 5/23/18, 8:03 AM, "Brajendra Mishra" <[email protected]> 
> wrote:
> 
>    I am using openssl for creating SSL certificate but I am unable to figure 
> out which option(s) is required to make TLS supported certificate.
>    Could you please help me out on this. I am not aware much about these 
> certificates and all?
> 
>    Brajendra Mishra
>    Persistent Systems Ltd.
> 
>    -----Original Message-----
>    From: Milan Das <[email protected]>
>    Sent: Wednesday, May 23, 2018 5:21 PM
>    To: [email protected]; [email protected]
>    Subject: Re: How to run NiFi on HTTPS
> 
>    Hi Bajendra,
>    TLS vs SSL is all depends on how you generate the SSL certificates.
>    If the SSL certificate is TLS 1.2 then JVM SSL protocol will use TLS.
> 
>    Regards,
>    Milan
>    Sr. Architect-- Interset Inc
> 
>    On 5/23/18, 7:40 AM, "Brajendra Mishra" <[email protected]> 
> wrote:
> 
>        Hi Andy,
> 
>        Thanks a lot for you valuable inputs. I could found the actual 
> resolution after debugging the issue.
>        Earlier I was using IBM java 8 instead of Oracle Java 8/open JDK 8, 
> where SSLv3 Protocol is not enabled by default, hence I was facing this issue.
> 
>        Now I am able to see the NiFi UI securely but please let me know the 
> way where I can run this nifi on TLS 1.0, 1.2 protocol instead of SSLv3 so I 
> can use IBM Java 8 as well?
> 
>        Brajendra Mishra
>        Persistent Systems Ltd.
> 
>        From: Andy LoPresto <[email protected]>
>        Sent: Wednesday, May 23, 2018 4:16 AM
>        To: [email protected]
>        Subject: Re: How to run NiFi on HTTPS
> 
>        Apache NiFi does not support Basic Authentication in any scenario. 
> There are multiple options for user authentication to the NiFi UI/API, 
> including LDAP, Kerberos, client certificates, Apache Knox, and OpenID 
> Connect. More details about configuring these options are available in the 
> Admin Guide [1].
> 
>        As for your TLS error, my guess is that there is an error with the 
> certificate you generated. The error “No overlapping cipher suites available” 
> can occur when the certificate is expired or otherwise invalid, and all the 
> available cipher suites require an RSA key for signing or encryption. To 
> further debug this, you can use the OpenSSL s_client tool to attempt to make 
> a connection via the command line, and enable the JSSE SSL debugging via a 
> modification to bootstrap.conf. Once you restart, you should see additional 
> TLS/SSL debug output in logs/nifi-bootstrap.conf.
> 
>        For us to be able to offer further advice, you’ll need to provide more 
> information, like stacktraces from your logs, or the openssl output from 
> examining the certificates. Images do not come through on the list, so please 
> copy and paste text output instead. There are other possible explanations, 
> such as OS-limited cipher suites available, older browser versions, etc. but 
> these are much less common.
> 
>        Add this line to bootstrap.conf:
> 
>        java.arg.15=-Djavax.net.debug=ssl,handshake
> 
>        [1] 
> https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#user_authentication
> 
> 
>        Andy LoPresto
>        [email protected]<mailto:[email protected]>
>        [email protected]<mailto:[email protected]>
>        PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> 
>        On May 22, 2018, at 5:53 AM, Brajendra Mishra 
> <[email protected]<mailto:[email protected]>> 
> wrote:
> 
>        Team I need to know the implementation of basic authentication with 
> HTTPS as well.
> 
>        Brajendra Mishra
>        Persistent Systems Ltd.
> 
>        From: Brajendra Mishra 
> <[email protected]<mailto:[email protected]>>
>        Sent: Tuesday, May 22, 2018 6:22 PM
>        To: [email protected]<mailto:[email protected]>
>        Subject: How to run NiFi on HTTPS
> 
>        Hi Team,
> 
>        I have used tlstoolkit to create required files (nifi.properties, 
> keystore and truststore files) to run NiFi on HTTPS.
>        I also configured successfully and ran the NiFi service correctly 
> which show it is running on Https protocol.
>        But once I tried to see its UI I am facing following error on all 
> browsers (IE, Firefox and Chrome):
> 
>        "Secure Connection Failed - An error occurred during a connection to 
> localhost:9090. Cannot communicate securely with peer: no common encryption 
> algorithm(s). Error code: SSL_ERROR_NO_CYPHER_OVERLAP"
> 
>        [cid:[email protected]]
> 
>        Could you please let me know how can I see NiFi UI in this case? I 
> have already tried all possible options (spread on internet) to get rid this 
> issue on browsers but no luc
> 
> 
>        Brajendra Mishra
>        Persistent Systems Ltd.
> 
>        DISCLAIMER
>        ==========
>        This e-mail may contain privileged and confidential information which 
> is the property of Persistent Systems Ltd. It is intended only for the use of 
> the individual or entity to which it is addressed. If you are not the 
> intended recipient, you are not authorized to read, retain, copy, print, 
> distribute or use this message. If you have received this communication in 
> error, please notify the sender and delete all copies of this message. 
> Persistent Systems Ltd. does not accept any liability for virus infected 
> mails.
> 
> 
> 
> 
> 
> 
> 

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to