We are able to call web service from postman or custom request generator. However, while connecting using IBM Integration bus we are getting below exception. Can some one help with this error.
Exception below:
"Web Service request has detected a SOCKET error whilst invoking a web
service located at host &1, on port &2, on path &3."
"javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.j: PKIX path
building failed: java.security.cert.CertPathBuilderException:
PKIXCertPathBuilderImpl could not build a valid CertPath.; internal
cause is: java.security.cert.CertPathValidatorException: The
certificate issued by CN=VeriSign Universal Root Certification
Authority, OU="(c) 2008 VeriSign, Inc. - For authorized use only",
OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US is not trusted;
internal cause is: java.security.cert.CertPathValidatorException:
Certificate chaining error"
To resolve this problem, you should add the certificate into your trust store.
To setup the truststore on broker :
https://www.ibm.com/support/knowledgecenter/SSMKHH_9.0.0/com.ibm.etools.mft.doc/ac56640_.htm
To retrieve the certificate of the service you are calling, you can ask for it to your contact, or you can just go to the ?wsdl page and directly save the certificate from chrome
PS : If it works for other tools, it is simply because IIB refuse all the untrusted connexions by default, while some other tool allow it.
Related
I try to run a microservice (based on Eclipse Microprofile) on OpenLiberty (v20.0.0.1/wlp-1.0.36.cl200120200108-0300) on Eclipse OpenJ9 VM, version 1.8.0_242-b08 (en_US))
I run the server as the official Docker image (open-liberty:kernel)
In my service I try to connect to another rest service via HTTPS
Client client = ClientBuilder.newClient();
client.target("https://myservice.foo.com/").request(....);
This throws the following exception:
javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException:
unable to find valid certification path to requested target
I already added the features 'transportSecurity-1.0' and 'ssl-1.0' into the server.xml file:
<featureManager>
<feature>jaxrs-2.1</feature>
<feature>microProfile-2.2</feature>
<feature>transportSecurity-1.0</feature>
<feature>ssl-1.0</feature>
</featureManager>
and I also tweaked the jvm.options file like this:
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=7777
-Dhttps.protocols=TLSv11,TLSv12
-Djdk.tls.client.protocols=TLSv11,TLSv12
-Dhttps.protocols=TLSv11,TLSv12
-Dcom.ibm.jsse2.overrideDefaultProtocol=TLSv11,TLSv12
But nothing helps to get rid of the exception.
How is the correct configuration for OpenLiberty to enable outgoing ssl connections?
Liberty doesn't trust anything over ssl by default, so unless the service you are connecting to uses an identical keystore/truststore file, or you've otherwise configured your service to trust the microservice in some way, you can get that exception. If this is the problem, something like this will probably be seen in messages.log as well:
com.ibm.ws.ssl.core.WSX509TrustManager E CWPKI0823E: SSL HANDSHAKE FAILURE: A signer with SubjectDN [CN=localhost, OU=oidcdemo_client, O=ibm, C=us] was sent from the host [localhost:19443]. The signer might need to be added to local trust store [/Users/tester/tmp/liberty/20003wlp/wlp/usr/servers/urlcheck/resources/security/key.p12], located in SSL configuration alias [defaultSSLConfig]. The extended error message from the SSL handshake exception is: [PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target].
How to manually patch up the truststore is documented here,
https://www.ibm.com/support/knowledgecenter/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/twlp_add_trust_cert.html
but what you will probably want to do in a docker environment is modify your images to either include a common keystore/truststore, or read one from outside somewhere (such as a kubernetes secret). By default, each docker image creates it's own unique key/truststore, and they won't be able to "talk" over ssl.
If you only need to communicate with services that have a certificate signed by a well-known authority, you can add
ENV SEC_TLS_TRUSTDEFAULTCERTS=true
to your Dockerfile (20.0003+) to enable that.
As mentioned by Bruce in the answer above, Liberty doesn't trust any certificates by default. If you are making outgoing connections from Liberty to a server, you either need to add their certificate to the truststore you have configured OR you need to trust the JRE's cacerts if the remote endpoint is using a certificate from a well-known CA.
When you say you are using Let's Encrypt certificates, do you mean the remote end-point is using them, or your Liberty server is?
If the remote end-point is, most JRE's cacerts include Let's Encrypt in their cacerts. If the Liberty server is using a certificate signed by Let's Encrypt, that doesn't really have an effect on the outgoing connection unless you are using mutual SSL authentication.
As an FYI, if you are using a certificate signed by Let's Encrypt in Liberty as the default certificate, we will be adding built-in support for the ACME protocol in a few releases. See here for progress: https://github.com/OpenLiberty/open-liberty/issues/9017
I observed while testing an external web service from my java program is returning:
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: timestamp check failed
But the same URL is accessible via Jmeter and SOAP UI. Based on some googling seems SOAP UI ignores hostname verification and expired certs checks but not getting enough information on Jmeter.
Does Jmeter ignores SSL handshakes error when certs are expired? Appreciate any help to enforce such validation.
By default JMeter doesn't do any check on certificate :
It accepts certificates invalid for current hosts
It accepts expired certificates
This is to allow using it in QA Environment where both conditions are very frequent
I am trying to use Web Service Task in SSIS/SSDT to use our company's Web Service. However I am getting this error: "The error is: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel..". I have installed the certificate to Trusted Root Certificates Authorities but I am still getting that error. I speculate that the issue stems from a mismatch name. Where the domain name does not match the name on the certificate I installed. Is there a solution for this or can I have SSIS/SSDT to ignore this certificate error?
When I run Fiddler to capture traffic between my server and client. I get the following warning message. How can I find out which certificate is causing the problem and how to fix the error?
Session #30: The remote server (server.mycompany.com) presented a certificate that did not validate, due to RemoteCertificateChainErrors.
0 - A certificate chain could not be built to a trusted root authority.
SUBJECT: CN=dev.server.mycompany.com, OU=Space, O=Company, L=NewYork, S=NY, C=US
ISSUER: CN=Space Test Authority, OU=Space, O=Company, L=NewYork, S=NY, C=US
I am currently working on a project that has the following components (all .NET 2.0)
Client Application
Web Service Invocation API
Web Service
In summary the Client Application creates and instance of the API and this calls the Web Service. Nice and simple and this all works exactly as I want it to.
The next stage of the project was to secure the Web Service with SSL. So I have created a "Self Signed CA" and from this signed a server certificate for IIS. Again, nice and simple and this all works exactly as I want it to.
The next stage of the project is to secure the Web Service by requiring the invoker to supply a client certificate. So I have created a client certificate (via the Self Signed CA). I am then adding this to the Web Service invocation call in the API:
WSBridge.Processor processor = new WSBridge.Processor();
processor.Url = this.endpoint;
processor.ClientCertificates.AddRange(this.clientCertificates);
processor.Timeout = (int)Settings.Default["DefaultTimeout"];
In debug I can see that this.clientCertificates contains the certificate I created. So in theory it is being presented to the web server.
However, when I attempt to call the Web Service I get the following exception in the API:
The request failed with HTTP status 403: Forbidden.
Fairly self explantory, but I have no idea what is causing the problem.
Other relevant information:
In my dev environment Client, API & Web Service are all running on the same machine
If I attempt to access the Web Service Description in IIS I get the following error (I am not prompted to choose a client certificate):
HTTP Error 403.7 - Forbidden
The page you are attempting to access requires your browser to have a Secure Sockets Layer (SSL) client certificate that the Web server recognizes.
The client certificate is loaded into the Personal store for the current user, the CA root is in trusted root for the local machine and current user.
If I switch off "Require SSL" and put "Client Certificates" on accept in IIS I can make my request. However when I look at HttpContext.Current.Request.ClientCertificate.Count in the Web Service this comes back as 0.
I need to be able to run my development with client certificates as portions of the service code use the CN of the client certificate to perform various actions. I could hack it in but it would be nice to be able to do a real end to end.
All the certificates mention here were generated using OpenSSL. I am developing on Windows 7 so I do not have the facility to install Microsoft CA
So, does anybody have any ideas as to the cause of this problem?
As an aside (not worth creating a new question for this) - for some reason when I enable SSL for the Web Service Visual Studio is no longer able to debug the service.
EDIT : Some more information
The client certificate has an intended purpose of <All>
Although I am working on localhost the server certificate for the web server was issued to devserver.xyz.com so I have changed my hosts file to point that to localhost. As such I can now browse (with client certs switched off in IIS) to my service descriptor page without seeing any SSL certificate warnings.
Well I have solved the problem, in summary this was due to the format of the client certificate this should have been PKCS12.
More Detail
Although the MMC Certificate plugin was showing the client certificate in the personal store for the current userm I noticed that when viewing the same store via Internet Explorer (Tools -> Internet Options -> Content -> Certificates) the certificate was not present.
After a little Googling it seems that IE will only accepts PKCS12 format for client certificates, so I convert the certificate with the following OpenSSL command:
openssl pkcs12 -export -in client_alpha.cer -inkey client_alpha.key -out client_alpha.p12
I then imported the p12 file into IE which allowed me to browse to the Web Service description page with full client/server certificated TLS.
Once I had made this change, I then retried by client application and this now works aswell. This is due to the fact that IIS, like IE, will only accept client certificates in PKCS12 format.