Re: My nifi no more serve admin interface

2019-08-15 Thread Andy LoPresto 
I think in general it’s hard for us to know when a bad keystore is provided 
until a connection tries to come in because a lot of that is delegated to 
Jetty. There was talk previously about a “keystore checker” toolkit feature 
which would look at the complete provided configuration for TLS and try to 
verify it was correct / diagnose any issues. Unfortunately with time & 
availability the way they are, I don’t think anyone has been able to work on 
it. 

I know there is a lot of documentation around configuring TLS for NiFi and 
diagnosing various problems manually but it’s not collected seamlessly in a 
canonical format and location. I am slowly working with some other community 
members to improve this as well. For now we generally try to push users who 
don’t have a strong grasp of the TLS generation/configuration process to the 
toolkit to offload a lot of that process, and suggest they read the 
documentation proactively to have a sense of the “good path” forward rather 
than exploring/experimenting and going down a rabbit hole. 

We always value contributions to the process/documentation and even something 
as minimal as sharing the process you took so we can identify the best 
wording/approach to intercept at the exact point where the wrong decision 
seemed like the right one is helpful to the entire community. Thanks. 


Andy LoPresto
alopre...@apache.org
alopresto.apa...@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

> On Aug 14, 2019, at 7:31 AM, Edward Armes  wrote:
> 
> Hmm, I wonder if there's a change that could be made to expose this error so 
> its a bit more obvious, maybe one for the Dev mailing list?
> 
> Edward
> 
> On Wed, Aug 14, 2019 at 3:12 PM Pierre Villard  > wrote:
> Glad you sorted it out and thanks for letting us know!
> In case you missed it, you might be interested by the NiFi toolkit [1] 
> containing a TLS toolkit to help you with certificates [2].
> 
> [1] https://nifi.apache.org/download.html 
> 
> [2] 
> https://nifi.apache.org/docs/nifi-docs/html/toolkit-guide.html#tls_toolkit 
> 
> Le mer. 14 août 2019 à 15:54, Nicolas Delsaux  > a écrit :
> Oh damn
> 
> It appeared (after a long search) that my keystore was incorrectly built.
> 
> Indeed, it contained the server certificate as a trusted certificate, where 
> it should had been a key pair (with both private and public keys in) as is 
> explained in Jetty documentation 
> (https://www.eclipse.org/jetty/documentation/9.4.19.v20190610/configuring-ssl.html#understanding-certificates-and-keys
>  
> 
>  - see part Layout of keystore and truststore). And this happened because I'm 
> really bad at certificates.
> 
> Sorry to have consumed some of your time, you all.
> 
> Le 13/08/2019 à 16:21, Nicolas Delsaux a écrit :
>> oh, sorry, I forgot to mention i use the nifi docker image, with 
>> configuration
>> 
>> services:
>>   nifi-runner:
>> hostname: nifi-psh.adeo.com 
>> image: apache/nifi:1.9.2
>> ports:
>>   - "38080:8443"
>>   - "5000:8000"
>> volumes:
>>   - 
>> ${project.basedir}/target/docker-compose/includes/nifi/node/conf:/opt/nifi/nifi-current/conf
>>   - 
>> ${project.basedir}/target/docker-compose/includes/nifi/node/cacerts.jks:/opt/certs/cacerts.jks
>>   - 
>> ${project.basedir}/target/docker-compose/includes/nifi/node/https_certificates.pkcs:/opt/certs/https_certificates.pkcs
>> 
>> And port 8443 is standard http port, I guess (the port 8000 is the standard 
>> debug one)
>> 
>> 
>> 
>> Le 13/08/2019 à 16:10, Pierre Villard a écrit :
>>> Might be a dumb question but I'm wondering why you're trying with port 
>>> 38080? Did you change the configuration to use that specific port with a 
>>> secured instance?
>>> 
>>> Pierre
>>> 
>>> Le mar. 13 août 2019 à 16:00, Nicolas Delsaux >> > a écrit :
>>> To go a little further, a test with openssl s_client gives the following
>>> 
>>> nicolas-delsaux@NICOLASDELSAUX C:\Users\nicolas-delsaux
>>> $ openssl s_client -host localhost -port 38080
>>> CONNECTED(0164)
>>> 416:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake
>>> failure:ssl\record\rec_layer_s3.c:1399:SSL alert number 40
>>> ---
>>> no peer certificate available
>>> ---
>>> No client certificate CA names sent
>>> ---
>>> SSL handshake has read 7 bytes and written 176 bytes
>>> Verification: OK
>>> ---
>>> New, (NONE), Cipher is (NONE)
>>> Secure Renegotiation IS NOT supported
>>> Compression: NONE
>>> Expansion: NONE
>>> No ALPN negotiated
>>> SSL-Session:
>>>  Protocol  : TLSv1.2
>>>  Cipher: 
>>>  Session-ID:
>>>  Session-ID-ctx:
>>>

Re: My nifi no more serve admin interface

2019-08-14 Thread Edward Armes 
Hmm, I wonder if there's a change that could be made to expose this error
so its a bit more obvious, maybe one for the Dev mailing list?

Edward

On Wed, Aug 14, 2019 at 3:12 PM Pierre Villard 
wrote:

