We Keep Coding

com.ibm.jsse2.util.j: Certificate chaining error while accessing a page through https in notes agent

I have following situation - I want to get page content using https request and java agent. However, I'm getting following error message:
javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.j: Certificate chaining error
I already imported internet certificates to my local notes cacerts file, but nothing changed.
However, when I'm running same code in Eclipse, using keystore with certificates downloaded from page I try to receive and it works fine.
I'm out of ideas, any suggestions will be appreciated!
===EDIT===
Dmytro Pastovenskyi's answer helped me, but additionally to get rid of protocol_version exception I had to use following code, setting version of TLS used:
System.setProperty("https.protocols", "TLSv1");
It seems nessesary to establish connection to some sites using 1.6 IBM JAVA.

I had same issue some times before.
It looks like IBM Domino server more strict when it check certificates. Our administrator who at the beginning said that chain is correct later found an issue with chain (and yes, it worked for .NET/JAVA and other platform, just not with Domino). Try to find some online tools that verify chain.
Before chain is fixed you can simply disabled certificate validation. I've an article how to do it (+ some other articles that may help you). Have a look here: Disabling certificate validation in Java

How to find weblogic t3 adminurl

I have a weblogic folder, From this - How can i find the adminurl that I can use with the below command
java weblogic.Deployer –adminurl t3://server:7001 –username system –password weblogic –listapps
I tried looking into setupinfo.txt, portlist.ini - but somehow this did not help/work. How can get this working?
I get errors/exceptions like these (after few attempts)
The loading of the trusted certificate list raised a certificate parsing exception PKIX: Unsupported OID in the AlgorithmIdentifier object
Unable to connect to 'http://server:7001': Destination unreachable; java.net.ConnectException: Tried all: 1 addresses, but could not connect over HTTPS to server: localhost port: 7102; No available router to destination
based on setupinfo.txt, I am able to login to the web console - but I need to know how to get this command working with adminurl !!!
Thanks,

Got it, thanks Alex.
Steps
Find startscript.xml under your weblogic domain , search this file for "ADMIN_URL"
The same can be done by web console UI ..... Admin Console Login to AdminConsole->Server->Configuration->ListenPort (enable and note down the port)
Bingo.

Client Certificate using Weblogic

Background:
I am working on a project that involves the client to authenticate itself (via client certificate). We are trying to launch a third party app which first authenticates the client cert and then launches its app.
We are using Java and SSL hanshake, and our client server is Weblogic 10.x. The client certificate is in PKCS12 format (cannot change this)
This is the piece of code for presenting the certificate:
System.setProperty("javax.net.ssl.keyStore","MyPath/cert.pfx");
System.setProperty("javax.net.ssl.keyStorePassword","MyPwd");
System.setProperty("javax.net.ssl.keyStoreType","PKCS12");
url.openConnection();
Now all this works pretty well from a standalone. The problem starts when we put this on weblogic. Sometimes it works, sometimes 'Client certificate not present' (http 403.7) is returned. I have tried various combinations (including configuring custome keystore on weblogic console) but nothing seems to work. Any idea why would weblogic altogether ignore the SSL settings (it doesnt throw an error even if I set keystore to a non-existent file)? System.setProperty for SSL just appears useless on weblogic!

In Weblogic 12c you also need add the parameter -DUseSunHttpHandler=true in order to tell the weblogic server to use the Sun Http Handlers instead of its own. Therefore you need the following Java VM parameters:
-Djavax.net.ssl.keyStore=MyPath/cert.pfx
-Djavax.net.ssl.keyStoreType=PKCS12
-Djavax.net.ssl.keyStorePassword=MyPwd
-DUseSunHttpHandler=true

Finally found the solution! Weblogic seems to over-ride the keystore configurations if it is done through Java as above. The thing that worked for me was to configure the SSL settings on JVM level, at web-logic start-up.
To make it work, I just added these Java options in the start-script for weblogic:
-Djavax.net.ssl.keyStore=MyPath/cert.pfx
-Djavax.net.ssl.keyStoreType=MyPwd
-Djavax.net.ssl.keyStorePassword=PKCS12
Restarted web-logic and SSL has been working great since then :)

What would cause SSL negotiations to succeed under .NET but fail under Java?

We have to create a web service client using Apache CXF in Java. The thing is I cannot seem to get the SSL session to properly engage. Either it fails altogether, the server fails to decipher what is sent to it once the application data is transmitted or I fail to read the responses from the server.
However when trying the same transaction using a simple soap test client built in .NET everything runs smoothly.
Server is using double authentication.
Everything is certificate based (x509) stored in the windows certificate store (windows-MY and windows-ROOT)
edit
yes, double authentication is indeed client AND server authentication.
Thus far using the bountyCastle provider instead of SunMSCAPI seems to get further but still cannot get the client authentication to work.
PLatform of client CXF 2.2.9, Sun JDK 1.6_21
server IIS 6 ASP.NET unfortunately is all I could gather, I have no control over the server and must use it as-is.
update
I am using a JKS keystore now but still am getting the problem. It seems the client is not sending his certificate to the server as part of the authentication process. As a result I get a 403.7 error from the server.
Funny thing is that I receive this error message as an HTML page that must first be decrypted before it is readable !

