Support Questions

Find answers, ask questions, and share your expertise
Celebrating as our community reaches 100,000 members! Thank you!

Secure Remote Process Group communication with static IPs


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 "": Certificate for <> doesn't match any of the subject alternative names: []

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,


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," -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 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,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 😕




This problem has been solved!

Want to get a detailed solution you have to login/registered on the community




An example screenshot with additional SANs

Super Mentor
@Frank Gaibler


You have configured your RPG to connect to a target NiFi instance/cluster via During the two-way TLS handshake the target NiFi server presents its server certificate which does not contain "" 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 "" property set in the 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 file to the static IP for each target instance/node set in your firewall.





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


@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,,....

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 "" 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

So secure communication over IP should be possible?


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.


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 "" or "" SSL works for IP.


This problem has been solved!

Want to get a detailed solution you have to login/registered on the community