Key length limit with Java Cryptography Extension - java

I am aware that the keylenght in the Sun/Oracle JVM is limited for judical reasons. However as far as I understood the concept of the JCE (Java Cryptography Extension) is that a user can choose it's own security provider to compensate this limitation.
For this reason I am trying to operate the Bounce Castle as security provider in conjunction with the Orcale JDK 1.7.
In order to figure out the actual allowed keylegths I am using this code:
import org.bouncycastle.jce.provider.BouncyCastleProvider;
import javax.crypto.Cipher;
import java.security.GeneralSecurityException;
import java.security.Provider;
import java.security.Security;
public class JCETest {
public static void main( String[] args ) throws GeneralSecurityException
{
BouncyCastleProvider bouncyCastleProvider = new BouncyCastleProvider();
Security.addProvider(bouncyCastleProvider);
System.out.println( "\nSecurity-Provider:" );
for( Provider prov : Security.getProviders() ) {
System.out.println( " " + prov + ": " + prov.getInfo() );
}
System.out.println( "\nMaxAllowedKeyLength (for '" + Cipher.getInstance("AES").getProvider() + "' using current 'JCE Policy Files'):\n"
+ " DES = " + Cipher.getMaxAllowedKeyLength( "DES" ) + "\n"
+ " Triple DES = " + Cipher.getMaxAllowedKeyLength( "Triple DES" ) + "\n"
+ " AES = " + Cipher.getMaxAllowedKeyLength( "AES" ) + "\n"
+ " Blowfish = " + Cipher.getMaxAllowedKeyLength( "Blowfish" ) + "\n"
+ " RSA = " + Cipher.getMaxAllowedKeyLength( "RSA" ) + "\n" );
}
}
The output for the Orcale JDK 1.7 and it's build in providers is:
Security-Provider:
SUN version 1.7: SUN (DSA key/parameter generation; DSA signing; SHA-1, MD5 digests; SecureRandom; X.509 certificates; JKS keystore; PKIX CertPathValidator; PKIX CertPathBuilder; LDAP, Collection CertStores, JavaPolicy Policy; JavaLoginConfig Configuration)
SunRsaSign version 1.7: Sun RSA signature provider
SunEC version 1.7: Sun Elliptic Curve provider (EC, ECDSA, ECDH)
SunJSSE version 1.7: Sun JSSE provider(PKCS12, SunX509 key/trust factories, SSLv3, TLSv1)
SunJCE version 1.7: SunJCE Provider (implements RSA, DES, Triple DES, AES, Blowfish, ARCFOUR, RC2, PBE, Diffie-Hellman, HMAC)
SunJGSS version 1.7: Sun (Kerberos v5, SPNEGO)
SunSASL version 1.7: Sun SASL provider(implements client mechanisms for: DIGEST-MD5, GSSAPI, EXTERNAL, PLAIN, CRAM-MD5, NTLM; server mechanisms for: DIGEST-MD5, GSSAPI, CRAM-MD5, NTLM)
XMLDSig version 1.0: XMLDSig (DOM XMLSignatureFactory; DOM KeyInfoFactory)
SunPCSC version 1.7: Sun PC/SC provider
BC version 1.46: BouncyCastle Security Provider v1.46
MaxAllowedKeyLength (for 'SunJCE version 1.7' using current 'JCE Policy Files'):
DES = 64
Triple DES = 128
AES = 128
Blowfish = 128
RSA = 2147483647
But when I apply BC as provider by switching to
Cipher.getInstance("AES", bouncyCastleProvider).getProvider()
It still shows me the limited key length (except for RSA) like this:
MaxAllowedKeyLength (for 'BC version 1.46' using current 'JCE Policy Files'):
DES = 64
Triple DES = 128
AES = 128
Blowfish = 128
RSA = 2147483647
But when I change the JDK to openJDK, I get this output:
MaxAllowedKeyLength (for 'BC version 1.46' using current 'JCE Policy Files'):
DES = 2147483647
Triple DES = 2147483647
AES = 2147483647
Blowfish = 2147483647
RSA = 2147483647
This astonishes me since I was under the impression that not the JDK but the security-provider limiting the key length. But my tests are showing that obviously the JDK is limiting the key length, no matter which provider I choose.
My question is: Did I got something wrong? Is there a way to unleash the keyleght with the Oracle JDK?


