Just to clarify, in NiFi 1.7.1 and above, the hostname verification comes from the SubjectAlternativeName of the certificate rather than the DN as described in RFC 6125. This change is called out in the Migration Guidance [1]. The LDAP user identity still comes from the DN of the certificate. In addition, wildcard certificates are not supported, as noted in the Admin Guide [2]. The TLS Toolkit makes generation of unique, explicit certificates easy and scalable, and should be used in place of wildcard certificates.
[1] https://cwiki.apache.org/confluence/display/NIFI/Migration+Guidance <https://cwiki.apache.org/confluence/display/NIFI/Migration+Guidance> [2] https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#tls-generation-toolkit Andy LoPresto [email protected] [email protected] PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Sep 18, 2018, at 5:39 AM, Bryan Bende <[email protected]> wrote: > > 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. >>>> >>>> >>> >> >> >>
signature.asc
Description: Message signed with OpenPGP using GPGMail