Presumably, by double authentication, you mean you're using client-certificate authentication in addition to server-certificate authentication (which is more common).
It would be useful to know which versions of the platforms are used on either side, and which patches have been applied.
It's possible that some of the problem come from the re-negotiation fix to CVE-2009-3555 (or lack of fix).
The problem is a flaw in the initial design of the re-negotiation in TLS, which is what was used to re-negotiate a client-certificate. There are two ways of getting a client-certificate: either the server asks for it during the initial TLS handshake, or it asks for it during a subsequent handshake (for example, once it has figured out what the request was aimed for and/or when trying to access a certain restricted area). The second method is the re-negotiation. Unfortunately, there was a security flaw in the design of the TLS protocol in that respect, which has since been fixed thanks to a TLS extension described in RFC 5746.
When the flaw was initially disclosed (around November 2009), some platforms and libraries such as Sun Java or OpenSSL rolled out a quick fix which simply disallowed any re-negotiation (so only initial negotiation of the client-certificate would work). Later on, once RFC 5746 was written, these libraries started to roll out implementations supporting this extension.
As far as I'm aware, Microsoft's default in IIS and its web framework was to use re-negotiation and not initial negotiation. In addition, it didn't roll out the initial fix to disable re-negotiation (effectively keeping the known vulnerability). It only rolled out a patch (still tolerant to old implementations by default) quite recently: Microsoft Security Bulletin MS10-049 - Critical.
There is also an explanation of the problem on this Microsoft security blog:
http://blogs.technet.com/b/srd/archive/2010/08/10/ms10-049-an-inside-look-at-cve-2009-3555-the-tls-renegotiation-vulnerability.aspx
Essentially, if you're trying to talk to a server that only supports the old negotiation style from a stack that only has the new re-negotiation style or no renegotiation at all, it's not going to work.
If your server is running using IIS or similar environment, you might be able to turn on initial client-certificate negotiation using netsh and its clientcertnegotiation=enable option.

Java doesn't rely on the OS certificate store and needs to use its own.
This will import your self-signed certificates.
cd JAVA_HOME/jre/lib/security
keytool -import -file server_cert.cer -keystore cacerts

I post this as an answer though I realize now the question was not formulated properly as I got thrown in a loop because the .NET example I had was actually performing a hack to get around the problem.
The proper question should have been
How to get Java to perform Client side Authentication on a server that does not ask for Ask for certificates ?
the answer is actually under our very noses, however to get to the answer one needs the correct question !!
Great thanks to Bruno who provided some very helpful information.
the solution can pretty much be summed up in these two questions :
Java HTTPS client certificate authentication
Client SSL authentication causing 403.7 error from IIS
Although the client is "not supposed" to send a certificate if not asked I found that by tweaking the client certificate in the keystore to contain the following :
Client certificate with all extensions
Client Private key
A concatenation of the client's complete certification chain.
push all this in the same certificate store and use it as keystore. Then load again the certification chain as a trust store. From there it should just work. This being said there is still a possibility for failure. the safest way to solve this particular issue is to have the server actively ask for a authentication certificate from the client by providing a list of accepted CA.
Hope this helps anyone else that can be stuck in the same problem, sure tooke me for a spin for a while before I reach the root of evil.

Simple Java Web Service client over HTTPS

I am connecting to a simple XML over HTTPS web service and getting a security exception. My question is whether you think the cause of this is the cert on the web server, so I should talk to the server admin or if my client code should be handling this. I would love to hear if anyone has encountered and solved this issue. Is the solution found on client side or server side? Below is the exception.
Caused by: sun.security.validator.ValidatorException: Violated path length constraints
at sun.security.validator.SimpleValidator.checkBasicConstraints(SimpleValidator.java:243)
at sun.security.validator.SimpleValidator.checkExtensions(SimpleValidator.java:158)
at sun.security.validator.SimpleValidator.engineValidate(SimpleValidator.java:143)
at sun.security.validator.Validator.validate(Validator.java:202)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(DashoA12275)
at com.sun.net.ssl.internal.ssl.JsseX509TrustManager.checkServerTrusted(DashoA12275)
Thanks for any advice.

It's probably worth testing the client side first with openssl
openssl s_client -connect yourserver.com:443
Check out the man page for further options.
What happens when you access it with a web browser? Firefox should provide you quite some information on the server cert.
While it does not seem like you after client cert authentication this examples does show you how to use a custom SSLSocketFactory. It can also be set statically - if you don't have access to the connection.

From the stack trace, I would guess that it's a problem with the server's certificate (the trace originates from "checkServerTrusted" calls). You might want to try connecting to the URL with a web browser such as Firefox to see if you get an SSL error with more details.