The key length limits are determined in the JCE, that is in the JRE, not in the provider. JCE checks the limits before it hands over to the provider.
The correct solution to this is to install the unlimited strength policy files. While this is probably the right solution for your development workstation, it quickly becomes a major hassle (if not a roadblock) to have non-technical users install the files on every computer. There is no way to distribute the files with your program; they must be installed in the JRE directory (which may even be read-only due to permissions).
Bouncy Castle does provide its own API though, which is separate from the JCE. This API does not enforce any key length limits. This is not an ideal solution either, as the API is totally different from the JCE and bound to BC, and BC is an extra 1MB library to distribute with your program.
Finally, there is also a reflection workaround described here in more detail.
OpenJDK does not have any key length limits, which is why they are all simply Integer.MAX_VALUE.

Related

Java 8u201: no cipher suites in common [duplicate]

I recently added SSL to my website and it can be accessed over https. Now when my java application tries to make requests to my website and read from it with a buffered reader it produces this stack trace
Im not using a self signed certificate the cert is from Namecheap who uses COMODO SSL as the CA to sign my certificate. im using java 8
javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
at sun.security.ssl.Handshaker.activate(Handshaker.java:503)
at sun.security.ssl.SSLSocketImpl.kickstartHandshake(SSLSocketImpl.java:1482)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1351)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
My code is very basic and simply tries to read the page on my site using a buffered reader
private void populateDataList() {
try {
URL url = new URL("https://myURL.com/Data/Data.txt");
URLConnection con = url.openConnection();
con.setRequestProperty("Connection", "close");
con.setDoInput(true);
con.setUseCaches(false);
BufferedReader in = new BufferedReader(new InputStreamReader(con.getInputStream()));
String line;
int i = 0;
while((line = in.readLine()) != null) {
this.url.add(i, line);
i++;
}
} catch (Exception e) {
e.printStackTrace();
}
}
Ive tried adding my SSL certificate to the JVM's Keystore and Ive also even tried to accept every certificate (which defeats the purpose of SSL I know) with this code
private void trustCertificate() {
TrustManager[] trustAllCerts = new TrustManager[] {
new X509TrustManager() {
public java.security.cert.X509Certificate[] getAcceptedIssuers() {
return new X509Certificate[0];
}
public void checkClientTrusted(
java.security.cert.X509Certificate[] certs, String authType) {
}
public void checkServerTrusted(
java.security.cert.X509Certificate[] certs, String authType) {
}
}
};
try {
SSLContext sc = SSLContext.getInstance("TLS");
sc.init(null, trustAllCerts, new java.security.SecureRandom());
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
} catch (GeneralSecurityException e) {
}
try {
URL url = new URL("https://myURL.com/index.php");
URLConnection con = url.openConnection();
BufferedReader br = new BufferedReader(new InputStreamReader(con.getInputStream()));
String line;
while((line = br.readLine()) != null) {
System.out.println(line);
}
} catch (Exception e) {
}
}
Im stumped and any help would be much appreciated!

In $JRE/lib/security/java.security:
jdk.tls.disabledAlgorithms=SSLv3, TLSv1, RC4, DES, MD5withRSA, DH keySize < 1024, \
EC keySize < 224, 3DES_EDE_CBC, anon, NULL
This line is enabled, after I commented out this line, everything is working fine. Apparently after/in jre1.8.0_181 this line is enabled.
My Java version is "1.8.0_201.