> Glad you sorted it out and thanks for letting us know!
> In case you missed it, you might be interested by the NiFi toolkit [1]
> containing a TLS toolkit to help you with certificates [2].
>
> [1] https://nifi.apache.org/download.html
> [2]
> https://nifi.apache.org/docs/nifi-docs/html/toolkit-guide.html#tls_toolkit
>
> Le mer. 14 août 2019 à 15:54, Nicolas Delsaux  a
> écrit :
>
>> Oh damn
>>
>> It appeared (after a long search) that my keystore was incorrectly built.
>>
>> Indeed, it contained the server certificate as a trusted certificate,
>> where it should had been a key pair (with both private and public keys in)
>> as is explained in Jetty documentation (
>> https://www.eclipse.org/jetty/documentation/9.4.19.v20190610/configuring-ssl.html#understanding-certificates-and-keys
>> - see part Layout of keystore and truststore). And this happened because
>> I'm really bad at certificates.
>>
>> Sorry to have consumed some of your time, you all.
>> Le 13/08/2019 à 16:21, Nicolas Delsaux a écrit :
>>
>> oh, sorry, I forgot to mention i use the nifi docker image, with
>> configuration
>> services:
>> nifi-runner:
>> hostname: nifi-psh.adeo.com
>> image: apache/nifi:1.9.2
>> ports:
>> - "38080:8443"
>> - "5000:8000"
>> volumes:
>> -
>> ${project.basedir}/target/docker-compose/includes/nifi/node/conf:/opt/nifi/nifi-current/conf
>> -
>> ${project.basedir}/target/docker-compose/includes/nifi/node/cacerts.jks:/opt/certs/cacerts.jks
>> -
>> ${project.basedir}/target/docker-compose/includes/nifi/node/https_certificates.pkcs:/opt/certs/https_certificates.pkcs
>>
>> And port 8443 is standard http port, I guess (the port 8000 is the
>> standard debug one)
>>
>>
>> Le 13/08/2019 à 16:10, Pierre Villard a écrit :
>>
>> Might be a dumb question but I'm wondering why you're trying with port
>> 38080? Did you change the configuration to use that specific port with a
>> secured instance?
>>
>> Pierre
>>
>> Le mar. 13 août 2019 à 16:00, Nicolas Delsaux  a
>> écrit :
>>
>>> To go a little further, a test with openssl s_client gives the following
>>>
>>> nicolas-delsaux@NICOLASDELSAUX C:\Users\nicolas-delsaux
>>> $ openssl s_client -host localhost -port 38080
>>> CONNECTED(0164)
>>> 416:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake
>>> failure:ssl\record\rec_layer_s3.c:1399:SSL alert number 40
>>> ---
>>> no peer certificate available
>>> ---
>>> No client certificate CA names sent
>>> ---
>>> SSL handshake has read 7 bytes and written 176 bytes
>>> Verification: OK
>>> ---
>>> New, (NONE), Cipher is (NONE)
>>> Secure Renegotiation IS NOT supported
>>> Compression: NONE
>>> Expansion: NONE
>>> No ALPN negotiated
>>> SSL-Session:
>>>  Protocol  : TLSv1.2
>>>  Cipher: 
>>>  Session-ID:
>>>  Session-ID-ctx:
>>>  Master-Key:
>>>  PSK identity: None
>>>  PSK identity hint: None
>>>  SRP username: None
>>>  Start Time: 1565704262
>>>  Timeout   : 7200 (sec)
>>>  Verify return code: 0 (ok)
>>>  Extended master secret: no
>>> ---
>>>
>>>
>>> Which i weird considering nifi outputs in its startup log the lines
>>>
>>> nifi-runner_1  | 2019-08-13 13:37:52,315 INFO [main]
>>> o.e.jetty.server.handler.ContextHandler Started
>>> o.e.j.w.WebAppContext@7cb81ae{nifi-error,/,
>>> file:///opt/nifi/nifi-current/work/jetty/nifi-web-error-1.9.2.war/webapp/,AVAILABLE
>>> }{./work/nar/framework/nifi-framework-nar-1.9.2.nar-unpacked/NAR-INF/bundled-dependencies/nifi-web-error-1.9.2.war}
>>> nifi-runner_1  | 2019-08-13 13:37:52,490 INFO [main]
>>> o.e.jetty.util.ssl.SslContextFactory
>>> x509=X509@3d94d7f3(nifi-psh.adeo.com (adeo
>>> ca),h=[nifi-psh.adeo.com],w=[]) for
>>> SslContextFactory@da1abd6[provider=null,keyStore=
>>> file:///opt/certs/https_certificates.pkcs,trustStore=file:///opt/certs/cacerts.jks
>>> ]
>>> nifi-runner_1  | 2019-08-13 13:37:52,510 INFO [main]
>>> o.eclipse.jetty.server.AbstractConnector Started
>>> ServerConnector@2066f0d3{SSL,[ssl, http/1.1]}{0.0.0.0:8443}
>>>
>>>
>>> which seems to indicate Jetty is able to listen for https connections on
>>> port 8443 using certificates described in SslContextFactory. No ?
>>>
>>> Le 13/08/2019 à 15:40, Nicolas Delsaux a écrit :
>>> > I'm currently trying to implement ldap user group authorization in
>>> nifi.
>>> >
>>> > For that, I've deployed nifi docker image with configuration files
>>> > containing required config elements (a ldap identity provider, a ldap
>>> > user group provider).
>>> >
>>> > I've also configured https with a keystore/truststore that are injected
>>> > into docker container through volumes.
>>> >
>>> > Once all is configured, i've taken the time to do some debug session to
>>> > make sure tue FileAccessPolicyProvider correctly loads my user from
>>> > ldap, and it works ok.
>>> >

Re: My nifi no more serve admin interface

2019-08-14 Thread Pierre Villard 
Glad you sorted it out and thanks for letting us know!
In case you missed it, you might be interested by the NiFi toolkit [1]
containing a TLS toolkit to help you with certificates [2].

