Hi Jeff,

Yes, NiFI 1.2.0+ uses (only) TLS v1.2 for any incoming connections. There is 
backward compatible capability to use TLS v1 and v1.1 for outgoing connections 
to legacy services.

From the Migration Notes [1]:

(1.2.0)
Jetty has been upgraded to version 9.4.2.  As a result, TLSv1/1.1 is no longer 
supported.  Users or clients connecting to NiFi through the UI or API now 
protected with TLS v1.2.  Any custom code that consumes the NiFi API needs to 
use TLS v1.2 or later.

(1.4.0)
A restricted implementation of the SSLContextService has been added, 
StandardRestrictedSSLContextService. It provides the ability to configure 
keystore and/or truststore properties once and reuse that configuration 
throughout the application, but only allows a restricted ("modern") set of 
TLS/SSL protocols to be chosen (as of 1.4.0, no SSL protocols are supported, 
only TLS v1.2). The set of protocols selectable will evolve over time as new 
protocols emerge and older protocols are deprecated. The generic "TLS" entry is 
also supported and will automatically select the best available option without 
user intervention (this is the recommended setting). This service is 
recommended over StandardSSLContextService if a component doesn't expect to 
communicate with legacy systems since it is unlikely that legacy systems will 
support these protocols.

The following Listen* processors now require a 
StandardRestrictedSSLContextService (previously requiring 
StandardSSLContextService): ListenBeats, ListenHTTP, ListenLumberjack, 
ListenRELP, ListenSMTP, ListenSyslog, ListenTCP, ListenTCPRecord
ListenGRPC is a new processor for 1.4.0, and requires 
StandardRestrictedSSLContextService
Dataflow managers will need to instantiate a new instance of 
StandardRestrictedSSLContextService and associate it with any of the above 
components in an existing flow

(1.7.1)
Hostname validation has become more strict in 1.7.1. In previous versions, NiFi 
supported certificates which did not contain a Subject Alternative Name (SAN) 
field matching the node hostname. In following with RFC 6125, all certificates 
should include an entry in the SAN array which matches the node hostname for 
hostname verification.

For clarification, all Apache NiFi versions have only 3 numbers (0.7.4, 1.7.1, 
etc.). A version with additional numbers following that version is likely 
provided by a specific vendor and questions about compatibility and features 
should be directed to that vendor.

[1] https://cwiki.apache.org/confluence/display/NIFI/Migration+Guidance 
<https://cwiki.apache.org/confluence/display/NIFI/Migration+Guidance>

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

> On Sep 24, 2018, at 4:31 AM, Tadiosa, Jeffrey O. 
> <[email protected]> wrote:
> 
> Hi Nifi Dev Team - I am Jeff from Accenture. We are using NiFi in one of our 
> project. is NiFi Version 1.5.0.3.1.0.0-564 compatible with TLS 1.2? Are there 
> anything that we should modify when we shift to TLS 1.2?
> 
> Best Regards,
> Jeffrey Tadiosa ITIL V3
> GDN for Technology in the Philippines | CAP Operations - Data Lake
> 17/F Global One Bldg, Eastwood City Cyberark, Brgy Bagumbayan, Quezon City, 
> Metro Manila, Philippines 1110
> Service Now Queue: CAP-OPERATIONS-DATALAKE;
> CAP Ops Data Lake Line: +1 5714345000  or +1 6126432466
> CAP Ops Data Lake Email: 
> [email protected]<mailto:[email protected]>
> CAP Ops Data Lake Skype ID: A04985DIRCAPOps
> 
> 
> ________________________________
> 
> This message is for the designated recipient only and may contain privileged, 
> proprietary, or otherwise confidential information. If you have received it 
> in error, please notify the sender immediately and delete the original. Any 
> other use of the e-mail by you is prohibited. Where allowed by local law, 
> electronic communications with Accenture and its affiliates, including e-mail 
> and instant messaging (including content), may be scanned by our systems for 
> the purposes of information security and assessment of internal compliance 
> with Accenture policy. Your privacy is important to us. Accenture uses your 
> personal data only in compliance with data protection laws. For further 
> information on how Accenture processes your personal data, please see our 
> privacy statement at https://www.accenture.com/us-en/privacy-policy.
> ______________________________________________________________________________________
> 
> www.accenture.com

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

Reply via email to