Member since
07-03-2017
5
Posts
0
Kudos Received
1
Solution
My Accepted Solutions
Title | Views | Posted |
---|---|---|
2316 | 08-20-2018 08:52 AM |
08-20-2018
08:52 AM
@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.
... View more
08-15-2017
06:37 AM
Now, I added it, but it doesn't solve the issue. Do you know if this could be a problem with the symbolic links? Interesting thing is that even when the submission fails in SAM with this error, afterwards the storm topology is up and running. You can also view it in SAM. The error you find in streamline log, not storm log.
... View more