Hello, This sounds correct, it is an exact match of the DN coming from the certificate (case and white-space sensitive) against the identity entered as a user in LDAP or file-based.
-Bryan On Tue, Sep 18, 2018 at 4:54 AM Nikhil Chaudhary <[email protected]> wrote: > > 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. > >> > >> > > > > >
