i'm using kettle RESTClient got following error:
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
i found maybe kettle don't trust self-signed certs by default,but i don't know how to fix it ,would someone help?
This is an open issue against the REST step: http://jira.pentaho.com/browse/PDI-13846
Feel free to add your vote to the case, maybe it will make it into PDI 6.0 :)
Related
I've got a WebSphere 9 server for testing web apps on my laptop. I also have Hybris running under Tomcat on my laptop (for testing also). I wrote a Java web app to test punchout functions in Hybris, that runs on my WebSphere server. It had been working, but I had to reinstall WebSphere. Since then, when I try to run my web app in WebSphere, I get this error in WebSphere:
javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.h: PKIX path
building failed: java.security.cert.CertPathBuilderException: unable
to find valid certification path to requested target
whenever my app tries to post to Hybris.
In the administrative console of WebSphere, I used the "receive from port" button to get the self-signed certificate from Hybris into the nodedefaultTrustStore in WebSphere. Hybris is at applied.local:9002 on my laptop and the certificate looks like this:
CN=applied.local, OU=applied.local, O=applied.local, L=applied.local,
ST=WI, C=us Valid from Jul 17, 2019 to Apr 11, 2022.
All of this was working previously, but I must have broken something. I must be missing something. I don't understand why it can't "find a valid certification path" to applied.local, since the CN is applied.local, and the certificate is in the trust store in WebSphere.
I got it working, but I don't know why I had to do this to get it working. If someone can explain why - that would be great. Anyway here's what I did:
Added custom variables to WebSphere to define where cacerts was, but default values should have worked, so not sure if this had any effect. In admin console, application servers > server1 > Java and Process Management, process definition, Java Virtual Machine, Customer properties: javax.net.ssl.truststore (path to cacerts in WebSphere), javax.net.ssl.truststoretype jks, and javax.net.ssl.trustStorePassword changeit.
Used a browser to export the self-signed certificate Hybris was using to a file.
Used Ikeyman to import the certificate into cacerts. (There are instructions on how to do this in IBM's pages).
Restarted WebSphere and Hybris and posting from WebSphere to Hybris worked again.
What doesn't make sense to me is that I had previously imported the Hybris self-signed certificate using the "Retrieve from port" button in the admin console for the NodeDefaultTrustStore. That used to work, but now apparently I have to import it into cacerts also or instead?
I'm kinda at a loss here.
Trying to set up proton with SSL / TLS access, but after creating the certificates with the (modified) shell scripts
supplied by the AppDev-Pack and linking the keyring and everything in notes.ini, I always seem to get
the error "Handshake failed with fatal error SSL_ERROR_SSL: error: 100000f7:SSL routines:OPENSSL_internal:
WRONG_VERSION_NUMBER".
Tried both a windows and linux server, as well as using the accessing node.js app with and without
certificates - but with no success.
Also tried the troubleshoot section of https://doc.cwpcollaboration.com/appdevpack/docs/en/proton-admin.html and it connected just fine,
but won't if i connect with node.js.
Looks like the error is thrown before a certificate is even checked?
In this example the error is thrown after trying to get a document by UNID.
notes.ini (proton parts)
gRPC Client Error
If someone has an idea how to fix that issue or where to start - that would really help me.
Thanks in advance.
It appears that the client side does not have the secure flag set. At least I get a similar stack when I try to connect without TLS when the server expects TLS.
See the secure attribute when calling useServer() function, and you'll also need to provide the credentials attributes.
I was trying to establish a ssl connection to the sever in my application. for this, I generated self-signed certificates and added them to the keystore as well as the java cacerts which is the trust store.
But When I launch my application, I keep getting PKIX path building failed validatorException: unable to find valid path to requested target error
Hence unable to login to my java application.I use java1.8.0_144 version.
Try to login to the website which IDE is complaining about, and see if you are able to access it through the browser.
If so, then check for the certificate being used in the browser and check that certificate is present in your java cacerts.
Hi i usually generated the root CA with openssl and never worked importing that into the cacerts with keytools. You can instead generate it with this application i made out of desperation (it's a Java 11 app):
https://github.com/kendarorg/JavaCaCertGenerator
Its only purpose is to replace the generation of the private key and the root certificate, in a form "fit" for cacerts. From there you can produce the various certificates for the addresses
I am trying to add an "XML File" datasource in Jaspersoft Studio 6.2 to a report which is actually a call to a REST service requiring a single parameter as part of the path.
if the image doesn't display here is a description:
The URL I use is like so : http://.../service/rest/report/
Options:
GET
Parameter:
name=id
value=$P{ReportID} (the parameter is already created with a default value)
When I try to test it, this is what happens
net.sf.jasperreports.engine.JRRuntimeException: 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
at net.sf.jasperreports.data.http.HttpDataConnection.getInputStream(HttpDataConnection.java:101)
at net.sf.jasperreports.data.DataFileStream.<init>(DataFileStream.java:47)
at net.sf.jasperreports.data.DataFileUtils.getDataStream(DataFileUtils.java:62)
at net.sf.jasperreports.data.xml.XmlDataAdapterService.loadDataDocument(XmlDataAdapterService.java:140)
at net.sf.jasperreports.data.xml.XmlDataAdapterService.contributeParameters(XmlDataAdapterService.java:70)
at net.sf.jasperreports.data.AbstractDataAdapterService.test(AbstractDataAdapterService.java:105)
at com.jaspersoft.studio.data.wizard.AbstractDataAdapterWizard$3.runOperations(AbstractDataAdapterWizard.java:162)
at com.jaspersoft.studio.utils.jobs.CheckedRunnableWithProgress$1.run(CheckedRunnableWithProgress.java:59)
at java.lang.Thread.run(Thread.java:745)
I know this should work. I can call the service in a browser using .../report/?id=xx and I get back the expected XML data. I have also tested this using the "WebService Data Source" plug-in found on the community.jaspersoft.com site - that works as well in the Studio app (but I am unable to configure it on the server).
So the question is, how do I get around this SSL exception? My app server is internal and does not use SSL (still under development).
There a two ways to tackle this:
Ignore the certificate all together (Be aware that ignoring the error makes you vulnerable to MITM attacks)
Add the certificate to your keystore of the corresponding JVM
For more details take a look here: How to ignore PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException?
Basic put object calls suddenly stopped working (sometimes it succeds). It has been working since long.
Looks like a SSL cert issue.
Stack Trace snippet.
org.jets3t.service.S3ServiceException: S3 PUT connection failed for '/s3_request_message-38afbd8e-7d65-428a-a708-5d34104ded95-4912660956668093023.xml'
at org.jets3t.service.impl.rest.httpclient.RestS3Service.performRequest(RestS3Service.java:516)
at org.jets3t.service.impl.rest.httpclient.RestS3Service.performRestPut(RestS3Service.java:800)
at org.jets3t.service.impl.rest.httpclient.RestS3Service.createObjectImpl(RestS3Service.java:1399)
at org.jets3t.service.impl.rest.httpclient.RestS3Service.putObjectImpl(RestS3Service.java:1317)
at org.jets3t.service.S3Service.putObject(S3Service.java:1661)
at org.jets3t.service.S3Service.putObject(S3Service.java:1914)
at com.amazon.lm.utils.aws.S3Box.putFile(S3Box.java:111)
at com.amazon.lm.engine.LMEngine.copyRequestS3(LMEngine.java:350)
at com.amazon.lm.engine.LMEngine.run(LMEngine.java:165)
at com.amazon.lm.engine.discover.DiscoveryEngine.run(DiscoveryEngine.java:156)
at com.amazon.lm.engine.discover.GoogleBaseSearch.run(GoogleBaseSearch.java:25)
at com.amazon.lm.ui.UIDiscoverTask.run(UIDiscoverTask.java:41)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.net.ssl.SSLPeerUnverifiedException: HTTPS hostname invalid: expected 'lm-requests-prod.s3.amazonaws.com', received '*.s3.amazonaws.com'
at org.apache.commons.httpclient.contrib.ssl.StrictSSLProtocolSocketFactory.verifyHostname(StrictSSLProtocolSocketFactory.java:293)
at org.apache.commons.httpclient.contrib.ssl.StrictSSLProtocolSocketFactory.createSocket(StrictSSLProtocolSocketFactory.java:215)
at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:707)
at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1361)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
at org.jets3t.service.impl.rest.httpclient.RestS3Service.performRequest(RestS3Service.java:342)
... 12 more
Looks like Java does not like the wildcard domain presented as '*.s3.amazonaws.com'
per Can Java connect to wildcard ssl... wildcards can be problematic with java.
But as said earlier, we have been using it since long time and suddenly started facing this issue, that too intermittently.
We are using following versions:
jdk: 1.6
jets3: 0.7
openssl:1.0
Has anyone faced this issue? If Yes, Is there any workaround?
This wasn't an issue with the AWSS3JavaClient code, based on the fact that the this problem was happening both with S3 library and with other Java S3 libraries, and the fact that SSL cert verification is done inside the JVM platform library code, not inside our S3 library code.
The problem is that our JVM's keystore didn't have the most recent certificate authorities (CAs) that allow the JVM to form a chain of trust for whatever cert we're getting from the S3 SSL endpoint. This is a fairly common problem with Java and SSL, since the JVM maintains it's own keystore (i.e. it doesn't use certs from the OS).
If you face this problem, try reproducing this issue with other JVMs. Whenever customers have seen this issue in the past, it's been because their local JVM keystore (the keystore ships with the JVM and contains the most recent certs and CAs) has been out of date. Upgrading to the latest JVM version has always fixed this in the past.
Try upgrading your JVM version to recent one, it should help because your keystore must have been expired! :)