Member since
07-30-2019
155
Posts
106
Kudos Received
33
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 5697 | 04-18-2019 08:27 PM | |
| 1825 | 12-31-2018 07:36 PM | |
| 3356 | 12-03-2018 06:47 PM | |
| 1042 | 06-02-2018 02:35 AM | |
| 2805 | 06-02-2018 01:30 AM |
03-31-2020
08:31 AM
There was a bug [1] in the TLS handshake negotiation process in Apache NiFi 1.11.0 - 1.11.3. NiFi 1.11.4 was released on March 22, 2020, which fixes this issue. I recommend upgrading to the latest version. [1] https://issues.apache.org/jira/browse/NIFI-7223
... View more
04-18-2019
08:27 PM
Hi Davis, I imagine the issue is that the server certificate that was signed by your organizational CA doesn't include the (intermediate or root) CA public certificates. It appears they (the signing team) sent those to you in addition as separate files. My expectation is that if you run the command more issuing-CA.cer or more root-CA.cer , you will get an output like this: -----BEGIN CERTIFICATE-----
MIIE3DCCAsSgAwIBAgIBATANBgkqhkiG9w0BAQsFADCBmzELMAkGA1UEBhMCVVMx
EzARBgNVBAgMCkNhbGlmb3JuaWExFTATBgNVBAcMDFNhbnRhIE1vbmljYTEPMA0G
A1UECgwGQXBhY2hlMQ0wCwYDVQQLDAROaUZpMRgwFgYDVQQDDA9FeGFtcGxlIE5p
RmkgQ0ExJjAkBgkqhkiG9w0BCQEWF2V4YW1wbGVAbmlmaS5hcGFjaGUub3JnMB4X
DTE2MTAyNzAwMTAwN1oXDTE5MDcyNDAwMTAwN1owazELMAkGA1UEBhMCVVMxCzAJ
BgNVBAgTAkNBMRUwEwYDVQQHEwxTYW50YSBNb25pY2ExDzANBgNVBAoTBkFwYWNo
ZTENMAsGA1UECxMETmlGaTEYMBYGA1UEAxMPbmlmaS5hcGFjaGUub3JnMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmYDueTT3NINXSHTymgnAL2ilsbzZ
2nUof3DQ7TofZX9Zn5r1cEcyJc0U9bwJDkPEXXwvN574WiL5txVKV+LZL+nqJSWl
NStvBiMbZ4eM7UuwH9IPm/36yofhkeqCoFBOR4E4OyJtAsTRs7yjp72Yw44EHpV1
xjVxXBnAcCuckKwUk1+9Q/gj/pVmsMfor9bytoqp7fiiYlqQ2qpRVx16++pg2JTI
MClM8++EI68yKwofMDLeJG0PcxxN0lvF+c86UoAzXCKHD7cJyTzTR6PpdBYuOXZr
EBOj9oQvCCaN9nkQ+7ZwTN2+78UKxPfL2BtYsBz/bhjClVmOVzASncKTSwIDAQAB
o1owWDAdBgNVHQ4EFgQUlgL5Hb5T8NkQybhTQUaSbn3kY7MwHwYDVR0jBBgwFoAU
RNigqj+NJB1moO6gLgSf28XrQ8owCQYDVR0TBAIwADALBgNVHQ8EBAMCBaAwDQYJ
KoZIhvcNAQELBQADggIBAIWQbwKjSBpsidI1/4XmbY7sX9hqlSG2Y/pZQTci9bWi
ZNdumrziEsvWmw9kqn1kLNJ5Usu8OdwpCJ6FQgt7c3cT4wKhJRLtN3mI7BNiLt3d
VdNCmFXEw6Tjb2iDZiTNcDHjKt9N7fU4VHj56vSWUBHAAlJ/FzBtiIf2Dzvvy94F
0e3uUlEWzW0q5g/RCtJIRdQwkdXxLA8g3JUdDOUGpqZl2ZBanu53KYj27313WSx4
NVI74FKMU3E/g9bmQcAd/aePsn2qP7ZnNMKadCRUOlowLMyfsxxV4RNpQ9mHTK1R
LA1GotHoVSXFeIOeSo1knw9PC10dcNuZYrkY1aOhxji/PYxFXv0eKeO67ZRsHgHv
BXBJ11bPiUUKaTLVXp9Vf67iejJEXVJTaIUH6fGK9YWNqBfs3dEbF8QVUQgBnsSV
MtFTdeCYr2bR9p3FAetDpMO2t889CKSr62mG9tfFuU6nheZdMefIGoK+T3LqmD53
sbbxa4p5/+N6r6GuGmcLGZ5ZqYg+yBzP08O/5RyteiH6hvvshZ1mF2M6xS8/fEVa
DmSPiYB4Nncbgs5o3c/zlg6zPZGeaWHr7vVXIm3KGc0+2NYgT8DHHQ+6I5CMURHD
TC+WEdX9VEUkt68IoUs58i32xzqPYkIE1WaJiXTJcuNWWAN8lTL0y4u1JOGUHDpT
-----END CERTIFICATE----- If you then run this command openssl x509 -in issuing-CA.cer -text -noout (verifies the certificate is parsable), you should get output like this: Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=California, L=Santa Monica, O=Apache, OU=NiFi, CN=Example NiFi CA/emailAddress=example@nifi.apache.org
Validity
Not Before: Oct 27 00:10:07 2016 GMT
Not After : Jul 24 00:10:07 2019 GMT
Subject: C=US, ST=CA, L=Santa Monica, O=Apache, OU=NiFi, CN=nifi.apache.org
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:99:80:ee:79:34:f7:34:83:57:48:74:f2:9a:09:
c0:2f:68:a5:b1:bc:d9:da:75:28:7f:70:d0:ed:3a:
1f:65:7f:59:9f:9a:f5:70:47:32:25:cd:14:f5:bc:
09:0e:43:c4:5d:7c:2f:37:9e:f8:5a:22:f9:b7:15:
4a:57:e2:d9:2f:e9:ea:25:25:a5:35:2b:6f:06:23:
1b:67:87:8c:ed:4b:b0:1f:d2:0f:9b:fd:fa:ca:87:
e1:91:ea:82:a0:50:4e:47:81:38:3b:22:6d:02:c4:
d1:b3:bc:a3:a7:bd:98:c3:8e:04:1e:95:75:c6:35:
71:5c:19:c0:70:2b:9c:90:ac:14:93:5f:bd:43:f8:
23:fe:95:66:b0:c7:e8:af:d6:f2:b6:8a:a9:ed:f8:
a2:62:5a:90:da:aa:51:57:1d:7a:fb:ea:60:d8:94:
c8:30:29:4c:f3:ef:84:23:af:32:2b:0a:1f:30:32:
de:24:6d:0f:73:1c:4d:d2:5b:c5:f9:cf:3a:52:80:
33:5c:22:87:0f:b7:09:c9:3c:d3:47:a3:e9:74:16:
2e:39:76:6b:10:13:a3:f6:84:2f:08:26:8d:f6:79:
10:fb:b6:70:4c:dd:be:ef:c5:0a:c4:f7:cb:d8:1b:
58:b0:1c:ff:6e:18:c2:95:59:8e:57:30:12:9d:c2:
93:4b
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
96:02:F9:1D:BE:53:F0:D9:10:C9:B8:53:41:46:92:6E:7D:E4:63:B3
X509v3 Authority Key Identifier:
keyid:44:D8:A0:AA:3F:8D:24:1D:66:A0:EE:A0:2E:04:9F:DB:C5:EB:43:CA
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Key Encipherment
Signature Algorithm: sha256WithRSAEncryption
85:90:6f:02:a3:48:1a:6c:89:d2:35:ff:85:e6:6d:8e:ec:5f:
d8:6a:95:21:b6:63:fa:59:41:37:22:f5:b5:a2:64:d7:6e:9a:
bc:e2:12:cb:d6:9b:0f:64:aa:7d:64:2c:d2:79:52:cb:bc:39:
dc:29:08:9e:85:42:0b:7b:73:77:13:e3:02:a1:25:12:ed:37:
79:88:ec:13:62:2e:dd:dd:55:d3:42:98:55:c4:c3:a4:e3:6f:
68:83:66:24:cd:70:31:e3:2a:df:4d:ed:f5:38:54:78:f9:ea:
f4:96:50:11:c0:02:52:7f:17:30:6d:88:87:f6:0f:3b:ef:cb:
de:05:d1:ed:ee:52:51:16:cd:6d:2a:e6:0f:d1:0a:d2:48:45:
d4:30:91:d5:f1:2c:0f:20:dc:95:1d:0c:e5:06:a6:a6:65:d9:
90:5a:9e:ee:77:29:88:f6:ef:7d:77:59:2c:78:35:52:3b:e0:
52:8c:53:71:3f:83:d6:e6:41:c0:1d:fd:a7:8f:b2:7d:aa:3f:
b6:67:34:c2:9a:74:24:54:3a:5a:30:2c:cc:9f:b3:1c:55:e1:
13:69:43:d9:87:4c:ad:51:2c:0d:46:a2:d1:e8:55:25:c5:78:
83:9e:4a:8d:64:9f:0f:4f:0b:5d:1d:70:db:99:62:b9:18:d5:
a3:a1:c6:38:bf:3d:8c:45:5e:fd:1e:29:e3:ba:ed:94:6c:1e:
01:ef:05:70:49:d7:56:cf:89:45:0a:69:32:d5:5e:9f:55:7f:
ae:e2:7a:32:44:5d:52:53:68:85:07:e9:f1:8a:f5:85:8d:a8:
17:ec:dd:d1:1b:17:c4:15:51:08:01:9e:c4:95:32:d1:53:75:
e0:98:af:66:d1:f6:9d:c5:01:eb:43:a4:c3:b6:b7:cf:3d:08:
a4:ab:eb:69:86:f6:d7:c5:b9:4e:a7:85:e6:5d:31:e7:c8:1a:
82:be:4f:72:ea:98:3e:77:b1:b6:f1:6b:8a:79:ff:e3:7a:af:
a1:ae:1a:67:0b:19:9e:59:a9:88:3e:c8:1c:cf:d3:c3:bf:e5:
1c:ad:7a:21:fa:86:fb:ec:85:9d:66:17:63:3a:c5:2f:3f:7c:
45:5a:0e:64:8f:89:80:78:36:77:1b:82:ce:68:dd:cf:f3:96:
0e:b3:3d:91:9e:69:61:eb:ee:f5:57:22:6d:ca:19:cd:3e:d8:
d6:20:4f:c0:c7:1d:0f:ba:23:90:8c:51:11:c3:4c:2f:96:11:
d5:fd:54:45:24:b7:af:08:a1:4b:39:f2:2d:f6:c7:3a:8f:62:
42:04:d5:66:89:89:74:c9:72:e3:56:58:03:7c:95:32:f4:cb:
8b:b5:24:e1:94:1c:3a:53 The next step is to concatenate all the public certificates into a single file so it can be imported into the keystore.jks. That way when the application (NiFi) presents its public certificate to the browser, it also presents the "certificate chain" that shows NiFi cert (signed by) Issuing CA (signed by) Root CA, and (hopefully) Root CA is already present in the client truststores (i.e. the browser/OS), or is signed by a global CA certificate (a commercial entity like Verisign, Comodo, etc.) that is already in those truststores. Basically the steps you need to take are: Copy the contents of all three " *.cer " files you received into a single text file (include the " -----BEGIN CERTIFICATE----- " and " -----END CERTIFICATE----- " lines for each) called " chain.pem ". It should look like: -----BEGIN CERTIFICATE----- Abcd... -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- 1234... -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- Wxyz... -----END CERTIFICATE----- Import this signed certificate chain into the keystore using the same alias as the private key that already exists (appears to be server based on your question above) keytool -import -trustcacerts -alias server -file chain.pem -keystore keystore.jks
... View more
01-02-2019
06:30 PM
1 Kudo
You could submit a feature request to the NiFi project, but based on the way this is currently implemented, I would not expect this change to be made in a 1.x version. NiFi is designed for immediate feedback and an iterative development cycle, so the use case of allowing a specific user to modify the configuration of a component without being allowed to operate it has not been addressed, as it was considered unrealistic.
... View more
12-31-2018
07:36 PM
2 Kudos
I do not believe there is a way to configure this with NiFi access controls. The way that NiFi permissions are set up, "operate" is a subset of "modify" -- you can have "operate" without "modify" but not "modify" without "operate". This is because the state of the processor (running/stopped) is considered configuration data and set via an API call.
... View more
12-03-2018
06:51 PM
This is not related to your issue here, but 1024 bits is no longer recommended as a secure RSA key length. You should use at least 2048, as explained here. You also have some inconsistent spacing in your Distinguished Name field, which can lead to identity verification issues depending on the client.
... View more
12-03-2018
06:47 PM
1 Kudo
The nested core exception is
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException:
unable to find valid certification path to requested target
. This indicates that the "client" (NiFi/Java) is unable to verify the complete certificate chain presented by the "server"/"destination" (the external web socket on a remote service). You will need at least one of the public certificates presented by that service to be imported into the truststore which you configured for your StandardRestrictedSSLContextService . To do that, you can use the openssl s_client tool to access that service and retrieve all the certificates. You can then copy/paste the Base-64 encoded (PEM/DER) certificates into a plaintext file and import them into your truststore.
The keystore contains the public certificate presented by your service (NiFi) as well as the private key used to establish that identity (i.e. the capability to cryptographically sign data and decrypt data which has been encrypted elsewhere with that public key). The truststore contains a list of public certificates (containing public keys) of
other services you want to trust. You've imported the public certificate of NiFi itself into that truststore, but you have not imported any external certificates.
You can also try using the JVM's default truststore, as similar to browsers and OS, it comes pre-populated with the common certificate authorities. If the site you're connecting to has a certificate signed by a CA vendor such as DigiCert, Verisign, Comodo, etc., the JDK
cacerts should work out of the box. The location is $JAVA_HOME/jre/lib/security/cacerts and the default password is changeit .
... View more
12-03-2018
06:28 PM
If the file was encrypted using
PBE (Password-Based Encryption) where the encryption key is derived from a password or other human-formatted input, you can use the EncryptContent processor in NiFi to decrypt the contents. Use a GetFile processor to read the file contents, and connect this to an EncryptContent processor set to Decrypt and populate the password and encryption algorithm as PBEWITHMD5ANDDES or PBEWITHSHA1ANDDES depending on which hash function was used to determine the key.
If you did not use PBE and have only the raw key, you will not be able to use
EncryptContent for this. My recommendation would be to write a simple Groovy script to perform the decryption and use the ExecuteScript processor, or use ExecuteStreamCommand and call openssl on the command-line to perform the decryption there.
... View more
11-28-2018
08:13 PM
@Joe P I cannot reply to your comment for some reason, so I'm putting my response here. I do not set the security policy for Ambari or any other Apache project. Every project evaluates security differently and makes decisions to reach a balance they find acceptable. I am only one member of the NiFi community as well, but our community has agreed on this policy for NiFi. We invite all community members and users to contribute ideas and engage in discussion on design decisions. You are welcome to request the changes you want, but I will say that the previous discussion around that obviously went in this direction and I don't see any new information in your position than was previously discussed.
... View more
11-27-2018
06:54 PM
1 Kudo
We fundamentally disagree on the utility and value of that feature. Providing a login page which does not secure the transmission of sensitive credentials against trivial intercept and can be bypassed easily does not provide sufficient value and leads to a number of problems: Users will assume it is secure and not change it from the default/configure stronger login options such as LDAP/Kerberos/client certificate authentication. We make a conscious effort not to offer weak security options as defaults because many users are unaware and will not change them Users will not be aware that the credentials can be intercepted and stolen (these credentials may be reused from other applications and pose a large threat) Users will not be aware that the login page can be bypassed (HTTP traffic can be monitored, and any credentials or tokens (NiFi is stateless, so it does not use session identifiers) can be intercepted and reused) For these reasons, NiFi does not offer an option for authentication or authorization controls over plaintext HTTP. HTTPS must be configured to enable those mechanisms to avoid a false sense of security and prevent user/admin complacency.
... View more
10-18-2018
11:22 AM
1 Kudo
Justen, you do not need to provide a value for Attributes to Send if you are providing the Authorization header via a dynamic property on the InvokeHTTP processor (all dynamic properties are included as headers automatically). If the token value is coming as an attribute on the incoming flowfile, then you will need to provide a value for Attributes to Send -- you can use the explicit attribute name (key) if you only want to send that header, or a regular expression if you want to send more than one. I've linked to a template I just built which demonstrates this behavior. The dynamic property is already there -- to add one, you click the "+" icon on the top right of the Properties tab in the processor configuration.
... View more