All in a sudden my Java application using SimpleDB doesn't work anymore. I'm using Java AWS SDK version 1.2.4 on Windows 7. I've the following exception:
java.security.KeyStoreException: problem accessing trust storejava.io.IOException: Invalid keystore format
com.sun.net.ssl.internal.ssl.TrustManagerFactoryImpl.engineInit(TrustManagerFactoryImpl.java:55)
javax.net.ssl.TrustManagerFactory.init(TrustManagerFactory.java:230)
org.apache.http.conn.ssl.SSLSocketFactory.createSSLContext(SSLSocketFactory.java:190)
org.apache.http.conn.ssl.SSLSocketFactory.createDefaultSSLContext(SSLSocketFactory.java:209)
org.apache.http.conn.ssl.SSLSocketFactory.<init>(SSLSocketFactory.java:333)
org.apache.http.conn.ssl.SSLSocketFactory.getSocketFactory(SSLSocketFactory.java:165)
org.apache.http.impl.conn.SchemeRegistryFactory.createDefault(SchemeRegistryFactory.java:45)
org.apache.http.impl.conn.tsccm.ThreadSafeClientConnManager.<init>(ThreadSafeClientConnManager.java:98)
com.amazonaws.http.HttpClientFactory.createHttpClient(HttpClientFactory.java:67)
com.amazonaws.http.AmazonHttpClient.<init>(AmazonHttpClient.java:111)
com.amazonaws.AmazonWebServiceClient.<init>(AmazonWebServiceClient.java:59)
com.amazonaws.services.simpledb.AmazonSimpleDBClient.<init>(AmazonSimpleDBClient.java:118)
What could the cause be and how to solve the problem?
Sorry for self answer, but I solved the problem. It was caused by my certificate file, pointed by these statements loaded by a ServletContextListener defined in my web.xml
String sslCertPath = contextEvent.getServletContext().getRealPath(
"/WEB-INF/classes/jssecacerts");
System.setProperty("javax.net.ssl.trustStore", sslCertPath);
Commenting out those lines everything works. This is caused by a corruption of that file.
After that, I fixed my key store, uncommented the lines, had a little fight with tomcat and after that everything was working again, also with my certificates in place.
Related
We are successfully using the AmazonPay API for Java (amazon-pay-api-sdk-java-2.2.2.jar) in Adobe ColdFusion. We recently introduced Lucee (on Jetty, also running on OpenJDK 8) and attempted to run the same code (relevant excerpt):
payConfig = createObject("java", "com.amazon.pay.api.PayConfiguration").init();
payConfig.setPrivateKey("...");
However, upon calling setPrivateKey, which will arrive at Security.addProvider(new BouncyCastleProvider()); through PayConfiguration, we receive a java.lang.ClassNotFoundException:
lucee.runtime.exp.NativeException: org.bouncycastle.jce.provider.BouncyCastleProvider
at com.amazon.pay.api.PayConfiguration.setPrivateKey(PayConfiguration.java:77)
[...]
at java.lang.Thread.run(Thread.java:823)
Caused by: java.lang.NoClassDefFoundError: org.bouncycastle.jce.provider.BouncyCastleProvider
... 57 more
Caused by: java.lang.ClassNotFoundException: org.bouncycastle.jce.provider.BouncyCastleProvider not found by amazon.pay.api.sdk.java.2.2.2 [49]
at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1597)
at org.apache.felix.framework.BundleWiringImpl.access$300(BundleWiringImpl.java:79)
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1982)
at java.lang.ClassLoader.loadClass(ClassLoader.java:881)
... 57 more
We have placed all dependencies (bcprov-jdk15on-1.65.jar being BouncyCastle) in /lucee-server/context/lib. Creating BouncyCastleProvider within a .cfm/.cfc does work as expected:
createObject("java", "org.bouncycastle.jce.provider.BouncyCastleProvider").init()
I don't understand what Lucee's classloader is doing here. What am I missing?
I don't know what Lucee's classloader is doing either to be honest, but this kind of error seems to be quite common when loading certain more complex jars via the Lucee /lib path. It's likely there are "class clashes" going on somewhere.
Lucee is now OSGi based which means the best way of avoiding this is to load third-party java libraries as OSGi bundles. Some libraries are already packaged for OSGi and others can be converted fairly easily. More details here.
The Amazon library doesn't seem to be OSGi friendly, although it could probably be converted without too much effort.
For now, I would look at JavaLoader as the simplest way of getting it working. I don't have any valid Amazon keys to test fully with, but using JavaLoader I was able to at least call the payConfig.setPrivateKey() method without getting a ClassNotFoundException error.
I'm using jCifs 1.3.17 to connect and list files on remote windows share.
Everything works fine on my local JRE(5,6,7), but the same code executed on oracle 11g database (11.2.0.3.0) crashes with following stack:
jcifs.smb.SmbAuthException: Logon failure: unknown user name or bad
password. at
jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:546) at
jcifs.smb.SmbTransport.send(SmbTransport.java) at
jcifs.smb.SmbSession.sessionSetup(SmbSession.java) at
jcifs.smb.SmbSession.send(SmbSession.java:218) at
jcifs.smb.SmbTree.treeConnect(SmbTree.java:176) at
jcifs.smb.SmbFile.doConnect(SmbFile.java:911) at
jcifs.smb.SmbFile.connect(SmbFile.java:954) at
jcifs.smb.SmbFile.connect0(SmbFile.java:880) at
jcifs.smb.SmbFile.exists(SmbFile.java) at
pl.openlife.CifsConnect.listCIFSFiles(CifsConnect.java:49)
I found out, that user password lenght might cause the problem:
1. Windows env jdk1.5.0_22 -> works with long passwords
2. Oracle linux, RDMS embeded JVM -> works with short password only (8 characters)
3. Oracle linux, RDMS embeded JVM -> long password fails with error shown above.
Sample code:
NtlmPasswordAuthentication auth = new NtlmPasswordAuthentication(domain,
username,
password);
SmbFile dir = new SmbFile(path,auth);
if(!dir.exists()){
// ABOVE CHECK FAILS
}
I heard somewhere about problems with oracle embedded jvm and bugs in JCE, but this shouldn't be the case, as jcifs have its own implementation of algorithms such as RC4 or DES. Does anyone have a clue what can be the case? Is there a way to walk this around?
Unfortunately I didn't find any answer to the issue mentioned above.
As a walkaround, I have used older version of jcifs (jcifs-1.2.25), which seems to work properly with oracle db embedded jvm.
UPDATE:
I have imported jcifs lib again (1.3.17) and it is working like a charm. I ended up with conclusion, that the java library was not imported properly. Reimport (loadjava) with option "-force" and manual compilation of invalid objects solves the problem always, but (I cant't figure why) in my case it must be loaded in following order :
1. Load my program lib (will cause errors)
2. Load jcifs lib with force option
3. compile and resolve
It seems that oracle jvm is unpredictable :)
I am working on a game and I am using the Slick2D library. I am also using bouncycastle for encryption. Then I use jarsplice to package everything together in a nice executable. And it runs fine until it needs to encrypt something. It gives me a java.lang.SecurityException: JCE cannot authenticate the provider BC And I am using a signed jarfile (http://www.bouncycastle.org/download/bcprov-jdk15on-150.jar)
Here is the stack trace
java.lang.SecurityException: JCE cannot authenticate the provider BC
at javax.crypto.Cipher.getInstance(Cipher.java:642)
at javax.crypto.Cipher.getInstance(Cipher.java:580)
at net.matrixstudios.zenerith.networking.ZenerithLogin.encryptLogin(ZenerithLogin.java:159)
at net.matrixstudios.zenerith.networking.ZenerithLogin.<init>(ZenerithLogin.java:112)
at net.matrixstudios.zenerith.MultiplayerMenu$1.performAction(MultiplayerMenu.java:90)
at net.matrixstudios.zenerith.gui.menu.MenuGameState.clickButton(MenuGameState.java:83)
at net.matrixstudios.zenerith.gui.menu.MenuGameState.checkForButtonClicks(MenuGameState.java:75)
at net.matrixstudios.zenerith.gui.menu.MenuGameState.update(MenuGameState.java:51)
at net.matrixstudios.zenerith.gui.menu.AbstractGameState.update(AbstractGameState.java:47)
at org.newdawn.slick.state.StateBasedGame.update(StateBasedGame.java:266)
at org.newdawn.slick.GameContainer.updateAndRender(GameContainer.java:663)
at org.newdawn.slick.AppGameContainer.gameLoop(AppGameContainer.java:411)
at org.newdawn.slick.AppGameContainer.start(AppGameContainer.java:321)
at net.matrixstudios.zenerith.gui.Window.<init>(Window.java:28)
at net.matrixstudios.Main.main(Main.java:28)
Caused by: java.util.jar.JarException: file:/C:/Users/M4trixSh4d0w/Desktop/Zenerith_Alpha.0.2.1.5.jar has unsigned entries - org/bouncycastle/LICENSE.class
at javax.crypto.JarVerifier.verifySingleJar(JarVerifier.java:462)
at javax.crypto.JarVerifier.verifyJars(JarVerifier.java:322)
at javax.crypto.JarVerifier.verify(JarVerifier.java:250)
at javax.crypto.JceSecurity.verifyProviderJar(JceSecurity.java:161)
at javax.crypto.JceSecurity.getVerificationResult(JceSecurity.java:187)
at javax.crypto.Cipher.getInstance(Cipher.java:638)
... 14 more
So how do I authenticate the jarfile to run?
This is a standalone executable jarfile.
I'm a Android developer, got this error when I upgraded the compile and build tool to Android 12 (31), I tried lots of ways to fix it and finally I found the only way that works is changing the JDK to the version of 11.0.14.1 (x86_64), I worked on Mac M1, the downloading link of this version is: https://docs.aws.amazon.com/corretto/latest/corretto-11-ug/downloads-list.html
You probably want to register the cryptographic service provider at runtime to ensure the configuration will work for everyone. You can use either of the Security.addProvider() or Security.insertProviderAt() methods. See documentation linked below under "Managing Providers".
http://docs.oracle.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html#Provider
Just use addProvider() unless the order of providers is somehow important for you. I saw one contributor commented that you might slot it in at entry #9, but I didn't see evidence that this is right for your configuration, so probably just an extraneous detail from his/her config file. Obviously, if I missed something about your configuration and you do need it there, then go for insertProviderAt().
I have an application that worked perfectly up now! but now it raises No such a provider exception on this line of code:
Cipher.getInstance("AES/CBC/PKCS5Padding", "BC");
BouncyCastle is installed correctly and the strange thing is only in this application it creates Exception! in others it works at the same time on the same machine with the same JRE!!!
What is the problem?
The Ubuntu software update system may have changed your Java configuration.
Use the -verbose flag to see if all classes are loaded from the location you expect.
It is a conundrum!
I have an applet in a JAR. When JAR is signed - be it self-signed or with a DigiCert sertificate - I get a ClassNotFoundException on the main applet class.
When I don't sign the applet, it loads just fine - (not counting the expected SecurityException due to the code not being signed).
But I can unpack the signed JAR and find everything to be where it is supposed to be.
The strangest part is that up until last week the set-up worked just fine.
Same main class, self-signed, same deployment mix of JS/HTML etc.
Any thoughts?
Here is the error message:
java.lang.ClassNotFoundException: com.spraklab.ilos.applet.Applet
at sun.plugin2.applet.Applet2ClassLoader.findClass(Applet2ClassLoader.java:195)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Plugin2ClassLoader.java:249)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Plugin2ClassLoader.java:179)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Plugin2ClassLoader.java:160)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Plugin2ClassLoader.java:690)
at sun.plugin2.applet.Plugin2Manager.createApplet(Plugin2Manager.java:3045)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Plugin2Manager.java:1497)
at java.lang.Thread.run(Thread.java:680)
In the code above you are trying to switch secure applet classloader. That is not allowed since Java 1.2.
Short version:
No hyphens in JAR-names!
The dramatic story:
Finally! Many work-days after the problem was discovered.
The applet loaded fine when not signed, bud ClassNotFoundException when signed.
The answer about the switching of classloaders led me to believe that there was something I had changed in my code. So I stripped my code down to a minumum.
But to avoid having to restart my browser all the time and empty the cache etc, I simply used the incognito-mode of Chrome. I rebuilt the code. And everything was fine in the end. Not!
When I then tested it outside of incognito, I got the error again.
So what was the difference? An examination of the server logs showed that the Jar simply wasn't being requested from the server when in regular mode!
I compared my code once again against an different app with similar embed-code, and saw only one difference: I was using a hyphen in stead of an underscore in the JAR-name - which should be allowed, and which had worked fine up until about 2 weeks ago.
But wasn't there also a Java update about 2 weeks ago ...?!?!