I am not sure if this is a NiFi dev or NiFi user question. Seems more dev based
Short Version: When running the NiFi toolkit ../bin/tls-toolkit.sh server, how do I get the server to include an additional public certificate of authority in the returned truststore.jks file (../bin/tls-toolkit.sh client calls) Long version: When running tls-toolkit.sh as the CA for NiFi instances ../bin/tls-toolkit.sh server -D "CN=nifi-ca.blah.blah.bloomberg.com, OU=NIFI" -t mysupersecrettoken-p 8443 -d 1826 And I call the CA to request a /bb/nifi-toolkit/nifi-toolkit-1.7.1/bin/tls-toolkit.sh client -c nifi-ca.blah.com -t mysupersecrettoken-p 8443 -D "CN=nifi-myproject.blah.blah.bloomberg.com, OU=NIFI, O=Bloomberg L.P., L=New York, ST=New York, C=US" The toolkit gives me a keystore.jks I need to get this certificate signed by an external entity so I dont have issues with the browsers. Basically I do keytool -certreq -alias nifi-key -file csr.txt -keystore keystore.jks I the the certificate signing request, csr.txt, I feed it to the public certificate of authority, I get a signed certificate back. I convert the format of the certificate like so openssl x509 -outform der -in new_cert.pem -out new_cert.crt Now I import the certificate back into my keystore. keytool -import -alias nifi-key -file new_cert.crt -keystore keystore.jks Now I have solved the certificate warning errors in the browser when I connect to the NiFi UI. ------------ Now I want to use the NiFi cli to to automate data flows between the registry and the NiFi instances so I generate a client cert 2) ../bin/tls-toolkit.sh client -c nifi-ca.blah.blah.bloomberg.com -t mysupersecrettoken-p 8443 -D "CN=nifi-cli, OU=NIFI" -T PKCS12 I setup nifi.prop, I also add "CN=nifi-cli, OU=NIFI" as a user to the NiFi UI Now I call the NiFi instane as so ../bin/cli.sh nifi pg-list -verbose -p /bb/nifi-toolkit/nifi-toolkit-1.7.1/nifi.prop And I get this error org.apache.nifi.toolkit.cli.api.CommandException: Error executing command 'pg-list' : sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target *** BTW, this error message and it gives you little to go on. Really sucks. Its not covered in any mailing list, topics, howto, nothing. This is a massive issue at an enterprise company. Regardless I figure this out. *** To fix this problem, anytime I call the ../bin/tls-toolkit.sh client I need to install my own man-in-the-middle and extract the root certificate like so openssl s_client -connect nifi-myproject.blah.blah.bloomberg.com:443 -showcerts Extract the root CA certificate post modify the truststore.jks file to include the root CA certificate that signed the .csr cat > /bb/nifi-toolkit/nifi-toolkit-1.7.1/certs/digicert.crt <<EOF -----BEGIN CERTIFICATE----- MIIElDCCA3ygAwIBAgIQAf2j627KdciIQ4tyS8+8kTANBgkqhkiG9w0BAQsFADBh MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3 d3cuZGlnaWNlcnQuY29tMSAwHgYDVQQDExdEaWdpQ2VydCBHbG9iYWwgUm9vdCBD QTAeFw0xMzAzMDgxMjAwMDBaFw0yMzAzMDgxMjAwMDBaME0xCzAJBgNVBAYTAlVT MRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxJzAlBgNVBAMTHkRpZ2lDZXJ0IFNIQTIg U2VjdXJlIFNlcnZlciBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ANyuWJBNwcQwFZA1W248ghX1LFy949v/cUP6ZCWA1O4Yok3wZtAKc24RmDYXZK83 nf36QYSvx6+M/hpzTc8zl5CilodTgyu5pnVILR1WN3vaMTIa16yrBvSqXUu3R0bd KpPDkC55gIDvEwRqFDu1m5K+wgdlTvza/P96rtxcflUxDOg5B6TXvi/TC2rSsd9f /ld0Uzs1gN2ujkSYs58O09rg1/RrKatEp0tYhG2SS4HD2nOLEpdIkARFdRrdNzGX kujNVA075ME/OV4uuPNcfhCOhkEAjUVmR7ChZc6gqikJTvOX6+guqw9ypzAO+sf0 /RR3w6RbKFfCs/mC/bdFWJsCAwEAAaOCAVowggFWMBIGA1UdEwEB/wQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgGGMDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYY aHR0cDovL29jc3AuZGlnaWNlcnQuY29tMHsGA1UdHwR0MHIwN6A1oDOGMWh0dHA6 Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEdsb2JhbFJvb3RDQS5jcmwwN6A1 oDOGMWh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEdsb2JhbFJvb3RD QS5jcmwwPQYDVR0gBDYwNDAyBgRVHSAAMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LmRpZ2ljZXJ0LmNvbS9DUFMwHQYDVR0OBBYEFA+AYRyCMWHVLyjnjUY4tCzh xtniMB8GA1UdIwQYMBaAFAPeUDVW0Uy7ZvCj4hsbw5eyPdFVMA0GCSqGSIb3DQEB CwUAA4IBAQAjPt9L0jFCpbZ+QlwaRMxp0Wi0XUvgBCFsS+JtzLHgl4+mUwnNqipl 5TlPHoOlblyYoiQm5vuh7ZPHLgLGTUq/sELfeNqzqPlt/yGFUzZgTHbO7Djc1lGA 8MXW5dRNJ2Srm8c+cftIl7gzbckTB+6WohsYFfZcTEDts8Ls/3HB40f/1LkAtDdC 2iDJ6m6K7hQGrn2iWZiIqBtvLfTyyRRfJs8sjX7tN8Cp1Tm5gr8ZDOo0rwAhaPit c+LJMto4JQtV05od8GiG7S5BNO98pVAdvzr508EIDObtHopYJeS4d60tbvVS3bR0 j6tJLp07kzQoH3jOlOrHvdPJbRzeXDLz -----END CERTIFICATE----- EOF keytool -import -v -trustcacerts -alias digicert-ca -file digicert.crt -keystore truststore.jks Now, finally, ../bin/cli.sh nifi pg-list -verbose -p /bb/nifi-toolkit/nifi-toolkit-1.7.1/nifi.prop Works! Now I am happy. This is a mess of undocumented black magic. I dont expect the public root CA to change. Is there a way to simplify this process? Cant we ignore this whole chain thing? Maybe include the public CA cert in the nifi-ca-keystore.jks on the server running the ../bin/tls-toolkit.sh server This voodoo process really is too much guys and needs to be simplified. Suggestions are welcome. Erik Anderson Bloomberg
