Support Questions
Find answers, ask questions, and share your expertise
Announcements
Alert: Welcome to the Unified Cloudera Community. Former HCC members be sure to read and learn how to activate your account here.

Nifi WebSocket Secure (wss://)

Solved Go to solution
Highlighted

Nifi WebSocket Secure (wss://)

New Contributor

Greetings!

I have a problem when I want to connect to a secure websocket with Nifi to get the information from it. This is how I take it and my problem:

I have created a "ConnectWebSocket" processor in Nifi.

I created my Truststore and Keystore for SSL.

I have created a "JettyWebSocketClient" to configure my WSS link.

And I created "StandardRestrictedSSLContextService" to set the paths of my keystore and truststore.

When I start the "ConnectWebSocket" processor Attached is the log file related to the problem, it seems to be a Handshake SSL problem, but I don't know. Here are my commands to create my keystore and truststore:

#: keytool -genkey -alias NifiTest -keyalg RSA -keysize 1024 -dname "CN=NiFi NifiTest, OU=SCC,O=SCC,L=Annapolis,S =Maryland,C=US" -keypass test1234 -keystore  NifiTest.jks -storepass test1234 -validity 360
#: keytool -importkeystore -srckeystore  NifiTest.jks -destkeystore NifiTest.p12 -srcstoretype JKS -deststoretype PKCS12 -srcstorepass test1234 -deststorepass test1234 -srcalias NifiTest -destalias NifiTest -srckeypass test1234 -destkeypass test1234 -noprompt
#: keytool -export -keystore  NifiTest.jks -storepass test1234 -alias NifiTest -file NifiTest.cer
#: keytool -import -trustcacerts -file NifiTest.cer -alias NifiTest -keystore truststore.jks -storepass test1234 -noprompt

I don't know if I'm creating my keystore and truststore correctly but it works well for the HTTPS.

Thank you for your answers.

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted

Re: Nifi WebSocket Secure (wss://)

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 solution in original post

2 REPLIES 2
Highlighted

Re: Nifi WebSocket Secure (wss://)

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 solution in original post

Highlighted

Re: Nifi WebSocket Secure (wss://)

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.

Don't have an account?
Coming from Hortonworks? Activate your account here