@SAMSAL  Looking at output provided, you appear to running your Apache NiFi on Windows.  It appears this issue was raised 2 days ago against M3 in Apache Jira here: https://issues.apache.org/jira/browse/NIFI-13394 It is currently unresolved.  You can certainly create an Apache jira account and add additional comments to this jira with your detailed findings. Please help our community thrive. 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

@SAMSAL  This is some great detail.  I believe you are hitting this bug that has been fixed for the next 2.0.0 milestone release (M4): https://issues.apache.org/jira/browse/NIFI-13329 There will eventually be a 2.0.0 RC release.  That will be the first official Release Candidate for new 2.x versions that will follow all these development milestone releases.   You can create an Apache Jira account that would give you the ability to raise new issues you find directly in the Apache NIFi project.  This is best way to bring your finding to the developer community. Please help our community thrive. 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

@helk  You can use a single certificate to secure all your nodes, but i would not recommend doing so for security reasons.  You risk compromising all your host if any one of them is compromised.  Additionally NiFi nodes act as clients and not just servers.  This means that all your hosts will identify themselves as the same client (based off DN).  So tracking client initiated actions back to a specific node would be more challenging.  And if auditing is needed, made very difficult. The SAN is meant to be used to differently.  Let's assume you host an endpoint searchengine.com which is back by 100 servers to handle client requests.  When a client tries to access searchengine.com that request may get routed to anyone of those 100 servers.  The certificate issues to each of those 100 servers is unique to each server; however, every single one of them will have the searchengine.com as an additional SAN entry in addition to their unique hostname.  This allows the host verification to still be successful since all 100 are also known as searchengine.com. Your specific issue based on shared output above is caused by the fact that your single certificate does not have "nifi01" in the list of Subject Alternative Names (SAN).  It appears you only added nifi02 and nifi03 as SAN entries. The current hostname verification specs no longer use DN for hostname verification.  Only the SAN entries are used for that.  So all names(hostnames, common names, IPs) that may be used when connecting to a host must be included in the SAN list. NiFi cluster keystore requirements: 1. keystore can contain only ONE privateKeyEntry. 2. PrivateKey can not use wildcards in the DN. 3. PrivateKey must contain both clientAuth and serverAuth Extended Key Usage (EKU). 4. Privatekey must contain at least one SAN entry matching the hostname of server on which keystore will be used. The NiFi truststore must contain the complete trust chain for your cluster node's PrivateKeys.  On truststore is typically copied to and used on all nodes. Please help our community thrive. 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

@tcherian  NiFi certificates must meet the following criteria: 1.  No wildcards used in the subject DistinquishedName (DN)  2. Included both clientAuth and serverAuth in the ExtendedKeyUsage (EKU) 3. Contains one or more SubjectAlternativeName (SAN) entries. 4. Keystore can only contain 1 PrivateKey entry There are many resources on the web for generating your own self-signed certificates and adding them to a PKCS12 or JKS keystore.  The "Keystore" and "truststore" are both just keystores.  The NiFi "Keystore" contain the PrivateKey entry which Is used by NiFi to identify itself as the server (serverAuth) when connecting to it and as the client (clientAuth) when connecting outward as a client (such as talking to other NiFi's, NiFi-Registry, etc).  The NiFi "truststore" contains one too many TrustedCert entries.  It is common to use the default Java cacerts file (which is just a jks keystore) and add additional TrustedCert entries to it.  The trustedCerts are the public certs that correspond to the PrivateKey that you should never share.  The Trusted certs are the signers of the private keys.  There are intermediate and root trusted cert keys.  An intermediate trust is one where the owner and signer are not the same DN.  A root trust is one where the owner and signer are the same DN.   So you might create a PrivateKey that is signed by intermediate Certificate Authority (CA) and that intermediate CA would be signed by another intermediate CA or a root (CA). The chain of signers between intermediate and root is known as the trustchain.  The Truststore needs to contain complete trust chains for your PrivateKey.    There are even free services out there like Tinycert, but you can also use openssl and keystool to generate self-signed certificates and import them to a keystore.  Just google how to create a certificate and how to import certificate into a keystore. Please help our community thrive. 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

Hi @MattWho  ,  I have figured it out,  I set the access policy recieve data via site-to-site and its has now started to work.     i used an api call to set the value referring to this. Access Policies | CDP Private Cloud (cloudera.com) thank you so much for your help.   TO Summarize,  nifi.properties  bash-4.4$ cat conf/nifi.properties | grep remote nifi.remote.input.host=nifi-0.nifi-headless.namespace.svc.cluster.local nifi.remote.input.secure=true nifi.remote.input.socket.port=10443 nifi.remote.input.http.enabled=true nifi.remote.input.http.transaction.ttl=30 sec nifi.remote.contents.cache.expiration=30 secs in another pod nifi.remote.input.host=nifi-1.nifi-headless.namespace.svc.cluster.local nifi.web.https.host=nifi-0.nifi-headless.namespace.svc.cluster.local nifi.web.https.port=9443 and respectively on another pod nifi.web.https.host=nifi-1.nifi-headless.namespace.svc.cluster.local nifi.web.https.port=9443 set access policies  created reporting task  url set is podname.svc/https port  eg  https://nifi-0.nifi-headless.doc-norc.svc.cluster.local:9443/nifi   set management controller service   created an input port and remote group to send data        ... View more