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 <pierre.villard...@gmail.com> 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 <nicolas.dels...@gmx.fr> 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 <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(00000164) >>> 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 : 0000 >>> 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 ? >>> > >>> > >>> >>
