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.
Related
We are using commons-codec to encrypt passwords, using the org.apache.commons.codec.digest.Md5Crypt.md5Crypt function.
It works fine on a Windows environment, but on CentOS, an exception is thrown.
We have 3 centOS test servers: one is centOS7, one is centOS6.7, and one is centOS7 minimal.
The weirdest thing is, the code works on the centOS7 server, but not on the other two. The only difference between them is the OS. Same tomcats, same jdks, same builds.
Does it need any other things under linux?
The exception message:
java.lang.IllegalAccessError: tried to access method org.apache.commons.codec.digest.DigestUtils.getMd5Digest()Ljava/security/MessageDigest; from class org.apache.commons.codec.digest.Md5Crypt
have you checked the jar ? and the presence of the library ? Perhaps it was removed for some obscure security / patent / export reason ?
or, at least, something changed. It is a problem of incompatibility: see that:
java.lang.IllegalAccessError: tried to access method
Or you have already (loaded) this class, because you have multiple incompatible instances . Try to find it in your packages (caller function, or called)
but why not directly use the library ?
import java.security.*;
MessageDigest md = MessageDigest.getInstance("MD5");
byte[] thedigest = md.digest(_originebyte);
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().
We are getting an issue "Could not obtain an instance of KeyTabKeytab is corrupted" with JDK 1.6 or JDK 1.5.
The reason for this issue in JDK 1.6 or 1.5 was observed as that the method sun.security.krb5.internal.ktab.KeyTab.getInstance(java.lang.String s) which creates the instance for the keytab file was not able to load the keytab file properly, due to the reason that this method is not synchronized.
This issue was happening in our environment under 100 users load test consistently, I looked into the SUN code and found that synchronization for the method "sun.security.krb5.internal.ktab.KeyTab.getInstance(java.lang.String s)" is missing, it looks to be fixed in JDK 1.7 by making the KeyTab.getInstance(java.lang.String s) .
So to get around the above problem I have added sychronization in my code as shown below as I'm not sure how Sun libraries load the keyTab for each login context.
LoginContext loginContext = new LoginContext(contextName);
synchronized(KerberosUtility.class)
{
loginContext.login();
}
Since the method "sun.security.krb5.internal.ktab.KeyTab.getInstance(java.lang.String s)" is synchronized in JDK 1.7, I'm planning to remove the synchronization block in the above mentioned code snippet which is surrounded by loginContext.login().
Do you see any issues here if I remove the synchronization?
Had you come across this issue earlier and solutions for the same?
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.