I also run into this with the Java8 update 1.8.0.229 on Ubuntu 18.04.
I changed the following part:
# Example:
# jdk.tls.disabledAlgorithms=MD5, SSLv3, DSA, RSA keySize < 2048
#jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \
# DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
# include jdk.disabled.namedCurves
jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, \
DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
include jdk.disabled.namedCurves
I removed TLSv1 and TLSv1.1 from the list of jdk.tls.disabledAlgorithms inside the file
/etc/java-8-openjdk/security/java.security
After checking this:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 28
Server version: 5.7.33-0ubuntu0.18.04.1 (Ubuntu)
Copyright (c) 2000, 2021, Oracle and/or its affiliates.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> SHOW GLOBAL VARIABLES LIKE 'tls_version';
+---------------+-----------------------+
| Variable_name | Value |
+---------------+-----------------------+
| tls_version | TLSv1,TLSv1.1,TLSv1.2 |
+---------------+-----------------------+
1 row in set (0.00 sec)
mysql> exit

protocol is disabled or cipher suites are inappropriate
The key to the problem lies in that statement. What it basically means is either:
The TLS implementation used by the client does not support the cipher suites used by the server's certificate.
The TLS configuration on the server has disabled cipher suites supported by the client.
The TLS configurations on the client disable cipher suites offered by the server.
TLS version incompatibility between the client and server.
This leads to handshake failure in TLS, and the connection fails. Check one or all of the three scenarios above.

You can add the expected TLS protocol to your connection string like this:
jdbc:mysql://localhost:3306/database_name?enabledTLSProtocols=TLSv1.2
That fixed the problem for me.
Edit 04-02-2022:
As Yair's comment says:
Since Connector/J 8.0.28 enabledTLSProtocols has been renamed to tlsVersions.

In my case I am runnig Centos 8 and had the same issue with Imap/Java.
Had to update the system-wide cryptographic policy level.
update-crypto-policies --set LEGACY
reboot machine.
Thats it.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/considerations_in_adopting_rhel_8/security_considerations-in-adopting-rhel-8#tls-v10-v11_security

We started experiencing this problem after upgrading to jre1.8.0_291. I commented out "jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA,
DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL,
include jdk.disabled.namedCurves" in java.security located in C:\Program Files\Java\jre1.8.0_291\lib\security which resolved the problem.

javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
For posterity, I recently bumped up against this using IBM's JDK8 implementation which specifically disables TLS1.1 and 1.2 by default (sic). If you want to see what TLS versions are supported by the JVM, run something like the following code:
SSLContext context = SSLContext.getInstance("TLS");
context.init(null, null, null);
String[] supportedProtocols = context.getDefaultSSLParameters().getProtocols();
System.out.println(Arrays.toString(supportedProtocols));
The code spits out [TLSv1] by default under AIX JDK8. Not good. Under Redhat and Solaris it spits out [TLSv1, TLSv1.1, TLSv1.2].
I could not find any values in the java.security file to fix this issue but there might be some for your architecture. In the IBM specific case, we have to add:
-Dcom.ibm.jsse2.overrideDefaultTLS=true

In my case I had to upgrade the mysql client library to the latest version and it started working again:
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>8.0.24</version>
</dependency>

I have encountered
javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
error when accessing TLS 1.3 enabled endpoint from a Java 11 application. That is a usual case in GCP, for example.
The problem has gone away without any changes in my code just by upgrading from Java 11 to Java 14.
The Java 11 doesn't deprecate earlier TLS protocol versions by default. Instead of configuring it, simple upgrade of the runtime to Java 14 has helped.

Apparently, if you have TLS 1.0 disabled the emails won't be sent out. TLS Versions 1.1 and 1.2 do not work. Peter's suggestion did the trick for me.

I was face with the same situation on a tomcat7 server, 5.7.34-0ubuntu0.18.04.1, openjdk version "1.8.0_292"
I tried many approaches like disabling SSL in the server.xml file, changing the connection strings etc etc
but in the end all i did was to edit the file java.security with
sudo nano /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/java.security
comment out and remove TLSv1 and TLSv1.1
# Comment the line below
#jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \
# DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
# include jdk.disabled.namedCurves
# your new line should read as beloew
jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, \
DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
include jdk.disabled.namedCurves

