@pnac03  Looks like you truncated the output of the keytool command for your keystore. What are the "ExtendedKeyUsages" (EKU) on your PrivateKeyEntry? It must have:   ExtendedKeyUsages [ serverAuth clientAuth ]   If it is missing "clientAuth", it can't be used in NiFi by the NiFRegistryFlowRegistryClient because it won't present a client certificate in the mutualTLS exchange.  But even above if no clientAuth EKU would not explain the exception you get: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target This exception is caused by a trust issue.  The copied over keystore and truststore are owned by the NiFi service user and the NiFi service user can traverse the directory path the the keystore and truststore?  The URL used in the NiFiRegistryFlowRegistryClient is using https and not http? Thanks, Matt ... View more

@Kiranq  Nothing stands out to me as problematic in the diagnostics output that relates to the stick FlowFile.  The verbose output indicates just 1 queued FlowFile on the canvas The Diagnostics output then tells us that this one FlowFile is queued in the connection with ID:  d8e8fe6e-38a5-3fee-8933-2e8c6bf55afa The UUID of the queued FlowFile is: ce9cbd21-455b-4191-80bc-6598609b71a1 Details of this One FlowFile:   If you clear out the FlowFile, does the very next FlowFile that enters this Process group get stuck?  Do FlowFiles only get stuck in front of this one specific processor and everywhere else FlowFiles are being processed fine? How is this specific process group configured? Can you list the connection and verify the content of this FlowFile looks correct? Have you tried adjusting NiFi's logging to DEBUG to see if any useful Debug output is produced for the issue? Thanks, Matt ... View more

@Bern  From what has been shared I can't tell you much more then the fact that you are having zookeeper issues.  Without a ZK quorum, NiFi can't maintain the cluster and thus the UI is not available.  There is not much else I can tell you from what you have shared.  I suggest looking more closely at the NiFi app.log and bootstrap logs for other ERRORs or WARNs that may have been logged before or at same time your ZK communication issue started.  You may also want to look at the health of your network. You mention that NiFi goes down nightly and that this started when you were building some "contingency processes".  I am not clear on what this means relative to your NiFi. Do you mean you were adding additional flows to your NiFi canvas when you started having issues? What else are you seeing in the NiFi logs prior to the ZK issue starting? What about CPU load? What about memory: Any Out Of Memory (EoM), continues garbage collection or long garbage collection events? Network issues resolving hostnames of the ZK nodes? Issues telnetting to ZK nodes using the zk configured ports (2888 and 3888)? I also appears you are using the embedded ZK which I would strongly discourage in any production system.  Any resource congestion issues your NiFi experience is going to have impacts on ZK quorum and cluster stability. I recommend standing up an external ZK on different hosts from where your NiFi is installed. It also worth noting that Apache NiFi 1.14.4 was released more then 6 years ago.  There have been many improvements, bug fixes, and CVEs addressed since then. Upgrading to the latest 1.28 (keeping in the same Major release 1.x branch) would be very advisable.  There will be No more Apache NiFi 1.x versions released now that Apache NiFi 2.x major release branch is available. 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

@pnac03  You are correct, The NiFiRegistry client should be using the keystore and truststore configured in the configured SSLContextService in the MutualTLS handshake with the target NiFi-Registry. Can you share the verbose keytool output for both your NiFi-Registry keystore and truststore? Verify that the keystore contains: Only one "PrivateKeyEntry" The PrivateKeyEntry "Owner" and "Issuer".  If not same DN, then it is not self-signed. The PrivateKeyEntry "ExtendedKeyUsages" (EKU).  Since you are trying to use this to perform "client" side connection to your NiFi-Registry from NiFi, it must include "clientAuth" as one of the EKUs Verify PrivateKeyEntry "KeyUsage" Verify that the truststore contians: One or more "trustedCertEntry"s.   It should include the complete trustchain. From the original openssl s_client connect command output you shared, I see you have a server certificate that has been signed by a Certificate Authority (CA).  The truststore used in the NiFi-Registry client in NiFi must contain the CA certificate. Using below openssl command will output every public certificate.  You can then copy each and import them in to the truststore you configured your NiFis to use in the NiFi-Registry client SSLContext.    openssl_s_client -connect <nifi-registry hostname>:<nifi-registry port> --showcerts  Here is the keytool command to verify the keystore information: keytool -v -list -keystore <keystore or truststore file>   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

@BobKing  Unfortunately there is not enough information provided to explain what is going on.  At. minimum you should always share the exact NiFi version being used to make it easier to check for any possible known issues affecting your version. Apache NiFi uses Quartz Cron. The cron you have configured is correct for "scheduling" a processor for execution at 17:00 every day.  Keep in mind that once scheduled for execution, how long afterwards it executes depends on thread availability.  There are potentially many processors on your NiFi canvas getting scheduled and the "Max Timer Driven Thread Count" pool of threads needs to service all those scheduled processors.  Generally thread execution is very fast, but at times you may have your thread pool being used by some longer running threads that could delay execution.  An execution at 16:07 pm seem very unexpected here. Did maybe someone manually execute the processor using "run once" at that time? Are you sure the processor ID executed each of those times? Is this a single instance of NiFi or a Multi-node NiFi cluster setup?  If cluster, is the system time synced to a NTP server to make sure all the servers to ensure consistent time across the cluster? 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

@Kiranq  Any exceptions (ERROR or WARN) being reported in logs? Any out of memory exceptions? Maybe get a diagnostics output while flow is in this state to get some insight on running threads.   (./nifi.sh diagnostics -verbose) Matt ... View more

@ThierryOfNantes  Welcome to the Cloudera community. I suspect your issue is with your run.as user.  While the nifi.sh may have executable to all, does your run.as user have necessary permissions to traverse the entire directory tree to the nifi.sh script? I suggest trying to navigate the directory tree as the run as user and starting nifii.sh manually as that user.    Can you share your /etc/rc.d/init.d/nifi script? Can you share your /install_directory/nifi/bin/nifi.sh script?   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

@mansmaan  I'm afraid there is not enough information shared yet to know exactly why you are experiencing a connection refused or connection reset issue from your NiFi node.  I was able to use InvokeHTTP with no issue to successfully get a response from the URL you provided.  I was able to view the weather data that was returned in json format. Have you tried to reach wttr.in directly from command line on the NiFi server? This sound like an environmental issue and not a NiFi invokeHTTP issue.    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

@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