Support Questions

Find answers, ask questions, and share your expertise

Securing NiFi 1.3.0

avatar
New Contributor

Hi, im trying to secure my nifi installation with ssl certificates. Initially i used the tls toolkit for testing purposes, things were working fine. However, when i switched to the CA SSL certs provided my infra team, im having issues.

Some of the issues i observed

1. Chrome doesnt prompt to choose certificate that i have installed (CA cert). If i use the SSL cert generated by tls toolkit, it prompts just fine.

2. I see some differences in EKU and KU sections of both the certs, see attached screenshot.

3. Certificate length is 2 for the one i generated via tls toolkit, but length is 1 for the CA one.

I have tried everything, and not able to fix this issue.

Hope someone can point me to the right direction.

40452-dv.png

40451-it.png

1 ACCEPTED SOLUTION

avatar
Contributor

Hi James,

I recently configured our NiFi 1.3 installation using certificates from our internal CA and found I had to do a little bit of certificate and keystore manipulation to get things working. I too had things working nicely using the nifi-toolkit and then found myself scratching my head and doing a lot of SSL handshake debugging wondering what had changed with my configuration. The NiFi toolkit is so great it’s hard to believe how much it actually does for you using a single line of code …client AND server certificate creation, strong passwords on all of your stores, keystore and truststore creation with the appropriate private, public, and trusted cert entries ….pretty impressive stuff!

Anyway here’s some to the configuration I had to do to get my internal certificates playing nicely with NiFi. Firstly, I had our pki team issue two certificates for us which were conveniently issued in two formats .p12 and .cer

1. Client cert (myClientCert.pem.p12 and myClientCert.pem.cer). This certificate only requires a EKU of clientAuth. This certificate is imported into your browser.

2. Server cert (myServerCert.pem.p12 and myServerCert.pem.cer). This certificate requires an EKU of both clentAuth and serverAuth. These are used on the server and not in your browser.

Client cert – This certificate needs to have a DN with credentials exactly matching those you have configured in your authorizers.xml file “Initial Admin Identity” property. Exactly matching means spaces, punctuation etc. need to match in your cert and your authroizers.xml file. This is the certificate you need to upload to your browser so you can log into the UI and configure access for other users (i.e. if in windows double click on the .p12 certificate and import it with the appropriate password). Your client configuration should be good to go.

Server cert – Matt’s configuration details above are spot on. As he mentions your server certificates KU and EKU look good (…which was more than I can say about ours!). One thing I did find in our CA issued certificates is that they did not contain the complete certificate chain for our environment so I needed to add this information in to get things working smoothly. To do this in windows complete the following:

  1. Import the certificate into the windows certificate manager by double clicking on the .p12 file and follow the import wizard.
  2. Tick the "Mark this key as exportable. This will allow you to back up or transport your keys at a later time" check box.
  3. Follow the remaining wizard prompts to import the certificate.
  4. Open a Windows command prompt and run "certmgr.msc" (Capi).
  5. Browse to "Personal" and select the certificate that was imported in step 1. Right click the certificate and choose "All Tasks" -> "Export".
  6. Select "Yes, export the private key" radio button when prompted.
  7. Select "Include all certificates in the certification path if possible" and "Export all extended properties" check boxes.
  8. Follow the remaining wizard prompts to export the certificate which now includes the entire certificate chain.
  9. Upload the exported certificate with the complete certificate chain to the server environment that is being configured.

Keystore creation

The keystore exported from Capi will not be in jks format so you need to convert it into a format that NiFi can use

keytool -importkeystore -srckeystore <certificateLocation> -destkeystore <destinationKeystore> -srcstoretype pkcs12

You now have a jks keystore with a single private key entry (with a chain length of three) containing the complete certificate chain.

Truststore creation

You need to add your root and intermediate certificate as trusted entries in your truststore. To extract the root and intermediate certificates once again use certmgr.msc and browse the directories for your root and intermediate ca entries. Export both of these certificates and upload them to your server.

We can now create a truststore file using the JDK's Keytool utility.

keytool -importcert -v -trustcacerts –alias <certificateAliasName> -file <locationToCertificate> -keystore <TrustStoreName> –storepass <TrustStorePassword> –noprompt

Repeat this process for both the root and intermediate certificates.

Be careful with the passwords that you use for importing and exporting the certificates as it is easy to change them and lose track of what the final password of your keystore and trustsores are. Be sure to do a verbose list of both the keystore and truststore so you know they are correct and match the entries defined in your nifi.properties file.

That’s pretty much it …if you’ve done everything correctly you should be prompted for you admin user cert by your browser when you hit the NiFi url and be greeted by the NiFi user interface. Good luck.

View solution in original post

6 REPLIES 6

avatar
Master Mentor

@James V

The "Keystore" you are using that you are using that was derived form your CA should contain only a single "PrivateKeyEntry". That "PrivateKeyEntry" should have a EKU that authorizes it use for both clientAuth and ServerAuth. (Based on above, EKU looks correct.) The Issuer listed of that PrivateKeyEntry should be the DN for your CA. If the Issuer is the same as the owner, it is a self signed cert. This typically means you did not install the response you got back from your CA. You should have provided your CA with a csr (certificate signing request) which you then received a response for.