For ME in this case :
javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
I found that this is JDK/JRE (Java\jdk1.8.0_291\jre\lib\security) config related, and in order to solve it you need to Disable the TLS anon and NULL cipher suites.
You can found how to do this in the oficial documentation here:
https://www.java.com/en/configure_crypto.html
Also before doing this, consider the implications of using LEGACY algorithms.

upgraded from 1 to 2 + modifying the $JRE/lib/security/java.security file did the trick.
before after mysql driver

How to disable weak ciphers and client renegotiation in Play 2.5.x (Scala)

I am using Play 2.5.x (Scala). The default server is Netty. I can't find a way to disable some (weak) specific ciphers as well as client renegotiation.
The Play doc refers to JSSE settings:
https://www.playframework.com/documentation/2.3.x/ConfiguringHttps
How do I use these JSSE settings in a config file ? Or is there a different way to achieve this ?

As described in the documentation, create a properties file (let's call it jvm.security.properties) that looks something like the following:
jdk.tls.disabledAlgorithms=EC keySize < 160, RSA keySize < 2048, DSA keySize < 2048
jdk.tls.rejectClientInitiatedRenegotiation=true
jdk.certpath.disabledAlgorithms=MD2, MD4, MD5, EC keySize < 160, RSA keySize < 2048, DSA keySize < 2048
Then start up the JVM with that properties file:
java -Djava.security.properties=jvm.security.properties

Java 8 has broken my application that uses PKCS12

In 2007 I wrote a tiny java application that would digitally sign several different PDF documents (with image of my signature). I has been working great until I upgraded to Java 8.
I am now getting errors:
IOException: Unable to read private key from keystore
e: java.io.IOException: unsupported PKCS12 secret value type 48
I seems now that Java 8 PKCS12 cannot store secret key entries. This is a critical application for me. I use it hundreds of times a day.
How can I work around this issue?
Here is an abridged version of the critical code:
String appPath = SignPDF.class.getProtectionDomain().getCodeSource().getLocation().getPath();
String keytype = "pkcs12";
String keyfile = appPath + "DanVokt.pfx";
String keyimage = appPath + "DanVokt.png";
String keypass = "xxxxxxxxx";
KeyStore ks = KeyStore.getInstance(keytype);
ks.load(new FileInputStream(keyfile), keypass.toCharArray());
String alias = (String)ks.aliases().nextElement();
PrivateKey key = (PrivateKey)ks.getKey(alias, keypass.toCharArray());
Certificate[] chain = ks.getCertificateChain(alias);
PdfReader reader = new PdfReader(ifile);
FileOutputStream fout = new FileOutputStream(ofile);
PdfStamper stp = PdfStamper.createSignature(reader, fout, '\0');
PdfSignatureAppearance sap = stp.getSignatureAppearance();
sap.setCrypto(key, chain, null, PdfSignatureAppearance.SELF_SIGNED);
// allow only printing
stp.setEncryption(null, keypass.getBytes(), PdfWriter.ALLOW_PRINTING,
PdfWriter.STANDARD_ENCRYPTION_128);
stp.close();
Here is a stack tace:
$ signpdf "Timelog*" 1
Processing File: "Timelog - Current Week.pdf" 1
IOException: Unable to read private key from keystore
java.io.IOException: unsupported PKCS12 secret value type 48
at sun.security.pkcs12.PKCS12KeyStore.loadSafeContents(PKCS12KeyStore.java:2197)
at sun.security.pkcs12.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:2025)
at java.security.KeyStore.load(KeyStore.java:1445)
at SignPDF.main(SignPDF.java:61)
Here is the version and build:
$ java -version
java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
Attempt to use keytool to view PKCS12 (.pfx) file:
$ keytool -list -keystore DanVokt.pfx -storepass XXXXXXXX -storetype PKCS12 -v
keytool error: java.io.IOException: unsupported PKCS12 secret value type 48
java.io.IOException: unsupported PKCS12 secret value type 48
at sun.security.pkcs12.PKCS12KeyStore.loadSafeContents(PKCS12KeyStore.java:2197)
at sun.security.pkcs12.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:2025)
at java.security.KeyStore.load(KeyStore.java:1445)
at sun.security.tools.keytool.Main.doCommands(Main.java:795)
at sun.security.tools.keytool.Main.run(Main.java:343)
at sun.security.tools.keytool.Main.main(Main.java:336)

