Configure SiteToSiteBulletinReportingTask in NIFI single Node

[#1]

I have NIFI single Node and for my learning purpose I'm trying to implement SiteToSiteBulletinReporyingTask (with assuming this will work for single node)

I configured StandardRestrictedSSLContextService as below

Note - same keystore and truststore used inside nifi-properties

I configured SiteToSiteBulletinReportingTask as below

Note - the destination URL is the same URL that nifi is currently running.

Now I'm facing below issues -

1. I'm not receiving any data to the bulletin port. I'm getting the

2. below warning message in nifi-app.log (couldn't find resource to fix this)

The issue is I'm getting the below warning and, to be honest, I don't have a clear idea about this warning, and also

2022-10-23 17:57:09,618 WARN [NiFi Site-to-Site Connection Pool Maintenance] o.apache.nifi.remote.client.PeerSelector Unable to refresh remote group peers due to: Certificate for <xxx.xxx.xx.xxx> doesn't match any of the subject alternative names: [localhost]

2022-10-23 17:57:09,618 WARN [NiFi Site-to-Site Connection Pool Maintenance] o.a.n.r.SiteToSiteBulletinReportingTask SiteToSiteBulletinReportingTask[id=105311a0-1473-1059-2fb8-ea483b8d9fa8] Unable to refresh remote group peers due to: Certificate for <xxx.xxx.xx.xxx> doesn't match any of the subject alternative names: [localhost]

[#2]

@D5ha 

Your issue here is with the certificate being used to perform the clientAuth action. 
Your certificate would also not work if you had a multi-node cluster.  It is only working as single node cluster because there are no other nodes for which your single node need to communicate as a client.

The keystore requirements for NiFi are as follows:
1. keystore MUST contain ONLY one PrivateKeyEntry
2. PrivateKeyEntry MUST have both clientAuth and ServerAuth ExtendedKeyUsage (EKU)
3. PrivateKeyEntry MUST have a SubjectAlternativeName (SAN) entry that matches the NiFi node's server hostname. If you are also going to be addressing your server by its IP, you should have that IP as a SAN entry as well.  Any other alternative hostname this server may be known as (meaning user type that alternate hostname in a URL to reach this host) should also be added to SAN.

In your case, the current issue happens in the mutual TLS handshake.  You have configured your SiteToSiteBulletinReportingTask to send to https://<some ip>/nifi.  The same NiFi server receive that client hello and responds with a server hello back which includes the SAN entries.  In your case the client (reporting task) looks at that server hello and basically rejects the handshake at that point in time.  It does this because of what looks like a man-in-the-middle attack.   The client tried to reach host <some ip> but instead a host with san <localhost> responded.

There is no configuration change you can make in your secured NiFi to get around this.  You'll need to get a new certificate meeting that above min criteria I outlined.  You'll need t do this also if you ever intend to add more hosts to your NiFi cluster.

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

[#3]

@Matt It would be great if you could share some guides or documents to generate the certificate and do the above configuration

[#4]

@D5ha   Your issue is a mutual TLS handshake issue and really has nothing specific to do with NiFi itself.  There are a lot of resources on the web for creating certificates.  There are even free services like Tinycert you can use to generate valid certificate meeting the requirements I shared in my last response.  

Providing guidance on how to create certificates does not make much sense since it can be done so many ways:
- Self-signed
- public CA
- Corporate/private CA
etc.

Your current shared TLS exception is telling you that the IP or Hostname (you have BLUE line through it in yoru image) was not found as a Subject Alternative Name (SAN) in the certificate created for the server side of this handshake which in yoru case happens to also be your NiFi instance.  

The Site-To-Site-Bulletin-Reporting-Task is acting as the client in this Mutual TLS handshake and the NiFi server S2S destination URL is the server side of this TLS handshake.

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