[1] https://nifi.apache.org/download.html
[2]
https://nifi.apache.org/docs/nifi-docs/html/toolkit-guide.html#tls_toolkit

Le mer. 14 août 2019 à 15:54, Nicolas Delsaux  a
écrit :

> Oh damn
>
> It appeared (after a long search) that my keystore was incorrectly built.
>
> Indeed, it contained the server certificate as a trusted certificate,
> where it should had been a key pair (with both private and public keys in)
> as is explained in Jetty documentation (
> https://www.eclipse.org/jetty/documentation/9.4.19.v20190610/configuring-ssl.html#understanding-certificates-and-keys
> - see part Layout of keystore and truststore). And this happened because
> I'm really bad at certificates.
>
> Sorry to have consumed some of your time, you all.
> Le 13/08/2019 à 16:21, Nicolas Delsaux a écrit :
>
> oh, sorry, I forgot to mention i use the nifi docker image, with
> configuration
> services:
> nifi-runner:
> hostname: nifi-psh.adeo.com
> image: apache/nifi:1.9.2
> ports:
> - "38080:8443"
> - "5000:8000"
> volumes:
> -
> ${project.basedir}/target/docker-compose/includes/nifi/node/conf:/opt/nifi/nifi-current/conf
> -
> ${project.basedir}/target/docker-compose/includes/nifi/node/cacerts.jks:/opt/certs/cacerts.jks
> -
> ${project.basedir}/target/docker-compose/includes/nifi/node/https_certificates.pkcs:/opt/certs/https_certificates.pkcs
>
> And port 8443 is standard http port, I guess (the port 8000 is the
> standard debug one)
>
>
> Le 13/08/2019 à 16:10, Pierre Villard a écrit :
>
> Might be a dumb question but I'm wondering why you're trying with port
> 38080? Did you change the configuration to use that specific port with a
> secured instance?
>
> Pierre
>
> Le mar. 13 août 2019 à 16:00, Nicolas Delsaux  a
> écrit :
>
>> To go a little further, a test with openssl s_client gives the following
>>
>> nicolas-delsaux@NICOLASDELSAUX C:\Users\nicolas-delsaux
>> $ openssl s_client -host localhost -port 38080
>> CONNECTED(0164)
>> 416:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake
>> failure:ssl\record\rec_layer_s3.c:1399:SSL alert number 40
>> ---
>> no peer certificate available
>> ---
>> No client certificate CA names sent
>> ---
>> SSL handshake has read 7 bytes and written 176 bytes
>> Verification: OK
>> ---
>> New, (NONE), Cipher is (NONE)
>> Secure Renegotiation IS NOT supported
>> Compression: NONE
>> Expansion: NONE
>> No ALPN negotiated
>> SSL-Session:
>>  Protocol  : TLSv1.2
>>  Cipher: 
>>  Session-ID:
>>  Session-ID-ctx:
>>  Master-Key:
>>  PSK identity: None
>>  PSK identity hint: None
>>  SRP username: None
>>  Start Time: 1565704262
>>  Timeout   : 7200 (sec)
>>  Verify return code: 0 (ok)
>>  Extended master secret: no
>> ---
>>
>>
>> Which i weird considering nifi outputs in its startup log the lines
>>
>> nifi-runner_1  | 2019-08-13 13:37:52,315 INFO [main]
>> o.e.jetty.server.handler.ContextHandler Started
>> o.e.j.w.WebAppContext@7cb81ae{nifi-error,/,
>> file:///opt/nifi/nifi-current/work/jetty/nifi-web-error-1.9.2.war/webapp/,AVAILABLE
>> }{./work/nar/framework/nifi-framework-nar-1.9.2.nar-unpacked/NAR-INF/bundled-dependencies/nifi-web-error-1.9.2.war}
>> nifi-runner_1  | 2019-08-13 13:37:52,490 INFO [main]
>> o.e.jetty.util.ssl.SslContextFactory
>> x509=X509@3d94d7f3(nifi-psh.adeo.com (adeo
>> ca),h=[nifi-psh.adeo.com],w=[]) for
>> SslContextFactory@da1abd6[provider=null,keyStore=
>> file:///opt/certs/https_certificates.pkcs,trustStore=file:///opt/certs/cacerts.jks
>> ]
>> nifi-runner_1  | 2019-08-13 13:37:52,510 INFO [main]
>> o.eclipse.jetty.server.AbstractConnector Started
>> ServerConnector@2066f0d3{SSL,[ssl, http/1.1]}{0.0.0.0:8443}
>>
>>
>> which seems to indicate Jetty is able to listen for https connections on
>> port 8443 using certificates described in SslContextFactory. No ?
>>
>> Le 13/08/2019 à 15:40, Nicolas Delsaux a écrit :
>> > I'm currently trying to implement ldap user group authorization in nifi.
>> >
>> > For that, I've deployed nifi docker image with configuration files
>> > containing required config elements (a ldap identity provider, a ldap
>> > user group provider).
>> >
>> > I've also configured https with a keystore/truststore that are injected
>> > into docker container through volumes.
>> >
>> > Once all is configured, i've taken the time to do some debug session to
>> > make sure tue FileAccessPolicyProvider correctly loads my user from
>> > ldap, and it works ok.
>> >
>> > Unfortunatly, now, when i try to load Nifi admin interface, I get a
>> > strange http response containing only the string "   �  P".
>> >
>> > In other words,
>> >
>> >
>> > nicolas-delsaux@NICOLASDELSAUX C:\Users\nicolas-delsaux
>> > $ curl -v -H "Host: nifi-psh.adeo.com" http://localhost:38080/
>> --output -
>> > *   Trying ::1...
>> >

