@AyanF
I would hope that if you are securing a processor such as HandleHTTPRequest processor to control access to this endpoint, that you have also secured your NiFi instance/cluster as well?
SSL/TLS is a very deep subject which is a bit much to discuss end-to-end here, but i will give a 10,000 foot view to help get you started.
If so, then somewhere along the line a keystore and truststore were generated to secure your NiFi.
Keystore files (keystore or truststore) are not something unique to NiFi nor any NiFi processor that uses them. Keystore and truststores are used to facilitate TLS handshakes and establish a secure and encrypted connection between a client and a server.
A keystore used by NiFi would contain a single "PrivateKeyEntry". This privateKeyEntry used by HandleHHTPRequest processor must have an Extended Key Usage (EKU) that support at least serverAuth (for securing NiFi itself it would need both serverAuth and clientAuth EKUs). It must also contain a SubjectAlternativeName (SAN) that contains the hostname of server on which your NiFi is running. Commonly the same keystore used to secure your NiFi instance is also used in the SSLContext service to secure components used in your dataflows but not a requirement.
A Truststore contains one too many "TrustedCertEntry"s. The trustedCertEntries are the public keys for self-signed certificates, intermediate, and root Certificate Authorities (CA).
TLS works the same accessing a secured NiFi or secured NiFi processor as it does accessing any other https site. The server side of the connection decides if the TLS handshake should be 1-way or mutual. In a 1 way TLS connection, the secured server provides its certificate to the client. The client verify that it trusts that server certificate. The server does not require the client to identify itself via a client certificate. This is how https://www.google.com works.The Server has the option to require/need or want a client certificate. The HandleHTTPRequest processor which would be server side of the TLS connection can be configured for one of those options. In a TLS client and server exchange the certificate DN is always used to identify the server to the client and client to the server. The Client certificate presented must be trusted by the server side as well. An truststore is included with every Java distribution. The file is named "cacerts" and it contains a bunch of trustedCertEntrys for well know CAs.
You can view the contents of a keystore like the cacerts file using java's keytool command:
keytool -v -list -keystore <path to keystore file>/<keystore filename>
Naturally if you create your own certificate it would be self signed and the cacerts file would need to have the public cert/key for your self signed private cert/key added to it.
Here is a example process for creating a keystore:
https://docs.oracle.com/cd/E19509-01/820-3503/ggfen/index.html
There are also services (some free) you can use to generate a signed certificate. Those services will also provide you with the public certs for your truststore.
https://www.tinycert.org/
But simply having a keystore and truststore on the NiFi (server) side is not enough to establish a secured connection. The client that is connecting to you NiFi handleHTTPRequest endpoint must also have a truststore. That truststore must contain the public cert/key if using a self signed server side cert or the complete trustchain for CAs that signed your server certificate. What is a trustchain? When you get a server cert signed, it may be signed by an intermediate CA or a root CA. An intermediate CA is a CA that itself has been signed by yet another CA. A root CA is signed by itself (Owner and issuer are same DistinquishedName (DN)). The complete trustschain would involve having every public cert from intermediate CA to the rootCA. Let's say your server cert is signed by intCA1 and intCA1 is signed by rootCA. RootCA is signed by RootCA. So the complete trustschain would require having the public cert/key for both intCA1 and rootCA in the truststore.
Now if you choose to have your HandleHttpRequest processor to "need authentication", the client must have a certifcate the truststore configured in your SSLContextService is capable of trusting (meaning it needs to complete trustchain in that truststore for that client cert/key. Keep in mind that any client certificate that is trusted by that truststore will be able to interface with that endpoint.
I understand this is a lot, but it only scratches the surface. Hopefully it is enough to get you were you need to be to secure your NiFi and NiFi components.
If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped.
Thank you,
Matt
