Member since
06-11-2018
8
Posts
0
Kudos Received
0
Solutions
07-26-2018
09:08 AM
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.
... View more
07-25-2018
02:00 PM
@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?
... View more
07-25-2018
11:27 AM
An example screenshot with additional SANs
... View more
07-25-2018
11:19 AM
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 😕
... View more
Labels:
- Labels:
-
Apache NiFi
06-12-2018
06:25 AM
@Matt Clarke Ah ok. That makes sense. I did paste the public IP in both at the time. The current config works with having the setting empty or to private IP. Thank you. Mistery solved. >_<
... View more
06-11-2018
03:18 PM
@Matt Clarke After going through logfiles, I assume I have one of the right parts with the failure: It did not produce any output with "nifi.sh run". I was just thrown out of the process and back to console. However I do not know what I did differently from all the other times. It now worked without any issue. Everything works for now. I will post updates if I am able to reproduce the issue again. I really have no clue what went different from before.
... View more
06-11-2018
02:14 PM
Hi @Matt Clarke, thank you very much for your fast response. I am not running nifi in a cluster. I am just trying to get an RPG communication to work from one local NiFi (my PC) to remote NiFi (Azure VM). Yes, the "nifi.remote.input.host" property is what I am concerned about. The rest I believe was configured correctly from the get go for HTTP-traffic. It works for PC to PC with setting it to my network IP. Running two NiFi on the same PC it works with localhost (Local PC is Windows). However, I can't get it to work with the server. Setting it to local IP has no effect. Setting it to the public IP (or *servername*.*region*.cloudapp.azure.com) will result in a crash of NiFi, shortly after startup. I assume I would need the public IP. However I am not able to reach it with telnet or ping. Neither from outside, nor the VM itself. Therefore I assume it is a problem with my Azure or Ubuntu config. It actually doesnt matter for the RPG which of the two I use on my PC. (I also installed an Apache webserver and it to is reachable). What doesn't seem to work is to get the data from the public IP to the internal one and back out again. The correct way it should work is to use the public IP for "nifi.remote.input.host", isn't it? The Input/Output ports are updated correctly on start/stop. However files are not send and I do not get an error message. (I stopped myInput deliberatly to show, that different states are visualized). Thanks, Frank
... View more
06-11-2018
12:35 PM
Hi folks, I cannot send data from my local pc to a remote process group on an azure vm (Ubuntu 18.04) and back. Both nifi instances are unsecured. I try to send with http. The local nifi-rpg sees the remote input and output ports and it is able to visualize their current states (Running, Stopped). However I am unable to send data from or to the rpg. I assume the fault lies withing the localhost property of the vm. Setting it to the public ip or domain name will result in a crash of nifi. Setting it to the internal ip does not change the behaviour of the rpg. Sadly I cannot ping the public IP address from within the VM and I do not see a way for port forwarding. Does someone know how to enable remote process groups on an azure linux vm? It seems more like an azure than a nifi issue, but the lack of messages I find online tells me that I am missing something simple. Should it usually work with setting the localhost to the public (or strangely private) ip? Should an azure vm usually be able to ping it's own public ip? Is it common for nifi to fail in startup if the localhost property is set to an unreachable ip? Greetings Frank
... View more
Labels:
- Labels:
-
Apache NiFi