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 [email protected] [email protected] PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Aug 14, 2019, at 7:31 AM, Edward Armes <[email protected]> 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 <[email protected] > <mailto:[email protected]>> 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 > <https://nifi.apache.org/download.html> > [2] > https://nifi.apache.org/docs/nifi-docs/html/toolkit-guide.html#tls_toolkit > <https://nifi.apache.org/docs/nifi-docs/html/toolkit-guide.html#tls_toolkit> > Le mer. 14 août 2019 à 15:54, Nicolas Delsaux <[email protected] > <mailto:[email protected]>> 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 > > <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 <http://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 <[email protected] >>> <mailto:[email protected]>> 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 <http://nifi-psh.adeo.com/> (adeo >>> ca),h=[nifi-psh.adeo.com <http://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 >>> <http://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://nifi-psh.adeo.com/>" >>> > http://localhost:38080/ <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 <http://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 <http://nifi-psh.adeo.com/>" >>> > https://localhost:38080/ <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 ? >>> > >>> >
