Minifi C++ 0.4.0 secure communication

[#1]

Has anyone got Minifi C++ v0 4 0 working over a secure connection to a Nifi cluster. My certs seem to be fine as I can log into UI of the secured cluster through the browser using a cert I created for a nifiadmin user. I've got minifi (collecting Squid logs) working unsecured but every time I try to get it connecting securely it won't authenticate to be able to retreive s2s settings. The logs are:

[2018-03-10 19:13:58.149] [org::apache::nifi::minifi::controllers::SSLContextService] [info] not good [2018-03-10 19:13:58.149] [org::apache::nifi::minifi::controllers::SSLContextService] [warning] still not good [2018-03-10 19:13:58.230] [org::apache::nifi::minifi::core::ProcessSession] [info] Transferring 2ef87a2c-2497-11e8-81ff-be2999981f84 from Get_access.log to relationship success [2018-03-10 19:13:58.230] [org::apache::nifi::minifi::processors::TailFile] [info] TailFile access.log for 2481982 bytes [2018-03-10 19:13:58.230] [org::apache::nifi::minifi::processors::UpdateAttribute] [info] Set attribute 'Store State' of flow file '2ef87a2c-2497-11e8-81ff-be2999981f84' with value 'Do not store state' [2018-03-10 19:13:58.230] [org::apache::nifi::minifi::processors::UpdateAttribute] [info] Set attribute 'host_name' of flow file '2ef87a2c-2497-11e8-81ff-be2999981f84' with value 'gs1' [2018-03-10 19:13:58.230] [org::apache::nifi::minifi::processors::UpdateAttribute] [info] Set attribute 'tenant' of flow file '2ef87a2c-2497-11e8-81ff-be2999981f84' with value ''TheBerties'' [2018-03-10 19:13:58.230] [org::apache::nifi::minifi::core::ProcessSession] [info] Transferring 2ef87a2c-2497-11e8-81ff-be2999981f84 from UpdateAttribute to relationship success [2018-03-10 19:13:58.426] [org::apache::nifi::minifi::utils::HTTPClient] [error] curl_easy_perform() failed Peer certificate cannot be authenticated with given CA certificates [2018-03-10 19:13:58.426] [org::apache::nifi::minifi::RemoteProcessorGroupPort] [error] ProcessGroup::refreshRemoteSite2SiteInfo -- curl_easy_perform() failed [2018-03-10 19:13:58.426] [org::apache::nifi::minifi::c2::C2Agent] [info] Class is RESTSender [2018-03-10 19:13:58.428] [org::apache::nifi::minifi::io::Socket] [error] Could not bind to socket [2018-03-10 19:13:58.429] [org::apache::nifi::minifi::FlowController] [info] Started Flow Controller [2018-03-10 19:13:58.429] [main] [info] MiNiFi started [2018-03-10 19:13:58.444] [org::apache::nifi::minifi::utils::HTTPClient] [error] curl_easy_perform() failed Peer certificate cannot be authenticated with given CA certificates [2018-03-10 19:13:58.444] [org::apache::nifi::minifi::RemoteProcessorGroupPort] [error] ProcessGroup::refreshRemoteSite2SiteInfo -- curl_easy_perform() failed [2018-03-10 19:13:58.444] [org::apache::nifi::minifi::RemoteProcessorGroupPort] [info] no protocol, yielding

I can't find much in the way of documentation for secure minifi cpp operations. I'm using the Centos 7 version on Hortonworks repository. Has anyone been successful and are you able to suggest what I'm doing wrong. I haven't reverted back to compiling from github yet but guess that is the next on the list.

Many thanks in advance.

Tom

[#2]

@Tom Burton I pulled up a clean Centos 7 VM with security profiles enabled and ran into the same issues. I noticed that the system's curl is not built with OpenSSL and instead is using NSS, which we are not using.

Did you use the bootstrap? I will begin checking all distros to ensure that we perform the download and install of libcurl-openssl when the default impl does not contain OpenSSL. Thanks for helping identify this.

[#3]

Thanks for putting the effort in @mparisi. Yes, I used bootstrap and followed the prices from GitHub. But I left my build VM with a standard security profile rather than the heavier NIST 800-171 one.

[#4]

I've been doing some further investigation @mparisi and I think your observation about the curl version may be at the root. I've tried running it on a vanila Centos 7 VM with no security profile and still have the same problem. I've also tried establishing a session with curl from the command line, and it consistently throws the same error:

# curl -k --cacert ./conf/nifi-cert.pem --cert ./conf/gs1_cert.pem --key ./conf/gs1_enckey.pem --pass ./conf/password https://nifi1.dev.cyhesion.com:9091/nifi
curl: (58) unable to load client key: -8025 (SEC_ERROR_UNKNOWN_PKCS11_ERROR)

I've tried single key/cert files and distinct ones. I've also converted the key into an RSA format one because there were some reports that keys that started "-----BEGIN ENCRYPTED PRIVATE KEY-----" sometimes case problems.

It seems to be a difficulty with curl handling encrypted keys that have been created with OpenSSL. Curl doesn't return an error when I give it unencrypted certificates and keys. Minifi still doesn't work with unencrypted keys but I assume it didn't expect to be used in that way. I've played around with encryption algorithms as well, including ensuring the key is encrypted with triple-DES as suggested in stack-overflow but without success.

As you pointed out curl on Centos 7 is bound to NSS rather than OpenSSL. Do you have any views on how this could be resolved?

[#5]

@Tom Burton I will modify the bootstrap to identify this and install libcurl-openssl from source and investigate using NSS when OpenSSL isn't present. The former is an easy setup change, the latter will exist and be used when that setup change isn't possible. I will have a resolution for both soon.

[#6]

Thanks @mparisi, much appreciated and I look forward to the updated bootstrap. Apologies for what is probably a stupid question, but if minifi is built under this bootstrap with libcurl-openssl will this work regardless of the version of curl that is installed on the system that it is running on?

[#7]

@Tom Burton We won't make assumptions. We'll maintain backwards compatibility, so we'll detect if libcurl w/ openssl is installed on the build system. If that is not desired and you do not with for us to manually install libcurl w/ openssl support we'll rely on other methods for security and then you can distribute that binary amongst your systems. In short we will need to adjust our build process to account for systems where libcurl is built without openssl support. I think that's a reasonable ask from us and something we should be able to quickly do.

[#8]

@Tom Burton I've submitted https://github.com/apache/nifi-minifi-cpp/pull/285

That PR will detect if OpenSSL support does not exist for libcurl and if it does not will use NSS. I've tested this on Centos 7.

[#9]

That works for me @mparisi. Let me know if there is anything I can do to test it. Many thanks, Tom

[#10]

Hello @mparisi. I can't seem to reply to your last message so have started a fresh thread. Thank you for creating Pull 285 for this. I've built from it, and apart from having to manually create the conf directory with its contents the built seemed to compete successfully. It identified that libcurl-nss was isn't rather than openssl, and built to work with that. However, I'm still failing to authenticate. Clearly I'm doing something stupid now. Should I be changing the config in minifi.properties, config.yml or doing anything else differently to make it work with nss. I'll go through everything again to make sure I haven't missed anything out but would welcome an guidance you can provide. Thanks for all your help, Tom

[#11]

@Tom Burton What error are you seeing in the log files? Can you pass along the minifi-log file? That will help me debug.

Try disabling host verification as I suspect that could be the issue, but cannot verify without the log file.

nifi.security.client.disable.host.verification=true

Feel free to join https://apache.hipchat.com/chat if you would like to chat.