Created on 10-30-2024 06:30 PM - edited 10-30-2024 06:31 PM
All,
I have two separate NiFi instance and I want to push provenance events from one instance to another. Source NiFi's hostname is nifi8443 and Target NiFi's hostname is nifi8444.
Both of these instances are running over HTTPS. On the "Target NiFi" I set up an input port called Test.
On source NiFi, here's what my SiteToSiteProvenanceReportingTask looks like.
Here's a couple things I did.
I realized that the reporting task on NiFi8443 is essentially acting like an client and NiFi8444 is acting as the server. I added the NiFi8444 server certificate into a truststore.p12 file on NiFi8443 and created the corresponding SSLContextService to point to that Truststore file.
I resolved the SSL issue and then I was reading on the target node (ie. NiFi8444) I had to make an identity for the full DN of the source (ie NiFi8443) certificate. So on NiFI8444, I created a new user called this - CN=nifi8443, O=NiFi Server, L=San Francisco, ST=California, C=US
Then I added that identity to two policies. The first one is retrieve-site-to-site -
And the second one is the input port -
I thought that was all the requirements however, I am currently getting this error when I start the reporting task.
SiteToSiteProvenanceReportingTask[id=d9ece17e-0192-1000-9050-2a4a5a2f9e02] Unable to refresh remote group peers due to: response code 401:Unauthorized with explanation: null
It seems like it has to do with the identity from NiFi8443 not properly being authenticated correctly. But when I run keytool -list -v -keystore nifi8443.p12 on the server certificate I get this -
@MattWho @SAMSAL - Do you know why I getting a 401 unauthorized error?
Created 10-31-2024 06:33 AM
@drewski7
While you added the public cert for your NiFi8444 to the truststore used in the nifi8443 StandardRestrictedSSLContetService, did you do the same in reverse?
Does your StandardRestrictedSSLContetService also include the keystore? The Keystore contains the PrivateKey that is used in the mutual TLS exchange with NiFi8444.
NiFi8443's public cert (or complete trusts chain) needs to be added the truststore configured in the nifi.properties file on NiFi8444.
You'll also want to look at the nifi-user.log on NiFi8444 to see the full exception thrown when NiFi8443 reporting tasks is trying to retrieve the Site-to-Site (S2S) details.
Identities will be manipulated by matching identity mapping patterns setup in the nifi.properties file. So you'll want to verify that also.
Additionally, are you still using Single-User-provider on NiFI8444 along with the NiFi auto generated keystore and truststore? (I saw CN=localhost in one of your images). You should create a keystore and truststore with proper DN and SANs for use with S2S.
Hope this helps with your investigation and troubleshooting.
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
Created 10-31-2024 06:33 AM
@drewski7
While you added the public cert for your NiFi8444 to the truststore used in the nifi8443 StandardRestrictedSSLContetService, did you do the same in reverse?
Does your StandardRestrictedSSLContetService also include the keystore? The Keystore contains the PrivateKey that is used in the mutual TLS exchange with NiFi8444.
NiFi8443's public cert (or complete trusts chain) needs to be added the truststore configured in the nifi.properties file on NiFi8444.
You'll also want to look at the nifi-user.log on NiFi8444 to see the full exception thrown when NiFi8443 reporting tasks is trying to retrieve the Site-to-Site (S2S) details.
Identities will be manipulated by matching identity mapping patterns setup in the nifi.properties file. So you'll want to verify that also.
Additionally, are you still using Single-User-provider on NiFI8444 along with the NiFi auto generated keystore and truststore? (I saw CN=localhost in one of your images). You should create a keystore and truststore with proper DN and SANs for use with S2S.
Hope this helps with your investigation and troubleshooting.
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
Created 11-04-2024 06:02 AM
The problem was my StandardRestrictedSSLContextService didn't include a keystore. For some reason, I thought it was just one way SSL communication. Once I added the keystore to the ContextService it was authenticating correctly! Thanks @MattWho !