In NiFi, how does one create the necessary keystore, truststore and certificates needed to configure the StandardRestrictedSSLContextService controller service?
I need to invoke an HTTPS REST service. (Using NiFi 1.9.2 in local development mode)
Steps taken:
Used TLS toolkit to generate self-signed certs, truststore and keystore
Saved the API endpoint certificate to a .cer file (exported from chrome)
$keytool -import -alias mycert -keystore /opt/nifi/conf/truststore.jks -file api-cert.cer
After doing this, InvokeHTTP processor in NiFi indicates it cannot find the certification path:
PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
You can either create those files manually (using tools like openssl and keytool), use the NiFi TLS Toolkit, or obtain those files from an enterprise security team. The keystore needs to contain the private key and public certificate of the NiFi certificate; the truststore should contain the public certificates of the external services you want to interact with. See the NiFi Walkthroughs for examples. RestrictedSSLContextService is only required for incoming connections; SSLContextService can be used for outgoing connections to legacy systems (Restricted disables TLS protocol versions older than TLS v1.2).
Provide a full path in the keystore and truststore filename fields.
I'm using a nifi contianer and the default directory is /opt/nifi/nifi-current/.
I placed the files in a certs directory so my keystore filename field looks like this:
certs/keystore.pfx
Related
I got a secure cluster NIFI with 3 nodes, configured with truststore.jks and keystore.jks
In my invokeHTTP, i've set "StandardSSLContextService" with keystore and trustore for https.
invokeHTTP works when i'm trying https://nifi:9443/nifi-api/controller/config
but not works when i'm trying "https://auth_server/oauth/access_token"
So when I'm trying use invokeHTTP to get token but it failed with this error :
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
thanks for helps
The StandardSSLContextService can be configured with a truststore, which is a Java KeyStore object which contains a collection of TrustedCertEntry objects -- each of which holds the public key and certificate information of a trusted entity. When Apache NiFi attempts to contact some other endpoint or service over HTTPS, it evaluates the received certificate identifying the service and attempts to validate that certificate. If the endpoint certificate is not directly contained in the truststore, it checks to see which certificate signed the leaf cert, and validate that one. This process continues up the certificate chain until either a cert is found that is trusted, or none are.
The error message you are receiving is stating that none of the certificates in the chain could be verified. As daggett pointed out, you could manually import the certificate of the service you want to validate into a custom truststore. If this is a service available on the public internet and signed by a generally trusted certificate authority (CA), you can also point your StandardSSLContextService to the default list provided by Java. The cacerts truststore is included automatically, and has a similar trusted entry list to modern browsers. It is found in $JAVA_HOME/jre/lib/security/cacerts. You can determine the value of $JAVA_HOME for your OS and Java version.
Truststore filename: /Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/jre/lib/security/cacerts (example)
Truststore password: changeit (default value)
Truststore type: JKS
I have created a Weblogic 12c Domain with a Managed Server on which i have installed SOA Suite 12.2. To be able to invoke REST services over SSL in my composites i have create a truststore with a valid certificate chain to connect to the REST server over SSL.
I have created a Custom Identity and Custom Trust for the SOA Managed server using a Custom Identity Store in /u01/data/keystores/identitykeystore.jks and truststore in /u01/data/keystores/truststore.jks.
When invoking the composite using the REST service i get a remotefault
<bpelFault><faultType>0</faultType><remoteFault xmlns="http://schemas.oracle.com/bpel/extension"><part name="summary"><summary>oracle.fabric.common.FabricInvocationException: javax.ws.rs.ProcessingException: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target</summary></part><part name="code"><code>null</code></part><part name="detail"><detail>unable to find valid certification path to requested target</detail></part></remoteFault></bpelFault></fault><faultType>
<message>0</message></faultType></messages>
In de server.out a java exception is found shortly after invoking the service reporting that a valid certification path cannot be found
sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
The received certificate chain is as expected, a root CA, intermediate and server certificate. (also extracted from the server.out)
The cause seems to be that weblogic is not using the configured custom truststore but the default Java truststore. (yes, nodemanager, admin and managed server have been restarted) This explains why the certification path is not valid, but have currently not a clue how to resolve this.
<Jun 23, 2016 10:15:27 PM CEST> <Info> <Management> <BEA-141107> <Version: WebLogic Server 12.2.1.0.0 Tue Oct 6 10:05:47 PDT 2015 1721936>
trustStore is: /usr/java/jdk1.8.0_92/jre/lib/security/cacerts
trustStore type is : jks
trustStore provider is :
init truststore
adding as trusted cert:
Subject: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US
Any suggestion, hint or solution is welcome!
-- Update 1 --
Found the following in the document "Fusion Middleware Securing Oracle WebLogic Server"
How WebLogic Server Locates Trust
WebLogic Server uses the following algorithm when it loads its trusted CA certificates:
If the keystore is specified by the -Dweblogic.security.SSL.trustedCAkeystore command-line argument, load the trusted CA certificates from that keystore.
Else if the keystore is specified in the configuration file (config.xml), load trusted CA certificates from the specified keystore. If the server is configured with DemoTrust, trusted CA certificates will be loaded from the WL_HOME\server\lib\DemoTrust.jks and the JDK cacerts keystores.
Else if the trusted CA file is specified in the configuration file
(config.xml), load trusted CA certificates from that file (this is
only for compatibility with 6.x SSL configurations).
Else load trusted CA certificates from WL_HOME\server\lib\cacerts
keystore.
The argument -Dweblogic.security.SSL.trustedCAkeystore is not used and therefore should load the trusted CA certificates from the custom truststore.
-- update 2 --
For the outbound web service bindings, Oracle SOA Suite uses JRF HttpClient and, therefore, the Sun JDK libraries for SSL. Therefore the -Djavax.net.ssl.trustStore=your_truststore_location has to be added to the JAVA_OPTIONS in the startweblogic.sh
After adding the truststore property to the JAVA_PROPERIES the following is logged in the server.out file..
soa_server1.out:/u01/data/domains/soa12c/bin/setDomainEnv.sh: line 384: -Djava.net.ssl.trustStore=/u01/data/keystores/truststore.jks: No such file or directory
File exist, domain user has file access to the jks file.
It is not working because whatever you've put is overwritten by Demo Trust. If you got to manager server bin path and open setDomainEnv and search for Demo you'll see Demo trust JKS. Remove it and then restart your SOA server.
One quote on the wrong position.....
I initally alreadt removed the java property -Djava.net.ssl.trustStore from the JAVA_PROPERTIES in the setDomainEnv.sh. And placed a new property -Djava.net.ssl.trustStore for he truststore. But placed it -outside- the double quotes enclosing the contents of JAVA_PROPERTIES. That explains why it defaulted back to cacerts ..
I am consuming third party web service in my application. It has https url which requires handshake. I am using Weblogic application Server and I want to configure the certificate in my server.
Can anyone please provide me steps to configure that certificate?
Also What is Identity and Trust on Weblogic Console?
Please help!!
Update the cacerts file for the JVM used by WebLogic. Using the WebLogic console, select the server. Then use the Configuration > Keystores tab to find the cacerts file location labeled Java Standard Trust Keystore on this page.
You will want to import the certificate from the web service into this cacerts file. If you are a Windows user, I use a free tool called Keystore Explorer (http://keystore-explorer.sourceforge.net/). This application allows to directly import the certificate using the URL. Do this by opening your cacerts file in KeyStore Explorer then use the Examine SSL option to import the certificate.
I resolved this by using keytool command provided in Jdk bin folder.
I just went to demotrust.jks and imported the third party certificate in it and it worked for me.
I used below command.
${ORACLE_HOME}/product/jrockit-jdk1.6.0_20-R28.1.0-4.0.1/bin/keytool -import -alias [AliasForYourCertificate] -keystore ${ORACLE_HOME}/Middleware/wlserver_10.3/server/lib/DemoTrust.jks -file /home/oracle/[YourCertFile].crt
Followed steps to integrate Worklight with backend system. In 5.0.6 adapters should support mutual SSL.
Import cert into default.keystore with alias named cert1
Modified adapter's sslCertificateAlias as cert1
When using Worklight Studio to run deployed adapter connecting with server, it is complaining about "Unable to find certificate chain with alias: 'cert1'".
What are the steps missing?
Check "ssl.keystore.*" properties in "worklight.properties" file, after it check if the cert exists in the keystore file using keytool:
keytool -list -keystore default.keystore
Here is are steps to configure mutual SSL between adapter and backend server with self signed certificates:
generate adapter's private key in "default.keystore" and export its public certificate
import adapter's certificate into backend truestore file
in case backend hasn't CA signed certificate:
generate backend's private key in its keystore file and export public certificate
import backend's public certificate into "default.keystore" file on WL server
Check worklight.properties file. Make sure that ssl related setting point to a default.keystore.
Figured out yesterday. Have to config certificate chain in proper way.
All certifications (server cert, first level cert and root cert) have to combine into one in special order and import with private key into keystore. Then use one alias name so that Worklight adapter could find it.
I followed the instructions given on this page to import the server certificate.
When I use keytool -list, I can see that the certificate is actually in the keystore. If I try to import the .crt file, keytool warns me that the keystore already contains the certificate.
Then I updated wrapper.conf with the two ssl options. I can see them on the command line of the Nexus process after a restart.
But when I try to add a proxy repo for the remote server, I always get sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
What did I miss?
You have to import the custom CA certificate into the 'trustStore' and not into the 'keyStore'.
The procedure for creating a 'trustStore' is the same as the one for the 'keyStore'.
Once you have your *.jks file then link it using the following system properties:
javax.net.ssl.trustStore=<file>
javax.net.ssl.trustStorePassword=<password>
Error message means the JVM cannot properly authenticate the remote server's SSL cert. Very common if the remote server is using a self-signed cert instead of one signed by an official certificate authority (like verisign).
Your message is confusing. You've enabled SSL on your Nexus instance, however you talk about a proxy repo implying the problem SSL cert might be on another server.