The "truststore" should not contain any PrivateKeyEntries. It should contain 1 to many "TrustedCertEntries". There should be a trustedCertEntry for every CA that signs any certificates being used anywhere to communicate with this NiFi. TrustedCertEntries are nothing more teh public keys.

Thanks,

Matt

avatar
Master Mentor
@James V

Can you post teh entire verbose output of both your Keystore and Truststore?

avatar
New Contributor

Hi Matt,

Thanks for taking the time to answer. I checked the keystore and trustedstore based on what you provided. I can see exactly what you suggest, 1 privatekeyentry in keystore and 1 trustedcertentries in trustedstore.

I have also turned on the debugging and this is what i see in nifi-bootstrap.log

40504-ks.png

40505-ts.png

nifi-bootstrap.log

40507-chain.png

Appreciate your help on this matter. Thanks!

avatar
Contributor

Hi James,

I recently configured our NiFi 1.3 installation using certificates from our internal CA and found I had to do a little bit of certificate and keystore manipulation to get things working. I too had things working nicely using the nifi-toolkit and then found myself scratching my head and doing a lot of SSL handshake debugging wondering what had changed with my configuration. The NiFi toolkit is so great it’s hard to believe how much it actually does for you using a single line of code …client AND server certificate creation, strong passwords on all of your stores, keystore and truststore creation with the appropriate private, public, and trusted cert entries ….pretty impressive stuff!

Anyway here’s some to the configuration I had to do to get my internal certificates playing nicely with NiFi. Firstly, I had our pki team issue two certificates for us which were conveniently issued in two formats .p12 and .cer

1. Client cert (myClientCert.pem.p12 and myClientCert.pem.cer). This certificate only requires a EKU of clientAuth. This certificate is imported into your browser.

2. Server cert (myServerCert.pem.p12 and myServerCert.pem.cer). This certificate requires an EKU of both clentAuth and serverAuth. These are used on the server and not in your browser.

Client cert – This certificate needs to have a DN with credentials exactly matching those you have configured in your authorizers.xml file “Initial Admin Identity” property. Exactly matching means spaces, punctuation etc. need to match in your cert and your authroizers.xml file. This is the certificate you need to upload to your browser so you can log into the UI and configure access for other users (i.e. if in windows double click on the .p12 certificate and import it with the appropriate password). Your client configuration should be good to go.

Server cert – Matt’s configuration details above are spot on. As he mentions your server certificates KU and EKU look good (…which was more than I can say about ours!). One thing I did find in our CA issued certificates is that they did not contain the complete certificate chain for our environment so I needed to add this information in to get things working smoothly. To do this in windows complete the following:

  1. Import the certificate into the windows certificate manager by double clicking on the .p12 file and follow the import wizard.
  2. Tick the "Mark this key as exportable. This will allow you to back up or transport your keys at a later time" check box.
  3. Follow the remaining wizard prompts to import the certificate.
  4. Open a Windows command prompt and run "certmgr.msc" (Capi).
  5. Browse to "Personal" and select the certificate that was imported in step 1. Right click the certificate and choose "All Tasks" -> "Export".
  6. Select "Yes, export the private key" radio button when prompted.
  7. Select "Include all certificates in the certification path if possible" and "Export all extended properties" check boxes.
  8. Follow the remaining wizard prompts to export the certificate which now includes the entire certificate chain.
  9. Upload the exported certificate with the complete certificate chain to the server environment that is being configured.

Keystore creation

The keystore exported from Capi will not be in jks format so you need to convert it into a format that NiFi can use

keytool -importkeystore -srckeystore <certificateLocation> -destkeystore <destinationKeystore> -srcstoretype pkcs12

You now have a jks keystore with a single private key entry (with a chain length of three) containing the complete certificate chain.

Truststore creation

You need to add your root and intermediate certificate as trusted entries in your truststore. To extract the root and intermediate certificates once again use certmgr.msc and browse the directories for your root and intermediate ca entries. Export both of these certificates and upload them to your server.

We can now create a truststore file using the JDK's Keytool utility.

keytool -importcert -v -trustcacerts –alias <certificateAliasName> -file <locationToCertificate> -keystore <TrustStoreName> –storepass <TrustStorePassword> –noprompt

Repeat this process for both the root and intermediate certificates.

Be careful with the passwords that you use for importing and exporting the certificates as it is easy to change them and lose track of what the final password of your keystore and trustsores are. Be sure to do a verbose list of both the keystore and truststore so you know they are correct and match the entries defined in your nifi.properties file.

That’s pretty much it …if you’ve done everything correctly you should be prompted for you admin user cert by your browser when you hit the NiFi url and be greeted by the NiFi user interface. Good luck.

avatar
New Contributor

@D H

Thank you very much for your help. It works now! Followed all your steps.

avatar
Contributor

Glad to hear it :). Enjoy your secure NiFi instance.