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
Related
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
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 have no problem to set up SoapUI mock service with self signed certificate by following the steps at
http://www.soapui.org/Service-Mocking/securing-mockservices-with-ssl.html .
But now I want to test the mock service with a "real" certificate issue by Entrust Certification Authority - L1C.
Other information for this certificate is
Ensures the identity of a remote computer
1.2.840.113533.7.75.2
2.23.140.1.2.2
It is valid until 2016.
I used the command to import the certificate to server.keystore .
c:\Program Files\Java\jre6\bin\keytool.exe -import -alias server -keystore server.keystore -storepass mypasss -file server_cer_issued_by_entrust.cer
(if I replace server_cer_issued_by_entrust.cer with a self signed (created) certificate it works)
I got the error in SoapUI which says ssh handshake error.
I just realize that it maybe not possible since the mock service is 127.0.0.1 but the actual certificate is issue for a web service like "mydomain.com", is that right?
SOAPUI runs over java, and when java connects to SSL url performs two validations:
Validate that the server certificate is trusted.
Validate that the common name in subject distinguished name of the server certificate matches the domain.
I assume that the first validation pass since in the link instructions which you provide its specify the same keystore in mock service for both: keystore and truststore, and since server certificate is imported in this one there is no problem to pass this validation.
So probably as you said the problem is that your mock service is on 127.0.0.1 and your certificate is issued to be used in mydomain.com.
A possible workaround is to disable SSL validation however this has no sense since as you said in the question you want to test the service with "real" certificate, instead maybe you can try editing host file and adding the mapping for 127.0.0.1 ip address for your certificate server domain, in your case:
127.0.0.1 mydomain.com
And then change the SOAPUI endpoint for your mock service to https://mydomain.com.
Hope this helps,
We are developing an application using tomcat and jersey.
Within this webapplication we need to connect to a https Website with a valid, not expired certificate.
If I do connect to this website locally via my chrome browser, everything works fine!
Unfortunately the tomcat server with our webapp throws an exception. We are using the Apache HttpClient (4.0) to connect to the https site:
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:371)
at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:126)
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:572)
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)
at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294)
at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
The server certificate is absolutely valid and from thawte.
Three different online tools validated the certificate successfully.
Openssl has an issue, too and showing me three certificates but throwing a simple error:
Verify return code: 20 (unable to get local issuer certificate)
The problem with openssl seems to be that it uses the wrong path /usr/lib/sslinstead of /etc/ssl/certs. If I use the CApath argument pointing to the proper path, openssl works fine so may this be an issue with the httpClient?
So our code for the default client is quite simple:
client = new DefaultHttpClient();
response = client.execute(url); //this throws the exception
EntityUtils.consume(response.getEntity());
It's not an option to allow any certificates by implementing a custom TrustedManager!
Futher I read, that some CA's are not part of the JDK/JRE and so it's certificates should be imported manually into the keystore or use a custom one, but thawte is a well known CA and shouldn't it work on default?
EDIT
I did set the javax.debug properties in catalina.sh so that I have further information about the problem:
http-bio-8080-exec-1, handling exception: javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path validation failed:
java.security.cert.CertPathValidatorException: basic constraints check failed:
pathLenConstraint violated - this cert must be the last cert in the certification path
I would appreciate any help!
Thanks in advance!
Okay, I got it working!
Although thawte is a well known CA it seems that Java SSL did have some problems with it.
After downloading the ssl Certificate via openssl:
echo |\
openssl s_client -connect ${REMHOST}:${REMPORT} 2>&1 |\
sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'
and saving it into an pem file, I did the manual import into the java keystore:
keytool -import -alias myAlias -file theCert.pem -keystore lib/security/cacerts
I have no idea why java ssl was not able to validate the thawte certificate properly.
Listing the keystore showed me, that there are 7 thawte trusted certificates in the standard keystore but bizarrely it did not work until I manually imported the pem file
I am trying to understand your setup. You have a SSL certificate (issued by Thwate), installed in tomcat and you can access your site just fine over SSL using say IE or Firefox or Chrome.
But when you try to access it using HttpClient, you receive the above error ?
Is that correct ?
The error clearly indicates that your client does not trust the CA. But if the cert is signed by Thwate (and is installed correctly and is acessible via IE/Firefox etc), then it should work fine.
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.