Member since
10-23-2018
43
Posts
0
Kudos Received
0
Solutions
11-06-2018
11:21 AM
@nisrine elloumi - Since the target NiFi configured in the Remote Process Group has been secured, your MiNiFi agent will need a keystore an truststore as well. The keystore must contain a singls PrivateKeyEntry that will be trusted by a TrustedCertEntry in the truststore of your NiFi. The truststore on your MiNiFi agent must contain a trustecCertEntry that is capable of establishing trust of the certificate coming from the target NiFi. - If your target NiFi has been secured using the the NiFi CA, you can use the TLS-toolkit to generate a new server certificate for your MiNiFi agent. Below can be found in the NiFi Admin guide: - Client The client can be used to request new Certificates from the CA. The client utility generates a keypair and Certificate Signing Request (CSR) and sends the CSR to the Certificate Authority. The client is invoked by running ./bin/tls-toolkit.sh client -h which prints the usage information along with descriptions of options that can be specified. You can use the following command line options with the tls-toolkit in client mode:
-a , --keyAlgorithm <arg> Algorithm to use for generated keys (default: RSA ) -c , --certificateAuthorityHostname <arg> Hostname of NiFi Certificate Authority (default: localhost ) -C , --certificateDirectory <arg> The directory to write the CA certificate (default: . ) --configJsonIn <arg> The place to read configuration info from, implies useConfigJson if set (default: configJson value) -D , --dn <arg> The DN to use for the client certificate (default: CN=<localhost name>,OU=NIFI ) (this is auto-populated by the tool) -f , --configJson <arg> The place to write configuration info (default: config.json ) -F , --useConfigJson Flag specifying that all configuration is read from configJson to facilitate automated use (otherwise configJson will only be written to) -g , --differentKeyAndKeystorePasswords Use different generated password for the key and the keystore -h , --help Print help and exit -k , --keySize <arg> Number of bits for generated keys (default: 2048 ) -p , --PORT <arg> The port to use to communicate with the Certificate Authority (default: 8443 ) --subjectAlternativeNames <arg> Comma-separated list of domains to use as Subject Alternative Names in the certificate -T , --keyStoreType <arg> The type of keystores to generate (default: jks ) -t , --token <arg> The token to use to prevent MITM (required and must be same as one used by CA) After running the client you will have the CA’s certificate, a keystore, a truststore, and a config.json with information about them as well as their passwords. - You will need to collect the needed information about your CA. You could run this toolkit right on the server where the NiFi CA was installed (for example from /tmp directory). Then you just need to move the produced keystore and truststore files over to your MiNiFi agent and configured the yaml file to use them. - If you are using a keystores and truststores generated by some other CA, you will need to follow whatever procedure that authority to generate the new keystore and truststore needed for your MiNiFi agent. Just make sure the criteria I outlined at the beginning is being met so that the 2-way TLS handshake will be successful. - Thank you, Matt - If you found this answer addressed your question, please take a moment to login in and click the "ACCEPT" link.
... View more
12-10-2018
04:40 PM
Thank you @Bryan Bende for this response My ConsumeKafka_0_10 works fine and i obviously don't have an errors like @Eric Lloyd but i can't see my data in the processor. Is that what we call back-pressure ? could this can be resolved with increasing the Maximum Timer Driven Thread Count and Maximum Event Drive Thread Count ? what does that means ? Could you please give some suggesion. Thanks you in advance.
... View more