Re: My nifi no more serve admin interface

2019-08-14 Thread Nicolas Delsaux 

Oh damn

It appeared (after a long search) that my keystore was incorrectly built.

Indeed, it contained the server certificate as a trusted certificate,
where it should had been a key pair (with both private and public keys
in) as is explained in Jetty documentation
(https://www.eclipse.org/jetty/documentation/9.4.19.v20190610/configuring-ssl.html#understanding-certificates-and-keys
- see part Layout of keystore and truststore). And this happened because
I'm really bad at certificates.

Sorry to have consumed some of your time, you all.

Le 13/08/2019 à 16:21, Nicolas Delsaux a écrit :


oh, sorry, I forgot to mention i use the nifi docker image, with
configuration

services:
nifi-runner:
hostname: nifi-psh.adeo.com
image: apache/nifi:1.9.2
ports:
- "38080:8443"
- "5000:8000"
volumes:
-
${project.basedir}/target/docker-compose/includes/nifi/node/conf:/opt/nifi/nifi-current/conf
-
${project.basedir}/target/docker-compose/includes/nifi/node/cacerts.jks:/opt/certs/cacerts.jks
-
${project.basedir}/target/docker-compose/includes/nifi/node/https_certificates.pkcs:/opt/certs/https_certificates.pkcs

And port 8443 is standard http port, I guess (the port 8000 is the
standard debug one)


Le 13/08/2019 à 16:10, Pierre Villard a écrit :

Might be a dumb question but I'm wondering why you're trying with
port 38080? Did you change the configuration to use that specific
port with a secured instance?

Pierre

Le mar. 13 août 2019 à 16:00, Nicolas Delsaux mailto:nicolas.dels...@gmx.fr>> a écrit :

To go a little further, a test with openssl s_client gives the
following

nicolas-delsaux@NICOLASDELSAUX C:\Users\nicolas-delsaux
$ openssl s_client -host localhost -port 38080
CONNECTED(0164)
416:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake
failure:ssl\record\rec_layer_s3.c:1399:SSL alert number 40
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 176 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
 Protocol  : TLSv1.2
 Cipher    : 
 Session-ID:
 Session-ID-ctx:
 Master-Key:
 PSK identity: None
 PSK identity hint: None
 SRP username: None
 Start Time: 1565704262
 Timeout   : 7200 (sec)
 Verify return code: 0 (ok)
 Extended master secret: no
---


Which i weird considering nifi outputs in its startup log the lines

nifi-runner_1  | 2019-08-13 13:37:52,315 INFO [main]
o.e.jetty.server.handler.ContextHandler Started

