Hi Roland, Thanks for the reply. If you are not seeing any warnings or errors in the NiFi Registry logs, you could enable SSL debugging in the NiFi Registry bootstrap.conf. Adding the following line to bootstrap.conf should enable SSL debug output to the nifi-registry-bootstrap.log:
java.arg.20=-Djavax.net.debug=ssl This setting produces a lot of output, but if you watch the log after the initial application startup, you should be able to observe the TLS handshake when NiFi attempts to list buckets from NiFi Registry. The log output should at least confirm that the certificate exchange is occurring as expected. Regards, David Handermann On Mon, Mar 29, 2021 at 10:34 PM Rosso, Roland < [email protected]> wrote: > Hi David, > > > > I use the nifi-toolkit to create the keystore and truststore to make sure > clientAuth and serverAuth is set properly. > > > > This is a ‘working’ config. > > Keystore: > > Alias name: nifi-key > > Creation date: date > > Entry type: PrivateKeyEntry > > > > Truststore: > > Alias name: server_name-nifi-cert > > Creation date: date > > Entry type: trustedCertEntry > > > > Owner: CN=server.domain.net, OU=NIFI > > Issuer: CN=localhost, OU=NIFI > > > > The issue with the new setup is using external CA, also created via the > nifi-toolkit, new NiFi install working fine (from a SSL perspective), > Registry connecting but can’t list buckets. > > > > Alias name: server_name-nifi-cert > Creation date: Mar 29, 2021 > Entry type: trustedCertEntry > > Owner: CN= server_name.domain.net, OU=NIFI > Issuer: CN=nifi_ca.domain.net, OU=ORG_NAME, O=ORG_FULL_NAME, L=LOCATION, > ST=XX, C=US > > > > Thanks, > Roland > > > > *From:* David Handermann <[email protected]> > *Sent:* Monday, March 29, 2021 9:27 PM > *To:* [email protected] > *Subject:* Re: [EXTERNAL] Re: NiFi Registry SSL question > > > > Hi Roland, > > > > Can you provide the commands you are using to create the server > keystores? Listing the keystore contents using "keytool -list -v -keystore > <keystoreFile>" should include an Entry Type of "PrivateKeyEntry", so it > would be helpful to confirm that the keystore includes a PrivateKeyEntry > and not a TrustedCertEntry. > > > > Regards, > > David Handermann > > > > On Mon, Mar 29, 2021 at 5:49 PM Rosso, Roland < > [email protected]> wrote: > > I've tried this one more time (Nifi 1.12.1 to Registry 0.6.0). > Re-signed/Re-imported the certs. > > The new "server" cert is of the type: > > Alias name: server_name-nifi-cert > Creation date: Mar 29, 2021 > Entry type: trustedCertEntry > > Owner: CN= server_name.domain.net, OU=NIFI > Issuer: CN=nifi_ca.domain.net, OU=ORG_NAME, O=ORG_FULL_NAME, L=LOCATION, > ST=XX, C=US > > [blah] > > I am adding the "server user" 'CN= server_name.domain.net, OU=NIFI' to > the registry with all the grants. I don't see any errors in the logs but > still cannot properly link it to the existing buckets. Should I add the > "server user" in a different manner since the cert issuer is not 'Issuer: > CN=localhost, OU=NIFI'? > The other servers certs that are signed with 'Issuer: CN=localhost, > OU=NIFI' work just fine (Nifi 1.9.2 to Registry 0.6.0). > Is there a way to increase the logs as well? > > Many thanks, > Roland > > -----Original Message----- > From: Rosso, Roland <[email protected]> > Sent: Thursday, March 25, 2021 2:21 PM > To: [email protected] > Subject: RE: [EXTERNAL] Re: NiFi Registry SSL question > > Thank you Bryan, > I've tried all combinations I could think off. > I'll resign all the certs with the same key for nifi and registry and try > this again. > > Thanks, > Roland > > -----Original Message----- > From: Bryan Bende <[email protected]> > Sent: Tuesday, March 23, 2021 3:48 PM > To: [email protected] > Subject: [EXTERNAL] Re: NiFi Registry SSL question > > I think the issue might be related to the "server user" in nifi registry. > I would double check that the way the identity was entered in registry > exactly matches the identity from nifi's certificate, case-sensitive and > white-space sensitive. Also make sure this user in registry is granted all > of the Proxy permissions, it is broken out into three different actions now > (read, write, delete). > > On Tue, Mar 23, 2021 at 9:28 AM Rosso, Roland < > [email protected]> wrote: > > > > Hi all, > > > > I am moving things around and moving from self-signed certs to corporate > certs. > > > > I’ve installed nifi 1.12 with a new truststore and keystore (use toolkit > with external certs) and that seems fine. > > > > I added the cert from the registry server (old self signed) into the new > nifi 1.12 truststore and the new server cert (signed with corporate CA) > into the nifi registry truststore (again, self signed). > > > > I also added the server ‘user’ CN=server.domain, OU=NIFI into the > registry and made the permission grants (proxy, buckets). I don’t get any > SSL errors in the logs but cannot add a PG via registry (no available > bucket). > > > > Is this setup possible and am I missing something, or do all NiFi nodes > and registry need to be signed with the same key? The idea was to setup a > new instance (on new server), pull all PGs via registry into the new and > retiring the old. > > > > > > > > Thanks, > > > > Roland > > > > > > > > > > > > This message (including any attachments) is intended only for the use of > the individual or entity to which it is addressed and may contain > information that is non-public, proprietary, privileged, confidential, and > exempt from disclosure under applicable law or may constitute as attorney > work product. If you are not the intended recipient, you are hereby > notified that any use, dissemination, distribution, or copying of this > communication is strictly prohibited. If you have received this > communication in error, notify us immediately by telephone and (i) destroy > this message if a facsimile or (ii) delete this message immediately if this > is an electronic communication. Thank you. > This message (including any attachments) is intended only for the use of > the individual or entity to which it is addressed and may contain > information that is non-public, proprietary, privileged, confidential, and > exempt from disclosure under applicable law or may constitute as attorney > work product. If you are not the intended recipient, you are hereby > notified that any use, dissemination, distribution, or copying of this > communication is strictly prohibited. If you have received this > communication in error, notify us immediately by telephone and (i) destroy > this message if a facsimile or (ii) delete this message immediately if this > is an electronic communication. Thank you. > This message (including any attachments) is intended only for the use of > the individual or entity to which it is addressed and may contain > information that is non-public, proprietary, privileged, confidential, and > exempt from disclosure under applicable law or may constitute as attorney > work product. If you are not the intended recipient, you are hereby > notified that any use, dissemination, distribution, or copying of this > communication is strictly prohibited. If you have received this > communication in error, notify us immediately by telephone and (i) destroy > this message if a facsimile or (ii) delete this message immediately if this > is an electronic communication. Thank you. > > This message (including any attachments) is intended only for the use of > the individual or entity to which it is addressed and may contain > information that is non-public, proprietary, privileged, confidential, and > exempt from disclosure under applicable law or may constitute as attorney > work product. If you are not the intended recipient, you are hereby > notified that any use, dissemination, distribution, or copying of this > communication is strictly prohibited. If you have received this > communication in error, notify us immediately by telephone and (i) destroy > this message if a facsimile or (ii) delete this message immediately if this > is an electronic communication. Thank you. >
