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.
When submitting my app to AppStore I get this message from Apple:
ITMS-90238: Invalid Signature - The executable at path MyApp.app/Contents/PlugIns/adoptopenjdk-8.jdk/Contents/Home/jre/lib/libfreetype.dylib.6 has following signing error(s): valid on disk /Volumes/data01/app_data/app-processing/mz_16965903542122982835dir/mz_15396195148822940240dir/myPackage.pkg/Payload/MyApp.app/Contents/PlugIns/adoptopenjdk-8.jdk/Contents/Home/jre/lib/libfreetype.dylib.6: satisfies its Designated Requirement test-requirement: code failed to satisfy specified code requirement(s) . Refer to the Code Signing and Application Sandboxing Guide at http://developer.apple.com/library/mac/#documentation/Security/Conceptual/CodeSigningGuide/AboutCS/AboutCS.html and Technical Note 2206 at https://developer.apple.com/library/mac/technotes/tn2206/_index.html for more information.
The app is submitting just fine with Oracle JDK hence there must be something special with this libfreetype.dylib.6 file.
It seems there are 2 files libfreetype.dylib.6 and libfreetype.6.dylib with identical content within AdoptOpenJDK. I was using a filter for signing *.dylib files and hence the libfreetype.dylib.6 file was not included within the filter and hence not signed. By updating the filter to also include *.dylib.* the problem was solved.
This problem did not appear with Oracle JDK because on Mac OS X it does not distribute the libfreetype library.
I'm working on a scala application with an SSH2 connection using sshj (0.19.1). I can connect fine from within eclipse, but running the application from a fat jar, I'm getting some errors. My initial error was:
Line 3: TransportException: null
at net.schmizz.sshj.transport.TransportException$1.chain(33)
at net.schmizz.sshj.transport.TransportException$1.chain(27)
at net.schmizz.concurrent.Promise.deliverError(96)
at net.schmizz.concurrent.Event.deliverError(74)
at net.schmizz.concurrent.ErrorDeliveryUtil.alertEvents(34)
at net.schmizz.sshj.transport.KeyExchanger.notifyError(386)
at net.schmizz.sshj.transport.TransportImpl.die(596)
at net.schmizz.sshj.transport.Reader.run(68)
I've added US_export_policy.jar and local_policy.jar to $JAVA_HOME/lib/security. I've added the following to try to register bouncycastle as a provider,
import org.bouncycastle.jce.provider.BouncyCastleProvider
val bouncyCastle = new BouncyCastleProvider()
java.security.Security.addProvider(bouncyCastle)
net.schmizz.sshj.common.SecurityUtils.registerSecurityProvider("org.bouncycastle.jce.provider.BouncyCastleProvider")
but I'm still getting the following errors:
INFO n.schmizz.sshj.common.SecurityUtils - Registration of Security Provider 'org.bouncycastle.jce.provider.BouncyCastleProvider' unexpectedly failed
INFO n.schmizz.sshj.common.SecurityUtils - BouncyCastle not registered, using the default JCE provider
INFO n.s.sshj.transport.random.JCERandom - Creating new SecureRandom.
WARN net.schmizz.sshj.DefaultConfig - Illegal key size
WARN net.schmizz.sshj.DefaultConfig - Cannot find any provider supporting Twofish/CBC/NoPadding
...
WARN net.schmizz.sshj.DefaultConfig - Illegal key size or default parameters
WARN net.schmizz.sshj.DefaultConfig - Disabling high-strength ciphers: cipher strengths apparently limited by JCE policy
INFO n.s.sshj.transport.TransportImpl - Client identity string: SSH-2.0-SSHJ_0.19.1
INFO n.s.sshj.transport.TransportImpl - Server identity string: SSH-2.0-OpenSSH_6.6.1
ERROR n.s.sshj.transport.TransportImpl - Dying because - {}
net.schmizz.sshj.common.SSHRuntimeException: BouncyCastle is required to read a key of type ecdsa-sha2-nistp256
at net.schmizz.sshj.common.Buffer.readPublicKey(Buffer.java:431)
at net.schmizz.sshj.transport.kex.AbstractDHG.next(AbstractDHG.java:66)
at net.schmizz.sshj.transport.KeyExchanger.handle(KeyExchanger.java:358)
at net.schmizz.sshj.transport.TransportImpl.handle(TransportImpl.java:493)
at net.schmizz.sshj.transport.Decoder.decode(Decoder.java:104)
at net.schmizz.sshj.transport.Decoder.received(Decoder.java:172)
at net.schmizz.sshj.transport.Reader.run(Reader.java:60)
Caused by: java.security.GeneralSecurityException: BouncyCastle is required to read a key of type ecdsa-sha2-nistp256
at net.schmizz.sshj.common.KeyType$3.readPubKeyFromBuffer(KeyType.java:120)
at net.schmizz.sshj.common.Buffer.readPublicKey(Buffer.java:429)
... 6 common frames omitted
INFO n.s.sshj.transport.TransportImpl - Disconnected - UNKNOWN
ERROR net.schmizz.concurrent.Promise - <<kex done>> woke to: net.schmizz.sshj.transport.TransportException: BouncyCastle is required to read a key of type ecdsa-sha2-nistp256
I'm running the jar as java -cp ../lib/bcprov-jdk15on-1.51.jar -jar <my jar>, because as I understand it, you can't include bouncycastle as part of your fat jar as a provider. But I'm not sure what I'm missing that I can't get it registered as a provider. Any help would be appreciated.
java -jar ignores classpath from commandline or envvar, and uses instead the specified jar plus any class-path item in its manifest. Either
reference bcprov in the jar's manifest (but do not merge a provider like bcprov into your own jar, you are correct on that) or
put bcprov in your JRE/lib/ext so JVM will find it without using classpath.
Or run with java -cp myjar:bcprov mainclassname (; on windows) which does use the classpath.
I'd expect your new BouncyCastleProvider() to throw, before getting to the point in your code that tries to use the provider, but I don't know scala and maybe it's different here.
FWIW, if this project would upgrade to 5 years ago (Java 7) you wouldn't need Bouncy for EC including ECDSA. You would still need it for Twofish, but I don't know who (else) implements Twofish and I'd be astonished if anyone requires it; your server here identifies as OpenSSH which doesn't.
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 a mapping application that can add ArcGIS 9.3+ base maps given a URL. One of the URLs that I would like to add is from a customer's URL and is secured. My mapping application was using Java 6 before and was able to add the secure URL with no issues. I now upgraded to Java 7 and am getting a
"java.security.cert.CertificateException: Certificates does not conform to algorithm constraints"
exception. At first, I believe this to be the case because in Java 7, by default, the MD2 algorithm to sign SSL certificates is disabled. You can see this in the java.security file:
"jdk.certpath.disabledAlgorithms=MD2"
But when I check the Certification Signature Algorithm of that URL, it says SHA-1. What is even more strange is if I comment out the "jdk.certpath.disabledAlgorithms=MD2" line in the java.security file, the URL will work with no issues. Is MD2 used somewhere else during the SSL process? Am I missing something here?
Background
MD2 was widely recognized as insecure and thus disabled in Java in version JDK 6u17 (see release notes http://www.oracle.com/technetwork/java/javase/6u17-141447.html, "Disable MD2 in certificate chain validation"), as well as JDK 7, as per the configuration you pointed out in java.security.
Verisign was using a Class 3 root certificate with the md2WithRSAEncryption signature algorithm (serial 70:ba:e4:1d:10:d9:29:34:b6:38:ca:7b:03:cc:ba:bf), but deprecated it and replaced it with another certificate with the same key and name, but signed with algorithm sha1WithRSAEncryption. However, some servers are still sending the old MD2 signed certificate during the SSL handshake (ironically, I ran into this problem with a server run by Verisign!).
You can verify that this is the case by getting the certificate chain from the server and examining it:
openssl s_client -showcerts -connect <server>:<port>
Recent versions of the JDK (e.g. 6u21 and all released versions of 7) should resolve this issue by automatically removing certs with the same issuer and public key as a trusted anchor (in cacerts by default).
If you still have this issue with newer JDKs
Check if you have a custom trust manager implementing the older X509TrustManager interface. JDK 7+ is supposed to be compatible with this interface, however based on my investigation when the trust manager implements X509TrustManager rather than the newer X509ExtendedTrustManager (docs), the JDK uses its own wrapper (AbstractTrustManagerWrapper) and somehow bypasses the internal fix for this issue.
The solution is to:
use the default trust manager, or
modify your custom trust manager to extend X509ExtendedTrustManager directly (a simple change).
Eclipse failed to connect to SVN https repositories (should also apply to any app using SSL/TLS).
svn: E175002: Connection has been shutdown: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Certificates does not conform to algorithm constraints
The issue was caused by latest Java 8 OpenJDK update that disabled MD5 related algorithms. As a workaround until new certificates are issued (if ever), change the following keys at java.security file
WARNING
Keep in mind that this could have security implications as disabled algorithms are considered weak.
As an alternative, the workaround can be applied on a JVM basis by a command line option to use an external java.security file with this changes, e.g.:
java -Djava.security.properties=/etc/sysconfig/noMD5.java.security
For Eclipse, add a line on eclipse.ini below -vmargs
-Djava.security.properties=/etc/sysconfig/noMD5.java.security
original keys
jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024
jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768
change to
jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024
jdk.tls.disabledAlgorithms=SSLv3, RC4, DH keySize < 768
java.security file is located in linux 64 at
/usr/lib64/jvm/java/jre/lib/security/java.security
On Fedora 28, just pay attention to the line
security.useSystemPropertiesFile=true
of the java.security file, found at:
$(dirname $(readlink -f $(which java)))/../lib/security/java.security
Fedora 28 introduced external file of disabledAlgorithms control at
/etc/crypto-policies/back-ends/java.config
You can edit this external file or you can exclude it from java.security by setting
security.useSystemPropertiesFile=false
We have this problem with one database we don't control and it requried another solution (The ones listed here didn't work). For mine I needed:
-Djdk.tls.client.protocols="TLSv1,TLSv1.1"
I think in my case it had to do with forcing a certain order.
Since this result is the first that Google returns for this error, I'll just add that if anyone looks for way do change java security settings without changing the global file java.security (for example you need to run some tests), you can just provide an overriding security file by JVM parameter
-Djava.security.properties=your/file/path in which you can enable the necessary algorithms by overriding the disablements.
this is more likely happening because somewhere along your certificate chain you have a certificate, more likely an old root, which is still signed with the MD2RSA algorythm.
You need to locate it into your certificate store and delete it.
Then get back to your certification authority and ask them for then new root.
It will more likely be the same root with the same validity period but it has been recertified with SHA1RSA.
Hope this help.
colleagues.
I have faced with this trouble during a development of automation tests for our REST API. JDK 7_80 was installed at my machine only. Before I installed JDK 8, everything worked just fine and I had a possibility to obtain OAuth 2.0 tokens with a JMeter. After I installed JDK 8, the nightmare with Certificates does not conform to algorithm constraints began.
Both JMeter and Serenity did not have a possibility to obtain a token. JMeter uses the JDK library to make the request. The library just raises an exception when the library call is made to connect to endpoints that use it, ignoring the request.
The next thing was to comment all the lines dedicated to disabledAlgorithms in ALL java.security files.
C:\Java\jre7\lib\security\java.security
C:\Java\jre8\lib\security\java.security
C:\Java\jdk8\jre\lib\security\java.security
C:\Java\jdk7\jre\lib\security\java.security
Then it started to work at last. I know, that's a brute force approach, but it was the most simple way to fix it.
# jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768
# jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024
I have this issue in SOAP-UI and no one solution above dont helped me.
Proper solution for me was to add
-Dsoapui.sslcontext.algorithm=TLSv1
in vmoptions file (in my case it was ...\SoapUI-5.4.0\bin\SoapUI-5.4.0.vmoptions)
Using openjdk-7 inside docker I have mounted a file with the content https://gist.github.com/dtelaroli/7d0831b1d5acc94c80209a5feb4e8f1c#file-jdk-security
#Location to mount
/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/security/java.security
Thanks #luis-muñoz
On redhat el8, running openjdk8. Changing the value of the following property from true to false
security.useSystemPropertiesFile = false
In the java.security file fixed the above issue for me