@techNerd  Clearing a processor components state requires stopping the processor before you can "clear the state".  Stopped state is required because the the processor may be writing or updating state when you attempt to clear state which would cause issues. When stopped there is no need to worry about a race condition between writes and deletes. That being said, reseting the sequence number stored in state to 0 can be accomplished using the advanced UI of the UpdateAttribute processor and a special reset-seq flowfile you feed into the processor at 00:00 each day.  The advance UI of the UpdateAttribute processor works like if,the,else logic.   So you would set up a Rule "reset" and a condition (if), If condition is true the "Actions" are applied.  If no Rules's  conditions are true, the processor's non advanced UI properties are applied.   UpdateAttribute properties (same as you already have): Click on "advanced" in lower left corner of processor configuration UI to open and configure Rules: Now all you need to do is setup a GenerateFlowFile processor that feeds a FlowFile into the updateAttribute processor once a day to reset seq to 0 stored in tat UpdateAttributes processor's local state.   Optionally  you could add a RouteOnAttribute processor after the UpdateAttribute to route out the sequence file for termination so it does not continue through your dataflow. If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@PriyankaMondal  1. Not clear on the question here.  Why use Toolkit to create three keystores?  I thought you were getting three certificated (one for each node) from your IT team.  Use those to create the three unique keystores you will use. 2. It appears your DN has a wildcard in it.  NiFi does not support the use of wildcards in the DN of node ClientAuth certificates.  This is because NiFi utilizes mutualTLS connections and the clientAuth DN is used to identify the unique connecting clients and is used to setup and configure the authorizations.    Now you could ask your IT team to create you one keystore with a non wildcard DN like "cn=nifi-cluster, ou=domainlabs, DC=com" and add all three of your Nifi node's hostnames as SAN entries in that one PrivateKeyEntry.  This would allow you to use that same PrivateKey keystore on all three NiFi nodes.  This has downsides liek security. If keystore on one node gets compromised, all hosts are compromised because it is reused.  All nodes will present as same client identity (since all present same DN) during authorization. So nothing will distinguish one node from the other. The keystore used by NiFi can ONLY contain one privateKey entry.  Merging multiple keystores with privateKey entries will result in one keystore with more than one PrivateKeyEntry which is not supported by NiFi.  If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@LKB  Can you share screenshots of your UpdateAttribute processor configuration? Are you using the advanced UI of the UpdateAttribute processor? The UpdateAttribute processor is fairly simplistic in design. Without configuring the advanced UI, it simply can remove attributes or create/modify existing attributes.  Each Attribute is defined by key:value pairs where the property name is the key and property value is the key.  The Advanced UI allows for conditionally based attribute additions or modifications. If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt   ... View more

@PriyankaMondal  You should have a signed certificate for each of your three NiFi nodes.  Make sure those certificates meet the minimum requirements for NiFi. Certificate DN can not contain wildcards. Certificate Extended Key Usage (EKU) must include "clientAuth" and "serverAuth" Certifcate must contain SAN entry for server hostname and any alternate DNS names that server may use. The Certificate (PrivateKey) needs to be placed inside a JKS or PKCS12 keystore.  There are plenty of resource in the web for creating keystores.  But essentially you want to combine your pem and key files to make a p12 file.  You can then import that p12 file in to a JKS keystore. A NiFi keystore must contain ONLY one PrivateKeyEntry.   So don't create a singel keystore where you import all 3 private keys.  You should have three separate Keystores (one for each NiFi node). NiFi uses two keystores (keystore and truststore): Keystore - contains only one PrivateKeyEntry (unique to each NiFi node) Truststore - contains one too many TrustedCertEntries.  The same truststore is used on all NiFi nodes.  The truststore needs to contain the compete trust chain for your node's private keys.   A certificate is signed by an authority. In order for server to trust a certificate presented in a TLS exchange, the authorities that signed that certificate must be trusted. That is where this truststore comes into play.  An authority can be of two types, intermediate CA or Root CA.  An intermediate CA is one where the issuer and signer are two different entities (DNs don't match).  A Root CA is one where the issue and signer are the same (DNs match).   Let's say you Private key with DN = "CN=node1, OU=NiFi" was signed by an Intermediate corp CA with "DN = CN=Intermediate1, 0U=company".   And that intermediate CA TrustedCert was signed by a Root CA with DN = "CN=RootCA, Ou=company".  In order for your truststore to have the complete trust chain,  the NiFi truststore would need to contain both a TrustedCertEntry for Intermediate CA and the root CA.  For the Truststore you will need to get the public cert(s) from your IT team (who should also be able to help you with your keystore and truststore creation) As far as the setup of NIFi goes, nothing else is different from what you did when using the self-signed certificates when it comes to configuration.   Keep in mind that each node's identity is derived from the nodes private certifcate DN.  That DN is evaluated against and configured user identity mapping patterns configired in the nifi.properties file.  If the java regex pattern matches the certificate DN, the mapping value  and mapping transform are applied.  That resulting mapped identity is what needs to be authorized in NiFi.  So these mapped identities become your node identities when configuring the NiFi authorizer. If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more