Exception while configuring signer certifiate in WebSphere - java

I have to call a webservice to purge files (delete from its child servers also) from remote server. In that course I am using a URL which has https in it.
WebSphere throws a java.security.cert.CertPathValidatorException: Certificate chaining error.
Later I found and configured signer certificate, By retrieving the certificate information using host name and port number. I saved this new singer certificate and after that i didnt get that exception.
But the problem is in some WebSphere am able to do this and in some am not able to do. In other I am getting this error: DerInputStream.getLength(): lengthTag=127, too big.
So here is my question why am not able to configure in other WebSphere, what could be the reason? am I doing it in wrong way?

DerInputStream.getLength(): lengthTag=127, too big.
This is because the certificate you are trying to import is not a DER format file. I got this error with a PKCS7 file.

Related

Does C# HttpClient ignore SSL certificate errors?

We have an internal web service hosted on https with an authorized root CA. When I tried to call that service from Java Apache HttpClient, it gave me the cert error "PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target".
Using SSL tools, I found out that the web service is sending the cert chain without the intermediate cert and it contains only server cert. So the Java cert error made sense because, only the root CA is present in Java truststore and it is unable to verify the cert chain, hence the error.
But on the other hand, I can call the same web service using C# HttpClient (.Net 4.6.1) without any issues.
Is C# HttpClient ignoring the cert issues with the web service or is it downloading the missing cert? Can anyone please shed some light on this?
Figured this out with very helpful comments from Stephen and Mark. I set up the trace in app.config where I found that C# HttpClient could find the intermediate certificate.
"System.Net Information: 0 : [23580] SecureChannel#41622463 - Remote certificate was verified as valid by the user."
But I had already verified that the intermediate cert wasn't present in Windows cert store which had led to this confusion. I checked there again and turns out the cert was under My User Account and not Computer Account. It must have been installed there when our company desktops were set up.
Now I am not really sure about the difference between the usage of these two cert stores in Windows, but at least I understand how C# client found the cert.

com.ibm.jsse2.util no trusted certificate found

I created a java agent that needs to connect to an API internaly. The protocol used is HTTPS. When the agent tries to connect to the API it throws the following error:
com.ibm.jsse2.util: no trusted certificate found. This all is running on a Domino 9.0.1fp3 server. The SSL certificate is a self signed certificate with a custom certificate authority.
I tried the following solution http://www-01.ibm.com/support/docview.wss?uid=swg21588966 but to no success. Even when we restarted the server it does not correctly pick up the certificate chain. As a last resort we created a little java class that ignores SSL certificates that are self signed. But ofcourse this is not a great solution.
I was wondering if someone also encountered this issue and knows how to solve it.
Apparently IBM forgot to mention that you actually need to restart the whole server for this to work....

Is it possible to merge java\jre\security\lib\cacerts file

In my project,I have integrated Spring Security with CAS server authentication. Now my project is an http application where as the CAS server is an Https application. I was getting following exception after Spring Security and CAS integration: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
In order to solve this error ,I replaced CAS server usr\java\jre\lib\security\cacerts file with my local usr\java\jre\lib\security\cacerts file. After this step the error was gone.
Now I want to deploy my application to some other server. In this new server some other applications are also deployed which may be using different CAS authentication. I cannot directly replace my CAS server cacerts file with this new server cacerts file as in that other application deployed may fail.Right? Can anyone suggest what should I do so that cacerts can be merged,or what should be done? i got to know a command called as keytool but unable to understand how it could be used to merge cacerts file. I dont know how to get my CAS server .cer file,I got to know this could be used in merging,please suggest solution
There is a missunderstanding here.
cacerts is Java's default truststore containing all the trusted certificates for known CA's (Verisign etc). So java can by default trust these certificates same way that your browser does.
This truststore should be used when you want to connect to servers that are signed by these CAs.
In all other cases you are expected to use your own custom truststore so that you can trust specific servers.Actually this is the norm.
So what you should be doing is to load in your code your own truststore and provide that to Java's JSSE to use for authentication during handshake

ssl certificate error: unable to get local issuer certificate

This website, https://dcs1.noaa.gov, recently updated their SSL certification. Since that change I cannot grab a file from there that I need. I get the following error:
--08:37:12-- https://dcs1.noaa.gov/pdts_compressed.txt
=> `pdts_compressed.txt'
Resolving dcs1.noaa.gov... 205.156.2.181
Connecting to dcs1.noaa.gov|205.156.2.181|:443... connected.
ERROR: Certificate verification error for dcs1.noaa.gov: unable to get local issuer certificate
To connect to dcs1.noaa.gov insecurely, use `--no-check-certificate'.
Unable to establish SSL connection.
I am running Red Hat Linux 4.x and updated all the openssl packages. The usual process I use to access this file is running in Java and uses URL.openStream() to read the file. The command wget also does not work so I am assuming that it is an SSL problem and not a java problem.
the cert is issued by Verisign, probably their root cert is in your servers root cert store. Open the webpage from your machine from a browser and you will see the cert is valid. You can also try to wget from another machine and it will work too.
Probably, the new server certificate is issued by an issuing authority that is not trusted by you. You need to import the issuing authority's certificate in your truststore.
You could try testing the SSL connection with openssl's s_client. I recently had a similar problem and had it resolved. Here's a link to that solution. It also includes information on how to use the s_client to test an SSL connection.
SSL Error: unable to get local issuer certificate

Will client JVM for a web service(https) throw an SSL Exception when the server is having a valid certificate from a CA?

I have a web service deployed on tomcat hosted on a remote server.
I have set it up such that it can be accessed only via HTTPS.
For this, I generated a Certificate Signing Request (CSR) and used it to get a temporary certificate from VeriSign.
My web service client is on my local machine. If I try to access the service it will throw a javax.net.ssl.SSLHandshakeException:unable to find valid certification path to requested target
If I install the certificate in to local Java's keystore, the issue will be resolved.
My question is if I install a valid SSL certificate from a CA in to my tomcat server,
will I get this client-side error even if I do not import the certificate to local key store?
No, you won't. JVM ships with root ca's by default. The older JVMs (1.5.xx version) don't have all root CA's, but if you have a certificate from Verisign it shouldn't be a problem.
Java has many root CA certificates already installed. As long as you use one of those popular CAs to get your certificate, the client will not receive an error.
While you should be fine, its a good idea to include not only the actual certificate for your site, but also the entire chain leading up to the root certificate. (Sometimes you'll bump into clients which are missing some intermediate certificates and this can cause annoying debugging problems.)

Categories

Resources