How we ignore hostname verification certificate for minifi iot device in invokehttp in NIFI

[#1]

Hello Team,

Currently we use NiFi’s InvokeHTTP to send files to a MiNiFi IoT device. The MiNiFi listenhttp is configured in the YAML and we are calling the device with:

http + ip (device)+port

Security requires we move this to HTTPS. On the NiFi side we configured SSLServiceContext and added a truststore. On the MiNiFi device we configured listenhttp in its YAML and provided a keystore and truststore (certificates are not machine-signed). After switching to HTTPS we see a hostname verification error 

Question: is there a supported option in Cloudera / NiFi’s InvokeHTTP to use only a truststore and skip hostname verification? Alternatively, is there a recommended way to bypass or relax hostname verification on the MiNiFi side so the call succeeds?

Thanks

[#2]

@nifirequest 

Welcome to the community!

The Apache NiFi community decided to remove the trusted hostname property from InvokeHTTP back in the 1.10 release.  By having this property the processor allowed for an insecure connection because user could simply add the unverified hostname in this property and the InvokeHTTP processor would then allow the connection to be successful.  Thus allowing user to perhaps unknowingly be exposing themselves to unsecure connections.

This option was removed in https://issues.apache.org/jira/browse/NIFI-6019

The purpose of hostname verification is to prevent man in the middle style attacks where client expects to connect to host ABC; however, the server that responded was not known as server ABC.   All the possible hostnames a server is known as need to be included as SubjectAlternativeName (SAN) entries in the server certificate.  

The ERROR you received in your InvokeHTTP about "Hostname ABC not verified" should have also included the list of SubjectAltNames that came from the server's certificate.  You should be using one of those SAN entries in the URL you have configured in the InvokeHTTP processor or you  should address the certificate being used by the listenHTTP to include the additional SAN (IPs or hostnames) also used to access the MiNiFi listener.

For one-way TLS connection the server side (ListenHTTP) must have a keystore and truststore.  The client side (InvokeHTTP) must have a truststore configured.
For MutualTLS both the server side and client side need to have both a keystore and truststore.   
You can't create a secured TLS enabled server without a serverAuth certificate.
Hostname verification happens on the client side and not the server side.

Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped.

Thank you,
Matt

[#3]

@nifirequest Has the reply helped resolve your issue? If so, please mark the appropriate reply as the solution, as it will make it easier for others to find the answer in the future.  Thanks.