Secure Remote Process Group communication with static IPs

[#1]

Hi everyone,
I am trying to secure communication between two NiFi-instances (V1.7.1) on my local PC. (In the end from minifi to nifi on cloud)
I am using the tls-toolkit and was able to get it to work with domain names (localhost, PC-Name). However it doesn't work with IP adresses. The Remote Process Group has for example the following exception for "https://172.18.61.254:12443/nifi":

javax.net.ssl.SSLPeerUnverifiedException: Certificate for <172.18.61.254> doesn't match any of the subject alternative names: [172.18.61.254]

Additional SANs to localhost or PC-name did not help.

Is secure communication over IP impossible to do in general? Since we wanted to use RPGs to get through an industrial firewall (which works with static IPs), dependency for a DNS is not prefered.

Kind regards,
Frank

--Update--

Maybe the question isn't clear enough, so I will try to add additional information:

Since the comments are invisible by default, I will upload the screenshot again which highlights the error.

For a quick test case (on Windows):

- Download NiFi and TLS-Toolkit
- Unzip NiFi to two different folders (client, server)
- Unzip TLS-Toolkit
- Create the files:
- tls-toolkit.bat standalone -B "password1" -c myFirm -C "CN=myFirm, L=SomePlace, ST=SomePlace2, O=yeah, OU=what, C=US, EMAILADDRESS=myemail@mail.com" -d 1095 -K "password2" -n localhost,PC-Name -P "password3" -S "password4" -o ../output
- Import the pk12-file from the tls-toolkit into your browser (password is the -B parameter)
- Copy the results from localhost and "PC-Name" to your corresponding nifi-conf-folder
- Add the C-parameter to "conf/authorizers.xml" between the >< for "Initial Admin Identity" and "Initial User Identity 1
- Change the ports in nifi.properties to avoid port conflicts between server and client
- Start instances
- Access Web-UI
- Give your initial admin some rights to access the components (the key-symbol in the "Operate"-panel)
- Create user "CN=localhost, OU=NIFI" on server
- Create global access policy to receive site-to-site-details and add the new user
- Create input and output ports on server
- Click on them and add access rights for your new user (manage access policies -> receive/send data via site-to-site -> create -> add user)
- Create Remote Process Group on Client (Web-UI-address of server, change protocol to http)
- Add simple flow on client (Generate Flow File, UpdateAttribute, ..)

You now have a working secure site-to-site configuration.

Now on how to receive the errors:

- Create new files with TLS-toolkit
- tls-toolkit.bat standalone -d 1095 -K "password2" -n 127.0.0.1,externalIP -P "password3" -S "password4" --subjectAlternativeNames addSomeStuff,seperatedByComma -o ../output
- Update server and client (you might have to delete authorizations.xml and user.xml) or unzip new instances
- Create flow and configure the RPG to use the external IP
- Get errors 😕

[#2]

An example screenshot with additional SANs

[#3]

@Frank Gaibler

-

You have configured your RPG to connect to a target NiFi instance/cluster via https://172.18.61.254:12443/nifi. During the two-way TLS handshake the target NiFi server presents its server certificate which does not contain "172.118.61.254" as its CN or as a SAN entry in the certificate. So it appears as though some other server is trying to pretend to be intended destination. This cause the handshake to fail.

-

You can add that ip to the server cert as a SAN. But you also must keep in mind that this initial communication performed by the RPG is only to retrieve S2S details from the target NiFi instance. The "details' sent in the response will include the hostnames for each target NiFi instance/node as configured in "nifi.remote.input.host" property set in the nifi.properties file. When it comes to actual data transfer between source Nifi (one with RPG) and destination NiFi it will be sent to this returned hostname(s). So you may find yourself needing to set that property in the target NiFi's nifi.properties file to the static IP for each target instance/node set in your firewall.

-

Thanks,

Matt

-

If you found this Answer addressed your original question, please take a moment to login and click "Accept" below the answer.

[#4]

@Matt Clarke
Thank you for your fast response.
As a first test case, I did not try to communicate with a cluster or a node. Just two plain NiFi on my local PC.

As far as I know, I added the SAN. Please see the attached screenshot in the additional comment of my question.
For the tls-toolkit this would be done with the option:

--subjectAlternativeNames de1000-xxxx,172.18.61.254,....

The IP address is listed as an alternative name.

I assume a NiFi in the cloud will include additional steps. For example, to access a secure NiFi on cloud I had to set "nifi.web.proxy.context.path" and "nifi.web.proxy.host" to the public ip and port. However since I did not get far enough on my test setup, I couldn't test much on the cloud yet. The SAN errors (I added public IP, hostname, DNS and tried to access over public IP) where the same for now.

The certificates where done in standalone mode according to https://bryanbende.com/development/2016/08/30/apache-nifi-1.0.0-secure-site-to-site.

So secure communication over IP should be possible?

[#5]

I think you are better off continuing to use hostnames to make this work. SSL is really not designed to be used for IP addresses. In production, you would want to use a DNS name for this purpose anyhow.

[#6]

In production, devices are often gated behind firewalls. The firewalls have settings for IP addresses not domain names. At least in our security network. Adding hostname resolution would include an additional open port and address for a domain name server. Since I know the static IP of the NiFi-server, using only IPs is the prefered solution for now. According to "https://stackoverflow.com/questions/2043617/is-it-possible-to-have-ssl-certificate-for-ip-address-not-domain-name" or "https://stackoverflow.com/questions/1095780/are-ssl-certificates-bound-to-the-servers-ip-address" SSL works for IP.

[#7 · Accepted solution]

@Frank Gaibler

First to your question: In general secure communication over IP is possible.

I had a closer look to the issue you described and I have figured out that the nifi-toolkit does not seem to handle the Subject Alternative Names correctly, when you use it for creating the certificates. Right now, the toolkit does not differentiate between DNS names and IP addresses.

Normally, you need to declare each subject alternative name as IP address or DNS name like dns:de1000-xxxx,ip:172.18.61.254,.... in your example.

But, the nifi-toolkit ignores this syntax and by default everything is declared as DNS name.

You can see it in the following screenshot:

Here you should get "IP address 192.168.100.120" normally.

So from my point of view, it is just a matter of how you create the certificates in the end, because when you use openssl / Java keytool directly for certificate creation, you can create proper certificates following exactly this way.

I will follow up internally, but as a workaround you can create the certificates directly using openssl / Java keytool.

This should solve the problem.