I did a bit of digging. The change appears to have happened as part of some Keystore API enhancements. (They were committed in January 2013)
The specific test is this:
} else if (bagId.equals((Object)SecretBag_OID)) {
DerInputStream ss = new DerInputStream(bagValue.toByteArray());
DerValue[] secretValues = ss.getSequence(2);
ObjectIdentifier secretId = secretValues[0].getOID();
if (!secretValues[1].isContextSpecific((byte)0)) {
throw new IOException(
"unsupported PKCS12 secret value type "
+ secretValues[1].tag);
}
where !(isContextSpecific() is checking the "tag" of the DERvalue to make sure that it doesn't have the CONTEXT bit set. This test is failing.
It would seem that the work-around would be to store these secret keys as DER values with a tag type that doesn't have bit 0x80 set.
See also:
PKCS12KeyStore.java - https://github.com/frohoff/jdk8u-jdk/blob/master/src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java
DERValue.java - https://github.com/frohoff/jdk8u-jdk/blob/master/src/share/classes/sun/security/util/DerValue.java

[RESOLVED]
I created a java keystore (JKS) file:
keytool -genkey -keyalg RSA -keysize 2048 -keystore danv_keystore.jks -alias danv
Of course this created a new private key and new certificate but that is currently not an issue since it is self-signed. I am a bit confused on how to use my own private key and certificate. Any examples?
I then simply changed the keytype and keyfile:
// String keytype = "pkcs12";
String keytype = "JKS";
// String keyfile = appPath + "DanVokt.pfx";
String keyfile = appPath + "danv_keystore.jks";
And voila! It is now working again.
I compiled it under J8 and J7 and it works in both environments.
Thanks!

Using Java 7 to Verify OpenSSL Generated S/MIME Digital Signature Files

We have a process that uses OpenSSL to generate S/MIME digital signatures which need to be verified later using Java 7. On one side we use OpenSSL to read in text files and generate a signed digital output which is verified later.
We used to have the verification using OpenSSL but now we need Java (note: we cannot count on OpenSSL being available now).
We use this to sign: openssl smime -sign -inkey private.key -signer public.key -in ${f} > ${f}.signed and this to verify: openssl smime -verify -noverify -in ${f}.signed
Note: that the verify does not validate the certificates, only checks the signature/contents.
I need to change the verify part of this process to be a java application, preferably with Java 7 (which I think now has the JCE built in).
A sample output is something like ...
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha-256"; boundary="----185C6C544BB34D30B0835B915C158544"
This is an S/MIME signed message
------185C6C544BB34D30B0835B915C158544
Four score and seven years ago our fathers brought forth on this continent, a
new nation, conceived in Liberty, and dedicated to the proposition that all
men are created equal.
Now we are engaged in a great civil war, testing whether that nation, ...
------185C6C544BB34D30B0835B915C158544
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
MIIKAAYJKoZIhvcNAQcCoIIJ8TCCCe0CAQExDzANBglghkgBZQMEAgEFADALBgkq
hkiG9w0BBwGgggchMIIHHTCCBgWgAwIBAgIEUzuEpzANBgkqhkiG9w0BAQsFADCB
hzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEoMCYGA1UE
CxMfRGVwYXJ0bWVudCBvZiBIb21lbGFuZCBTZWN1cml0eTEiMCAGA1UECxMZQ2Vy
dGlm ...
... JIQeeE=
------185C6C544BB34D30B0835B915C158544--
The signature algorithm is sha256WithRSAEncryption; example ...
openssl smime -pk7out -in message.signed | openssl pkcs7 -text -noout -print_certs
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1396409511 (0x533b84a7)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=Corp, OU=Acme, OU=CA
Validity
Not Before: May 16 15:27:56 2014 GMT
Not After : May 16 15:57:56 2015 GMT
Subject: C=US, O=Corp, OU=Acme, OU=CBP, CN=foo.acme.corp.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:00:00:00:00:b1:b6:49:6e:ca:d7:61:07:a0:18:
...
c9:de:ab:a7:2f:97:e4:f6:64:37:ec:3a:9d:ae:c0:
16:03
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Certificate Policies:
Policy: 2.16.840.1.101.3.2.1.3.8
...
I have looked at many, many examples, tried multiple ones without success. I wish had had some source to share with you, but the success I have had so far would not be helpful in the least.

This can be done using the Bouncy Castle Crypto APIs where you can use the following official example as reference, https://github.com/bcgit/bc-java/blob/master/mail/src/main/java/org/bouncycastle/mail/smime/examples/ValidateSignedMail.java.
For a simpler example to perform a full validation of a signed email including the certification chain you would do something like this with org.bouncycastle:bcmail-jdk15on:1.52:
import org.bouncycastle.cms.SignerInformation;
import org.bouncycastle.jce.provider.BouncyCastleProvider;
import org.bouncycastle.mail.smime.validator.SignedMailValidator;
import javax.mail.internet.MimeMessage;
import java.io.FileInputStream;
import java.security.KeyStore;
import java.security.Security;
import java.security.cert.PKIXParameters;
public class SignedMailValidatorExample {
public static void main(String[] args) throws Exception {
Security.addProvider(new BouncyCastleProvider());
FileInputStream signedEmailInputStream = new FileInputStream("signed_email.eml");
MimeMessage signedEmailMimeMessage = new MimeMessage(null, signedEmailInputStream);
KeyStore trustStore = KeyStore.getInstance("JKS");
trustStore.load(new FileInputStream("truststore.jks"), "changeit".toCharArray());
PKIXParameters pkixParameters = new PKIXParameters(trustStore);
pkixParameters.setRevocationEnabled(false);
SignedMailValidator signedMailValidator = new SignedMailValidator(signedEmailMimeMessage, pkixParameters);
boolean successfulValidation = true;
for (SignerInformation signerInformation : signedMailValidator.getSignerInformationStore().getSigners()) {
SignedMailValidator.ValidationResult signerValidationResult = signedMailValidator
.getValidationResult(signerInformation);
if (!signerValidationResult.isValidSignature()) {
successfulValidation = false;
break;
}
}
if (successfulValidation) {
System.out.println("Signed email validated correctly.");
} else {
System.out.println("Signed email validation failed.");
}
}
}
Where truststore.jks should contain a CA certificate (e.g. the issuing CA) that chains to the certificate used to sign the email. Now, you can easily created this file using a software like https://keystore-explorer.org/.

Weblogic - java.lang.ClassNotFoundException: org.bouncycastle.jce.provider.JCEMac$DES9797Alg3

I am working with a Java Web application and I need to generate a MAC using 3DES algorithm. Code is working without problems on a Weblogic 10.3 but the problem came when I tried to run the application in a different Weblogic, similar version (10.3.1).
This is my code:
public String getMac(String inkey, String data) throws Exception {
byte[] out = new byte[8];
try {
// if I commend this line, the result is the same
Security.addProvider(new BouncyCastleProvider());
// this loop proves the BC provider is there
for (Provider p : Security.getProviders()) {
log.debug("--");
log.debug(p.getName());
log.debug(p.getInfo());
}
try {
BouncyCastleProvider bc = new BouncyCastleProvider();
// class is there, no problem
log.debug("info" + bc.getInfo());
DES9797Alg3 alg3 = new DES9797Alg3();
// class is there, no problem
log.debug("alg3" + alg3.toString());
} catch (Exception e) {
log.error("error BouncyCastleProvider classes");
}
log.debug("length: " + inkey.length());
if (inkey.length() < 48)
inkey += inkey.substring(0, 16);
byte[] rawkey = hexStringToByteArray(inkey);
DESedeKeySpec keyspec = new DESedeKeySpec(rawkey);
SecretKeyFactory keyfactory = SecretKeyFactory.getInstance("DESede");
SecretKey key = keyfactory.generateSecret(keyspec);
Mac mac = Mac.getInstance("ISO9797Alg3Mac");
mac.init(key);
mac.update(data.getBytes());
mac.doFinal(out, 0);
} catch (Exception e) {
log.error("Error generating MAC X9_19", e);
throw new Exception("Error generating MAC X9_19", e);
}
And this is the error I get:
Caused by: java.security.InvalidKeyException: No installed provider supports this key: com.sun.crypto.provider.DESedeKey
at javax.crypto.Mac.a(DashoA13*..)
at javax.crypto.Mac.init(DashoA13*..)
at es.indra.netplus.sec.services.util.UtilMac.getMac(UtilMac.java:180)
... 73 more
Caused by: java.security.NoSuchAlgorithmException: class configured for Mac(provider: BC)cannot be found.
at java.security.Provider$Service.getImplClass(Provider.java:1268)
at java.security.Provider$Service.newInstance(Provider.java:1220)
... 76 more
Caused by: java.lang.ClassNotFoundException: org.bouncycastle.jce.provider.JCEMac$DES9797Alg3
at weblogic.utils.classloaders.GenericClassLoader.findLocalClass(GenericClassLoader.java:283)
at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.java:256)
at weblogic.utils.classloaders.ChangeAwareClassLoader.findClass(ChangeAwareClassLoader.java:54)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at weblogic.utils.classloaders.GenericClassLoader.loadClass(GenericClassLoader.java:176)
at weblogic.utils.classloaders.ChangeAwareClassLoader.loadClass(ChangeAwareClassLoader.java:35)
at java.security.Provider$Service.getImplClass(Provider.java:1262)
I do no understand why error says that org.bouncycastle.jce.provider.JCEMac$DES9797Alg3 is not there. It is possible that 'java.security' is looking in another place? I have requested to the server administrator to copy the library in the endorsed directory, but not I am not sure if this is going to work and way this is happening.
Notice that even if I remove 'Security.addProvider(new BouncyCastleProvider());' line, in the list of available providers, BC is listed.
This is the list of providers I got:
-- -- --
CSSX509CertificateFactoryProvider
CSS JDK CertPath provider
1.0
-- -- --
SUN
SUN (DSA key/parameter generation; DSA signing; SHA-1, MD5 digests; SecureRandom; X.509 certificates; JKS keystore; PKIX CertPathValidator; PKIX CertPathBuilder; LDAP, Collection CertStores, JavaPolicy Policy; JavaLoginConfig Configuration)
1.6
-- -- --
SunRsaSign
Sun RSA signature provider
1.5
-- -- --
SunJSSE
Sun JSSE provider(PKCS12, SunX509 key/trust factories, SSLv3, TLSv1)
1.6
-- -- --
SunJCE
SunJCE Provider (implements RSA, DES, Triple DES, AES, Blowfish, ARCFOUR, RC2, PBE, Diffie-Hellman, HMAC)
1.6
-- -- --
SunJGSS
Sun (Kerberos v5, SPNEGO)
1.0
-- -- --
SunSASL
Sun SASL provider(implements client mechanisms for: DIGEST-MD5, GSSAPI, EXTERNAL, PLAIN, CRAM-MD5; server mechanisms for: DIGEST-MD5, GSSAPI, CRAM-MD5)
1.5
-- -- --
XMLDSig
XMLDSig (DOM XMLSignatureFactory; DOM KeyInfoFactory)
1.0
-- -- --
SunPCSC
Sun PC/SC provider
1.6
-- -- --
WebLogicCertPathProvider
WebLogic CertPath Provider JDK CertPath provider
1.0
-- -- --
WLSJDKCertPathProvider
WebLogic JDK CertPath provider
1.0
-- -- --
BC
BouncyCastle Security Provider v1.46
1.46
BC is there, moreover, the same version I got inside my war file.
I have googled many hours with no luck, hope someone can point me to the right direction.

After spending many hours on google trying to fix the error doing change in the code, the problem was solved adding the library in the server domain lib directory. Anyway, I still do not understand why this happens.

Categories

Resources