@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 ... View more