@pnac03  A MutualTLS connection is established between NiFi and NiFi-Registry.  This means trust is established in both directions. You shared only the output from an openssl command connection to your NiFi-Registry. In that output we see that you NiFi-Registry reports the following: Acceptable client certificate CA names CN = 3SCDemo-CA, OU = 3SCDemo CN = nifi-registry, OU = 3SCDemo This tells us that your NiFi-Registry will only accept clientAuth certificates signed by the authorities listed in above output. Also from that same openssl command output we can see the following details of your NiFi-Registry's serverAuth certificate: Certificate chain 0 s:CN = nifi-registry, OU = 3SCDemo i:CN = 3SCDemo-CA, OU = 3SCDemo a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Sep 13 18:35:02 2025 GMT; NotAfter: Sep 13 18:35:02 2026 GMT Here we can see that your NiFi-Registry certificate has been signed/Issued by the CA "CN=3SCDemo-CA, OU=3SCDemo". What you have not shared yet is details from the other side of this mutualTLS connection. If you ran the same openssl command pointing at your NiFi node it would show us some of the TLS connection details.  You would want to look at the same NiFi's certificate chain and the NiFi's acceptable client certificate CA Names form that output.  The CA names list must include the following to be able to trust the NiFi-Registry's serverAuth certificate: CN = 3SCDemo-CA, OU = 3SCDemo Then you want to look at the NiFi's certificate chain and make sure that all root and intermediate CAs in the trust chain exist in your NiFi-Registry's truststore.   Currently your NiFi-Registry only trusts its own certificate and the one above CA.    Also keep in mind the following: If you have a NiFi cluster setup, every node in the Nifi cluster must be able to establish a mutualTLS connection with your NiFi-Registry and not just the node URL you are currently connected to for UI access. If you do not have the following setting set to "TRUE" in the nifi.properties file, any changes made to the keystore and truststore are not loaded into NiFi until a NiFi restart:  "nifi.security.autoreload.enabled".  the default setting is FALSE.  Reference: Security Configuration   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

@muahmmed  We would need to know what is being logged in the nifi-registry-app.log during startup. Thank you, Matt ... View more

@Kiranq  If your CPU load average is low relative to the number of cores you have on your Server running NiFi, you could increase the Max timer thread pool.  A typical starting point is 2 to 4 times the number of cores. Also suggest running diagnostics (./nifi.sh diagnostics) and inspecting that output. Also check if you have any processors configured with a higher concurrent tasks value. Thanks, Matt ... View more

@Rashad_K  What does NiFI provenance show for the duplicate inserts? Do you see the same NiFi FlowFile (by FlowFile UUID) being successfully inserted? Does the issue persist if your change the run duration from 25ms to 0ms? 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

@nifirequest  This appears to be a duplicate to the following community question: https://community.cloudera.com/t5/Support-Questions/How-we-ignore-hostname-verification-certificate-for-minifi/td-p/412577 Did the response in that thread not help you? Thank you, Matt ... View more

@Kiranq  How large is your Max Timer Driven Thread pool set to? I don't know how many components you have on yoru canvas or how many concurrent tasks you have set on your processors, but if the pool is very small and your CPU load average is not high, you could increase the pool size to see if that helps.  This helps if you have a lot of processors trying to share the tread pool or you have some processors with long running threads holding up threads from the pool. From the shared screenshot we can see your ExecuteSQL processor has not executed in the previous 5 minutes. Once "stuck", does the FlowFile ever get processed or is it stuck forever until some manual action is preformed by a user? Do you see any Out of Memory (OOM) or other ERROR level messages in your nifi-app.log? 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

@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