Hi Bryan and Mark, Thank you for your replies. So after a lot of trial and error, got the connection working between NiFi and the NiFi Registry.
Went with the approach of LDAP + local file based. However, it seems like since we’ve installed a wildcard certificate, we need to specify the DN exactly as follows in the Initial User Identity as well as the Node Identity: CN=*domain.com, O="Company", L=Place, ST= Area, C=TH Only then it works. Even if we try adding a subdomain such as nifi.domain.com in the CN, the whole thing stops working. Is this how it’s intended to work? Thank You. Best Regards, Nikhil C. On 17/9/18 20:39, "Bryan Bende" <[email protected]> wrote: In addition to what Mark said, the NiFi nodes to be represented as users somewhere in order to create policies that grant them proxy permission. If your authorizer is using the LDAP user group provider then you could create users in LDAP to represent your NiFi nodes. If you don't want to create users in LDAP, then you can use a composite user group provider made up of LDAP + file-based and you can create users in the file-based user group provider using the DNs of the NiFi certificates. On Mon, Sep 17, 2018 at 9:11 AM Mark Payne <[email protected]> wrote: > > Nikhil, > > LDAP is used for user authentication. Machine-to-machine communications, though, must use > certificates, and so authentication in this case is done via certificates. In both cases, though, this > is authentication (i.e., identifying who the user is), not authorization (i.e., determining the user's permissions). > You'll need to ensure that you assign appropriate permissions for your users. All NiFi nodes will need the > Proxy permission, I believe. The Registry User Guide [1] will explain the different permissions/policies available > and what they are used for. > > Thanks > -Mark > > > [1] https://nifi.apache.org/docs/nifi-registry-docs/html/user-guide.html#special-privileges > > > On Sep 17, 2018, at 8:34 AM, Nikhil Chaudhary <[email protected]> wrote: > > Hi Mark, > > So I added clientAuth and serverAuth both in the certificate and now the error is as follows: > > NiFi Registry Logs: > > 2018-09-17 12:26:07,170 INFO [NiFi Registry Web Server-12] o.a.n.r.w.s.NiFiRegistrySecurityConfig Identity in proxy chain not trusted to act as a proxy: org.apache.nifi.registry.web.security.authentication.exception.UntrustedProxyException: Untrusted proxy [CN=*domain.com, O="Company", L=Place, ST= Area, C=TH]. Returning 403 response. > > > NiFi Logs: > > 2018-09-17 12:26:07,202 INFO [NiFi Web Server-21] o.a.n.w.a.config.NiFiCoreExceptionMapper org.apache.nifi.web.NiFiCoreException: Unable to obtain listing of buckets: org.apache.nifi.registry.client.NiFiRegistryException: Error retrieving all buckets: Untrusted proxy [CN=*domain.com, O="Company", L= Place, ST=Area, C=TH]. Contact the system administrator.. Returning Conflict response. > 2018-09-17 12:26:07,203 DEBUG [NiFi Web Server-21] o.a.n.w.a.config.NiFiCoreExceptionMapper > org.apache.nifi.web.NiFiCoreException: Unable to obtain listing of buckets: org.apache.nifi.registry.client.NiFiRegistryException: Error retrieving all buckets: Untrusted proxy [CN=*domain.com, O="Company", L= Place, ST= Area, C=TH]. Contact the system administrator. > > Both the registry and NiFi are running on the same instance for test purposes and have the same host set up in the configuration: nifi.domain.com > Any idea what could be wrong now? > > The only information I've found online is to add the Node information within the authorizers file, however since we use LDAP, I believe that isn't necessary? Or is it similar to the set up of nifi-to-nifi clustering? > > Cheers, > Nikhil C. > > On Thu, Sep 13, 2018 at 8:40 PM Mark Payne <[email protected]> wrote: >> >> Hi Nikhil, >> >> The property that you mention: "nifi.registry.security.needClientAuth" applies only to user logins. >> This allows users to login via certificate or other methods by not requiring that they present a client >> certificate. However, NiFi & registry require mutual authentication for all machine-to-machine interactions. >> So in order to have NiFi talk to the registry, NiFi's cert will need to have client auth usage as well. >> >> Thanks >> -Mark >> >> >> On Sep 13, 2018, at 5:35 AM, Nikhil Chaudhary <[email protected]> wrote: >> >> Hey Guys, >> >> Been stumped with a certificate issue. >> A bit of info on the deployment strategy. >> >> NiFi is running with a wildcard certificate in its keystore (*.domain.com) – It’s a self signed certificate. >> We’ve added the Root CA in the truststore of NiFi. >> >> We’ve used the same keystore to run NiFi registry. >> >> So installing the Root CA on my laptop, I can access NiFi on HTTPS with no errors or warnings. >> In theory the Root CA within the NiFi truststore should do the same when accessing NiFi registry, shouldn’t it? >> >> I enabled debug logs and the error that came up was: Caused by: sun.security.validator.ValidatorException: Extended key usage does not permit use for TLS client authentication >> >> The certificate only has serverAuth in it’s extended key usage but shouldn’t that be enough? >> I’ve seen emails and posts online regarding NiFi clustering in which case clientAuth needs to be enabled but this case seems different? >> >> ClientAuth in NiFi registry properties file is set as false. >> nifi.registry.security.needClientAuth=false >> >> Is there something I’m missing or not doing correctly? >> >> Stack Trace: >> >> 2018-09-12 11:02:22,581 DEBUG [NiFi Registry Web Server-15] org.eclipse.jetty.server.HttpConnection >> javax.net.ssl.SSLHandshakeException: General SSLEngine problem >> at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1529) ~[na:1.8.0_181] >> at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535) ~[na:1.8.0_181] >> at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:813) ~[na:1.8.0_181] >> at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781) ~[na:1.8.0_181] >> at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624) ~[na:1.8.0_181] >> at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.fill(SslConnection.java:621) ~[jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317] >> at org.eclipse.jetty.server.HttpConnection.fillRequestBuffer(HttpConnection.java:322) [jetty-server-9.4.3.v20170317.jar:9.4.3.v20170317] >> at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:231) [jetty-server-9.4.3.v20170317.jar:9.4.3.v20170317] >> at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279) [jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317] >> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:110) [jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317] >> at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:258) [jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317] >> at org.eclipse.jetty.io.ssl.SslConnection$3.succeeded(SslConnection.java:147) [jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317] >> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:110) [jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317] >> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124) [jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317] >> at org.eclipse.jetty.util.thread.Invocable.invokePreferred(Invocable.java:122) [jetty-util-9.4.3.v20170317.jar:9.4.3.v20170317] >> at org.eclipse.jetty.util.thread.strategy.ExecutingExecutionStrategy.invoke(ExecutingExecutionStrategy.java:58) [jetty-util-9.4.3.v20170317.jar:9.4.3.v20170317] >> at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:201) [jetty-util-9.4.3.v20170317.jar:9.4.3.v20170317] >> at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:133) [jetty-util-9.4.3.v20170317.jar:9.4.3.v20170317] >> at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:672) [jetty-util-9.4.3.v20170317.jar:9.4.3.v20170317] >> at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:590) [jetty-util-9.4.3.v20170317.jar:9.4.3.v20170317] >> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_181] >> Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem >> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) ~[na:1.8.0_181] >> at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728) ~[na:1.8.0_181] >> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:330) ~[na:1.8.0_181] >> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:322) ~[na:1.8.0_181] >> at sun.security.ssl.ServerHandshaker.clientCertificate(ServerHandshaker.java:1979) ~[na:1.8.0_181] >> at sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:237) ~[na:1.8.0_181] >> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052) ~[na:1.8.0_181] >> at sun.security.ssl.Handshaker$1.run(Handshaker.java:992) ~[na:1.8.0_181] >> at sun.security.ssl.Handshaker$1.run(Handshaker.java:989) ~[na:1.8.0_181] >> at java.security.AccessController.doPrivileged(Native Method) ~[na:1.8.0_181] >> at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1467) ~[na:1.8.0_181] >> at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.fill(SslConnection.java:727) ~[jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317] >> ... 15 common frames omitted >> Caused by: sun.security.validator.ValidatorException: Extended key usage does not permit use for TLS client authentication >> at sun.security.validator.EndEntityChecker.checkTLSClient(EndEntityChecker.java:238) ~[na:1.8.0_181] >> at sun.security.validator.EndEntityChecker.check(EndEntityChecker.java:145) ~[na:1.8.0_181] >> at sun.security.validator.Validator.validate(Validator.java:274) ~[na:1.8.0_181] >> at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324) ~[na:1.8.0_181] >> at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:279) ~[na:1.8.0_181] >> at sun.security.ssl.X509TrustManagerImpl.checkClientTrusted(X509TrustManagerImpl.java:130) ~[na:1.8.0_181] >> at sun.security.ssl.ServerHandshaker.clientCertificate(ServerHandshaker.java:1966) ~[na:1.8.0_181] >> ... 22 common frames omitted >> >> >> >> Thank You. >> >> Best Regards, >> Nikhil C. >> >> >
