Thanks, Isha for the first cut. We have a whole bunch of systems that are in an internal network that are all able to talk using site to site, so we are not unfamiliar with the connection, but after a long session of comparisons and changes, I still cannot this to work.
I enabled DEBUG in logback.xml across the board....I now have more debug that I can figure out how to use, but the one thing that recurs: *DEBUG [NiFi Web Server-87] o.a.n.w.s.l.RequestAuthenticationFilter Username not found Remote Address [20.XXX.XXX.XXX]* That is the log from the RECEIVER (Nif with the Input port). The IP address in the log message is the SENDER (nifi with remote process group) (Sorry, not sure how the server/client terminology works here) But no where in the logs does it say what the username is, it just says it is not found, so I am not clear on what is wrong with the username. I have fair experience with certificate generation and we generate our own internal certs using locally generated CA and everything has worked perfectly to this point. I am also pretty familiar with the username format and how to retrieve it....I currently have 20+ NiFi systems that are all using site to site with no issues. The server certs have been added on both sides to the local truststore, and I am not getting a PKIX error, very specifically getting the Unauthorized which, as noted, is associated with the hostname. If the hostname was accepted, I would get Forbidden if there were policy issues....the problem is that I cannot get to that point. The machines are both in azure, but I am using the FQDN of the receiver and routing to the internet. The internal azure networks cannot talk to each other. Any help at this point would be welcome, we have done this before, we are at a loss as to why we cannot do it now. NOTE: After writing the above, I did realize one thing: all our internal NiFi systems are communicating via site to site using common CA certs. The CA cert has been loaded in the truststore and they are all happy to talk to each other as long as the CA's all match. In the example I am talking about above, I have just inserted the server cert (PEM file) into the truststore on both boxes. The systems are OK with this because I don't have a PKIX error, but there may be something at issue with the username?? Dave On Thu, Jun 27, 2024 at 1:29 AM Isha Lamboo <[email protected]> wrote: > Hi David, > > > > This typically means one of two things: > > 1. that the DN of the (client) certificate does not match the user in > the receiving NiFi instance **exactly**. > Inspect the logs (I think it’s nifi-user.log) to find the DN that the > sending NiFi is providing and edit the username in the receiving NiFi > instance. > 2. The user is correct but does not have permissions to send data to > the input port. Each input port needs these permissions set separately. > Right-click on it and click “manage access policies”. In the dropdown box > select “receive site-to-site data” and add the user or group that should be > allowed to send data to this port. > > > > Hope this helps you find the issue. > > > > Regards, > > > > Isha > > > > *Van:* David Early via users <[email protected]> > *Verzonden:* donderdag 27 juni 2024 01:33 > *Aan:* [email protected] > *Onderwerp:* Nifi Site to Site error message meaning > > > > All, > > > > I am trying to get an HTTP site to site set up, and I have done this a > bunch of times, but I am seeing an error that I have not seen before and > the logs are not helping. > > > > I have gotten PKIX errors and Forbidden, but I am getting an Unauthorized > message: > > > > > > What is this telling me? Where is the problem in the permission chain? > > > > -- > > David > -- David Early, Ph.D. [email protected] 720-470-7460 Cell