o.e.j.w.WebAppContext@7cb81ae{nifi-error,/,file:///opt/nifi/nifi-current/work/jetty/nifi-web-error-1.9.2.war/webapp/,AVAILABLE}{./work/nar/framework/nifi-framework-nar-1.9.2.nar-unpacked/NAR-INF/bundled-dependencies/nifi-web-error-1.9.2.war}
nifi-runner_1  | 2019-08-13 13:37:52,490 INFO [main]
o.e.jetty.util.ssl.SslContextFactory
x509=X509@3d94d7f3(nifi-psh.adeo.com  (adeo
ca),h=[nifi-psh.adeo.com ],w=[]) for

SslContextFactory@da1abd6[provider=null,keyStore=file:///opt/certs/https_certificates.pkcs,trustStore=file:///opt/certs/cacerts.jks]
nifi-runner_1  | 2019-08-13 13:37:52,510 INFO [main]
o.eclipse.jetty.server.AbstractConnector Started
ServerConnector@2066f0d3{SSL,[ssl, http/1.1]}{0.0.0.0:8443
}


which seems to indicate Jetty is able to listen for https
connections on
port 8443 using certificates described in SslContextFactory. No ?

Le 13/08/2019 à 15:40, Nicolas Delsaux a écrit :
> I'm currently trying to implement ldap user group authorization
in nifi.
>
> For that, I've deployed nifi docker image with configuration files
> containing required config elements (a ldap identity provider,
a ldap
> user group provider).
>
> I've also configured https with a keystore/truststore that are
injected
> into docker container through volumes.
>
> Once all is configured, i've taken the time to do some debug
session to
> make sure tue FileAccessPolicyProvider correctly loads my user from
> ldap, and it works ok.
>
> Unfortunatly, now, when i try to load Nifi admin interface, I get a
> strange http response containing only the string "   � P".
>
> In other words,
>
>
> nicolas-delsaux@NICOLASDELSAUX C:\Users\nicolas-delsaux
> $ curl -v -H "Host: nifi-psh.adeo.com
" http://localhost:38080/ --output -
> *   Trying ::1...
> * TCP_NODELAY set
> * Connected to localhost (::1) port 38080 (#0)
> > GET / HTTP/1.1
> > Host: nifi-psh.adeo.com 
> > User-Agent: curl/7.55.1
> > Accept: */*
> >
> §♥♥ ☻☻P* Connection

Re: My nifi no more serve admin interface

2019-08-14 Thread Edward Armes 
Hi Nicolas,

This is another dump question. As I've only ever seen this before when I've
accidentally connect to a secured Nifi cluster over HTTP and not HTTPS.
>From I've seen Nifi won't ask your browser to do a connection upgrade (HTTP
-> HTTPS),

When you type in the address are you sure your browser is not cutting of
the *s* from the *https* in the URL you entering?

Edward

On Tue, Aug 13, 2019 at 3:22 PM Nicolas Delsaux 
wrote:

> oh, sorry, I forgot to mention i use the nifi docker image, with
> configuration
> services:
> nifi-runner:
> hostname: nifi-psh.adeo.com
> image: apache/nifi:1.9.2
> ports:
> - "38080:8443"
> - "5000:8000"
> volumes:
> -
> ${project.basedir}/target/docker-compose/includes/nifi/node/conf:/opt/nifi/nifi-current/conf
> -
> ${project.basedir}/target/docker-compose/includes/nifi/node/cacerts.jks:/opt/certs/cacerts.jks
> -
> ${project.basedir}/target/docker-compose/includes/nifi/node/https_certificates.pkcs:/opt/certs/https_certificates.pkcs
>
> And port 8443 is standard http port, I guess (the port 8000 is the
> standard debug one)
>
>
> Le 13/08/2019 à 16:10, Pierre Villard a écrit :
>
> Might be a dumb question but I'm wondering why you're trying with port
> 38080? Did you change the configuration to use that specific port with a
> secured instance?
>
> Pierre
>
> Le mar. 13 août 2019 à 16:00, Nicolas Delsaux  a
> écrit :
>
>> To go a little further, a test with openssl s_client gives the following
>>
>> nicolas-delsaux@NICOLASDELSAUX C:\Users\nicolas-delsaux
>> $ openssl s_client -host localhost -port 38080
>> CONNECTED(0164)
>> 416:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake
>> failure:ssl\record\rec_layer_s3.c:1399:SSL alert number 40
>> ---
>> no peer certificate available
>> ---
>> No client certificate CA names sent
>> ---
>> SSL handshake has read 7 bytes and written 176 bytes
>> Verification: OK
>> ---
>> New, (NONE), Cipher is (NONE)
>> Secure Renegotiation IS NOT supported
>> Compression: NONE
>> Expansion: NONE
>> No ALPN negotiated
>> SSL-Session:
>>  Protocol  : TLSv1.2
>>  Cipher: 
>>  Session-ID:
>>  Session-ID-ctx:
>>  Master-Key:
>>  PSK identity: None
>>  PSK identity hint: None
>>  SRP username: None
>>  Start Time: 1565704262
>>  Timeout   : 7200 (sec)
>>  Verify return code: 0 (ok)
>>  Extended master secret: no
>> ---
>>
>>
>> Which i weird considering nifi outputs in its startup log the lines
>>
>> nifi-runner_1  | 2019-08-13 13:37:52,315 INFO [main]
>> o.e.jetty.server.handler.ContextHandler Started
>> o.e.j.w.WebAppContext@7cb81ae{nifi-error,/,
>> file:///opt/nifi/nifi-current/work/jetty/nifi-web-error-1.9.2.war/webapp/,AVAILABLE
>> }{./work/nar/framework/nifi-framework-nar-1.9.2.nar-unpacked/NAR-INF/bundled-dependencies/nifi-web-error-1.9.2.war}
>> nifi-runner_1  | 2019-08-13 13:37:52,490 INFO [main]
>> o.e.jetty.util.ssl.SslContextFactory
>> x509=X509@3d94d7f3(nifi-psh.adeo.com (adeo
>> ca),h=[nifi-psh.adeo.com],w=[]) for
>> SslContextFactory@da1abd6[provider=null,keyStore=
>> file:///opt/certs/https_certificates.pkcs,trustStore=file:///opt/certs/cacerts.jks
>> ]
>> nifi-runner_1  | 2019-08-13 13:37:52,510 INFO [main]
>> o.eclipse.jetty.server.AbstractConnector Started
>> ServerConnector@2066f0d3{SSL,[ssl, http/1.1]}{0.0.0.0:8443}
>>
>>
>> which seems to indicate Jetty is able to listen for https connections on
>> port 8443 using certificates described in SslContextFactory. No ?
>>
>> Le 13/08/2019 à 15:40, Nicolas Delsaux a écrit :
>> > I'm currently trying to implement ldap user group authorization in nifi.
>> >
>> > For that, I've deployed nifi docker image with configuration files
>> > containing required config elements (a ldap identity provider, a ldap
>> > user group provider).
>> >
>> > I've also configured https with a keystore/truststore that are injected
>> > into docker container through volumes.
>> >
>> > Once all is configured, i've taken the time to do some debug session to
>> > make sure tue FileAccessPolicyProvider correctly loads my user from
>> > ldap, and it works ok.
>> >
>> > Unfortunatly, now, when i try to load Nifi admin interface, I get a
>> > strange http response containing only the string "   �  P".
>> >
>> > In other words,
>> >
>> >
>> > nicolas-delsaux@NICOLASDELSAUX C:\Users\nicolas-delsaux
>> > $ curl -v -H "Host: nifi-psh.adeo.com" http://localhost:38080/
>> --output -
>> > *   Trying ::1...
>> > * TCP_NODELAY set
>> > * Connected to localhost (::1) port 38080 (#0)
>> > > GET / HTTP/1.1
>> > > Host: nifi-psh.adeo.com
>> > > User-Agent: curl/7.55.1
>> > > Accept: */*
>> > >
>> > §♥♥ ☻☻P* Connection #0 to host localhost left intact
>> >
>> >
>> > http does not work (which i expects, since I've configured
>> > authentication/authorization
>> >
>> > nicolas-delsaux@NICOLASDELSAUX C:\Users\nicolas-delsaux
>> > $ curl -v -H "Host: nifi-psh.adeo.com" https://localhost:38080/
>> > --output -
>> > *   Trying ::1...
>> > * TCP_NODELAY set
>> >

Re: My nifi no more serve admin interface

2019-08-13 Thread Nicolas Delsaux 

oh, sorry, I forgot to mention i use the nifi docker image, with
configuration

services:
nifi-runner:
hostname: nifi-psh.adeo.com
image: apache/nifi:1.9.2
ports:
- "38080:8443"
- "5000:8000"
volumes:
-
${project.basedir}/target/docker-compose/includes/nifi/node/conf:/opt/nifi/nifi-current/conf
-
${project.basedir}/target/docker-compose/includes/nifi/node/cacerts.jks:/opt/certs/cacerts.jks
-
${project.basedir}/target/docker-compose/includes/nifi/node/https_certificates.pkcs:/opt/certs/https_certificates.pkcs

And port 8443 is standard http port, I guess (the port 8000 is the
standard debug one)


Le 13/08/2019 à 16:10, Pierre Villard a écrit :

Might be a dumb question but I'm wondering why you're trying with port
38080? Did you change the configuration to use that specific port with
a secured instance?

Pierre

Le mar. 13 août 2019 à 16:00, Nicolas Delsaux mailto:nicolas.dels...@gmx.fr>> a écrit :

To go a little further, a test with openssl s_client gives the
following

nicolas-delsaux@NICOLASDELSAUX C:\Users\nicolas-delsaux
$ openssl s_client -host localhost -port 38080
CONNECTED(0164)
416:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake
failure:ssl\record\rec_layer_s3.c:1399:SSL alert number 40
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 176 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
 Protocol  : TLSv1.2
 Cipher    : 
 Session-ID:
 Session-ID-ctx:
 Master-Key:
 PSK identity: None
 PSK identity hint: None
 SRP username: None
 Start Time: 1565704262
 Timeout   : 7200 (sec)
 Verify return code: 0 (ok)
 Extended master secret: no
---


Which i weird considering nifi outputs in its startup log the lines

nifi-runner_1  | 2019-08-13 13:37:52,315 INFO [main]
o.e.jetty.server.handler.ContextHandler Started

o.e.j.w.WebAppContext@7cb81ae{nifi-error,/,file:///opt/nifi/nifi-current/work/jetty/nifi-web-error-1.9.2.war/webapp/,AVAILABLE}{./work/nar/framework/nifi-framework-nar-1.9.2.nar-unpacked/NAR-INF/bundled-dependencies/nifi-web-error-1.9.2.war}
nifi-runner_1  | 2019-08-13 13:37:52,490 INFO [main]
o.e.jetty.util.ssl.SslContextFactory
x509=X509@3d94d7f3(nifi-psh.adeo.com  (adeo
ca),h=[nifi-psh.adeo.com ],w=[]) for

SslContextFactory@da1abd6[provider=null,keyStore=file:///opt/certs/https_certificates.pkcs,trustStore=file:///opt/certs/cacerts.jks]
nifi-runner_1  | 2019-08-13 13:37:52,510 INFO [main]
o.eclipse.jetty.server.AbstractConnector Started
ServerConnector@2066f0d3{SSL,[ssl, http/1.1]}{0.0.0.0:8443
}


which seems to indicate Jetty is able to listen for https
connections on
port 8443 using certificates described in SslContextFactory. No ?

Le 13/08/2019 à 15:40, Nicolas Delsaux a écrit :
> I'm currently trying to implement ldap user group authorization
in nifi.
>
> For that, I've deployed nifi docker image with configuration files
> containing required config elements (a ldap identity provider, a
ldap
> user group provider).
>
> I've also configured https with a keystore/truststore that are
injected
> into docker container through volumes.
>
> Once all is configured, i've taken the time to do some debug
session to
> make sure tue FileAccessPolicyProvider correctly loads my user from
> ldap, and it works ok.
>
> Unfortunatly, now, when i try to load Nifi admin interface, I get a
> strange http response containing only the string "   � P".
>
> In other words,
>
>
> nicolas-delsaux@NICOLASDELSAUX C:\Users\nicolas-delsaux
> $ curl -v -H "Host: nifi-psh.adeo.com
" http://localhost:38080/ --output -
> *   Trying ::1...
> * TCP_NODELAY set
> * Connected to localhost (::1) port 38080 (#0)
> > GET / HTTP/1.1
> > Host: nifi-psh.adeo.com 
> > User-Agent: curl/7.55.1
> > Accept: */*
> >
> §♥♥ ☻☻P* Connection #0 to host localhost left intact
>
>
> http does not work (which i expects, since I've configured
> authentication/authorization
>
> nicolas-delsaux@NICOLASDELSAUX C:\Users\nicolas-delsaux
> $ curl -v -H "Host: nifi-psh.adeo.com
" https://localhost:38080/
> --output -
> *   Trying ::1...
> * TCP_NODELAY set
> * Connected to localhost (::1) port 38080 (#0)
> * schannel: SSL/TLS connection with localhost port 38080 (step 1/3)
> * schannel: checking server certificate revocation
> * schannel: sending initial

Re: My nifi no more serve admin interface

2019-08-13 Thread Pierre Villard 
Might be a dumb question but I'm wondering why you're trying with port
38080? Did you change the configuration to use that specific port with a
secured instance?

Pierre

Le mar. 13 août 2019 à 16:00, Nicolas Delsaux  a
écrit :

> To go a little further, a test with openssl s_client gives the following
>
> nicolas-delsaux@NICOLASDELSAUX C:\Users\nicolas-delsaux
> $ openssl s_client -host localhost -port 38080
> CONNECTED(0164)
> 416:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake
> failure:ssl\record\rec_layer_s3.c:1399:SSL alert number 40
> ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 7 bytes and written 176 bytes
> Verification: OK
> ---
> New, (NONE), Cipher is (NONE)
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> SSL-Session:
>  Protocol  : TLSv1.2
>  Cipher: 
>  Session-ID:
>  Session-ID-ctx:
>  Master-Key:
>  PSK identity: None
>  PSK identity hint: None
>  SRP username: None
>  Start Time: 1565704262
>  Timeout   : 7200 (sec)
>  Verify return code: 0 (ok)
>  Extended master secret: no
> ---
>
>
> Which i weird considering nifi outputs in its startup log the lines
>
> nifi-runner_1  | 2019-08-13 13:37:52,315 INFO [main]
> o.e.jetty.server.handler.ContextHandler Started
> o.e.j.w.WebAppContext@7cb81ae
> {nifi-error,/,file:///opt/nifi/nifi-current/work/jetty/nifi-web-error-1.9.2.war/webapp/,AVAILABLE}{./work/nar/framework/nifi-framework-nar-1.9.2.nar-unpacked/NAR-INF/bundled-dependencies/nifi-web-error-1.9.2.war}
> nifi-runner_1  | 2019-08-13 13:37:52,490 INFO [main]
> o.e.jetty.util.ssl.SslContextFactory
> x509=X509@3d94d7f3(nifi-psh.adeo.com (adeo
> ca),h=[nifi-psh.adeo.com],w=[]) for
> SslContextFactory@da1abd6
> [provider=null,keyStore=file:///opt/certs/https_certificates.pkcs,trustStore=file:///opt/certs/cacerts.jks]
> nifi-runner_1  | 2019-08-13 13:37:52,510 INFO [main]
> o.eclipse.jetty.server.AbstractConnector Started
> ServerConnector@2066f0d3{SSL,[ssl, http/1.1]}{0.0.0.0:8443}
>
>
> which seems to indicate Jetty is able to listen for https connections on
> port 8443 using certificates described in SslContextFactory. No ?
>
> Le 13/08/2019 à 15:40, Nicolas Delsaux a écrit :
> > I'm currently trying to implement ldap user group authorization in nifi.
> >
> > For that, I've deployed nifi docker image with configuration files
> > containing required config elements (a ldap identity provider, a ldap
> > user group provider).
> >
> > I've also configured https with a keystore/truststore that are injected
> > into docker container through volumes.
> >
> > Once all is configured, i've taken the time to do some debug session to
> > make sure tue FileAccessPolicyProvider correctly loads my user from
> > ldap, and it works ok.
> >
> > Unfortunatly, now, when i try to load Nifi admin interface, I get a
> > strange http response containing only the string "   �  P".
> >
> > In other words,
> >
> >
> > nicolas-delsaux@NICOLASDELSAUX C:\Users\nicolas-delsaux
> > $ curl -v -H "Host: nifi-psh.adeo.com" http://localhost:38080/ --output
> -
> > *   Trying ::1...
> > * TCP_NODELAY set
> > * Connected to localhost (::1) port 38080 (#0)
> > > GET / HTTP/1.1
> > > Host: nifi-psh.adeo.com
> > > User-Agent: curl/7.55.1
> > > Accept: */*
> > >
> > §♥♥ ☻☻P* Connection #0 to host localhost left intact
> >
> >
> > http does not work (which i expects, since I've configured
> > authentication/authorization
> >
> > nicolas-delsaux@NICOLASDELSAUX C:\Users\nicolas-delsaux
> > $ curl -v -H "Host: nifi-psh.adeo.com" https://localhost:38080/
> > --output -
> > *   Trying ::1...
> > * TCP_NODELAY set
> > * Connected to localhost (::1) port 38080 (#0)
> > * schannel: SSL/TLS connection with localhost port 38080 (step 1/3)
> > * schannel: checking server certificate revocation
> > * schannel: sending initial handshake data: sending 174 bytes...
> > * schannel: sent initial handshake data: sent 174 bytes
> > * schannel: SSL/TLS connection with localhost port 38080 (step 2/3)
> > * schannel: encrypted data got 7
> > * schannel: encrypted data buffer: offset 7 length 4096
> > * schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE
> > (0x80090326) - This error usually occurs when a fatal SSL/TLS alert is
> > received (e.g. handshake failed). More detail may be available in the
> > Windows System event log.
> > * Closing connection 0
> > * schannel: shutting down SSL/TLS connection with localhost port 38080
> > * schannel: clear security context handle
> > curl: (35) schannel: next InitializeSecurityContext failed:
> > SEC_E_ILLEGAL_MESSAGE (0x80090326) - This error usually occurs when a
> > fatal SSL/TLS alert is received (e.g. handshake failed). More detail may
> > be available in the Windows System event log.
> >
> > But neither is https
> >
> > I guess there is something wrong with certificate, but the log doesn't
> >

Re: My nifi no more serve admin interface

2019-08-13 Thread Nicolas Delsaux 

To go a little further, a test with openssl s_client gives the following

nicolas-delsaux@NICOLASDELSAUX C:\Users\nicolas-delsaux
$ openssl s_client -host localhost -port 38080
CONNECTED(0164)
416:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake
failure:ssl\record\rec_layer_s3.c:1399:SSL alert number 40
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 176 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1565704262
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---


Which i weird considering nifi outputs in its startup log the lines

nifi-runner_1  | 2019-08-13 13:37:52,315 INFO [main]
o.e.jetty.server.handler.ContextHandler Started
o.e.j.w.WebAppContext@7cb81ae{nifi-error,/,file:///opt/nifi/nifi-current/work/jetty/nifi-web-error-1.9.2.war/webapp/,AVAILABLE}{./work/nar/framework/nifi-framework-nar-1.9.2.nar-unpacked/NAR-INF/bundled-dependencies/nifi-web-error-1.9.2.war}
nifi-runner_1  | 2019-08-13 13:37:52,490 INFO [main]
o.e.jetty.util.ssl.SslContextFactory
x509=X509@3d94d7f3(nifi-psh.adeo.com (adeo
ca),h=[nifi-psh.adeo.com],w=[]) for
SslContextFactory@da1abd6[provider=null,keyStore=file:///opt/certs/https_certificates.pkcs,trustStore=file:///opt/certs/cacerts.jks]
nifi-runner_1  | 2019-08-13 13:37:52,510 INFO [main]
o.eclipse.jetty.server.AbstractConnector Started
ServerConnector@2066f0d3{SSL,[ssl, http/1.1]}{0.0.0.0:8443}


which seems to indicate Jetty is able to listen for https connections on
port 8443 using certificates described in SslContextFactory. No ?

Le 13/08/2019 à 15:40, Nicolas Delsaux a écrit :

I'm currently trying to implement ldap user group authorization in nifi.

For that, I've deployed nifi docker image with configuration files
containing required config elements (a ldap identity provider, a ldap
user group provider).

I've also configured https with a keystore/truststore that are injected
into docker container through volumes.

Once all is configured, i've taken the time to do some debug session to
make sure tue FileAccessPolicyProvider correctly loads my user from
ldap, and it works ok.

Unfortunatly, now, when i try to load Nifi admin interface, I get a
strange http response containing only the string "�P".

In other words,


nicolas-delsaux@NICOLASDELSAUX C:\Users\nicolas-delsaux
$ curl -v -H "Host: nifi-psh.adeo.com" http://localhost:38080/ --output -
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 38080 (#0)
> GET / HTTP/1.1
> Host: nifi-psh.adeo.com
> User-Agent: curl/7.55.1
> Accept: */*
>
§♥♥ ☻☻P* Connection #0 to host localhost left intact


http does not work (which i expects, since I've configured
authentication/authorization

nicolas-delsaux@NICOLASDELSAUX C:\Users\nicolas-delsaux
$ curl -v -H "Host: nifi-psh.adeo.com" https://localhost:38080/
--output -
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 38080 (#0)
* schannel: SSL/TLS connection with localhost port 38080 (step 1/3)
* schannel: checking server certificate revocation
* schannel: sending initial handshake data: sending 174 bytes...
* schannel: sent initial handshake data: sent 174 bytes
* schannel: SSL/TLS connection with localhost port 38080 (step 2/3)
* schannel: encrypted data got 7
* schannel: encrypted data buffer: offset 7 length 4096
* schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE
(0x80090326) - This error usually occurs when a fatal SSL/TLS alert is
received (e.g. handshake failed). More detail may be available in the
Windows System event log.
* Closing connection 0
* schannel: shutting down SSL/TLS connection with localhost port 38080
* schannel: clear security context handle
curl: (35) schannel: next InitializeSecurityContext failed:
SEC_E_ILLEGAL_MESSAGE (0x80090326) - This error usually occurs when a
fatal SSL/TLS alert is received (e.g. handshake failed). More detail may
be available in the Windows System event log.

But neither is https

I guess there is something wrong with certificate, but the log doesn't
seems to indicate any certificate misconfiguration.


What have i done wrong ?

My nifi no more serve admin interface

2019-08-13 Thread Nicolas Delsaux 

I'm currently trying to implement ldap user group authorization in nifi.

For that, I've deployed nifi docker image with configuration files
containing required config elements (a ldap identity provider, a ldap
user group provider).

I've also configured https with a keystore/truststore that are injected
into docker container through volumes.

Once all is configured, i've taken the time to do some debug session to
make sure tue FileAccessPolicyProvider correctly loads my user from
ldap, and it works ok.

Unfortunatly, now, when i try to load Nifi admin interface, I get a
strange http response containing only the string "�P".

In other words,


nicolas-delsaux@NICOLASDELSAUX C:\Users\nicolas-delsaux
$ curl -v -H "Host: nifi-psh.adeo.com" http://localhost:38080/ --output -
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 38080 (#0)
> GET / HTTP/1.1
> Host: nifi-psh.adeo.com
> User-Agent: curl/7.55.1
> Accept: */*
>
§♥♥ ☻☻P* Connection #0 to host localhost left intact


http does not work (which i expects, since I've configured
authentication/authorization

nicolas-delsaux@NICOLASDELSAUX C:\Users\nicolas-delsaux
$ curl -v -H "Host: nifi-psh.adeo.com" https://localhost:38080/ --output -
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 38080 (#0)
* schannel: SSL/TLS connection with localhost port 38080 (step 1/3)
* schannel: checking server certificate revocation
* schannel: sending initial handshake data: sending 174 bytes...
* schannel: sent initial handshake data: sent 174 bytes
* schannel: SSL/TLS connection with localhost port 38080 (step 2/3)
* schannel: encrypted data got 7
* schannel: encrypted data buffer: offset 7 length 4096
* schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE
(0x80090326) - This error usually occurs when a fatal SSL/TLS alert is
received (e.g. handshake failed). More detail may be available in the
Windows System event log.
* Closing connection 0
* schannel: shutting down SSL/TLS connection with localhost port 38080
* schannel: clear security context handle
curl: (35) schannel: next InitializeSecurityContext failed:
SEC_E_ILLEGAL_MESSAGE (0x80090326) - This error usually occurs when a
fatal SSL/TLS alert is received (e.g. handshake failed). More detail may
be available in the Windows System event log.

But neither is https

I guess there is something wrong with certificate, but the log doesn't
seems to indicate any certificate misconfiguration.


What have i done wrong ?