RXOP v3.8.9 has resolved the issue reported below.
Description of Symptoms
There are reports of a previously working RXOP application throwing a java.lang.SecurityException (wrapped inside a ricoh.rxop.rxcommon.RxopException) and failing to connect to a remote device.
The stacktrace will look something like this:
RxopException: [10.85.22.20] -- init -- JCE cannot authenticate the provider BC
ricoh.rxop.rxcommon.RxopException: -- init -- JCE cannot authenticate the provider BC
at ricoh.rxop.rxinst.RicohJavaDevice.e(RicohJavaDevice.java)
at ricoh.rxop.rxinst.RicohJavaDevice.access$000(RicohJavaDevice.java)
at ricoh.rxop.rxinst.al.run(al.java)
at ricoh.rxop.rxinst.bB.run(bB.java)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: java.lang.SecurityException: JCE cannot authenticate the provider BC
at java.base/javax.crypto.Cipher.getInstance(Cipher.java:722)
at java.base/javax.crypto.Cipher.getInstance(Cipher.java:642)
at ricoh.rxop.rxcommon.t.a(t.java)
at ricoh.rxop.rxcommon.r.a(r.java)
at ricoh.rxop.rxcommon.r.<init>(r.java)
at ricoh.rxop.rxcommon.DeviceInfoList.<init>(DeviceInfoList.java)
at ricoh.rxop.rxcommon.DeviceInfoList.getInstance(DeviceInfoList.java)
... 5 more
Caused by: java.util.jar.JarException: file:/C:/Users/fnord/rxopClient-3.8.8/lib/bcprov-jdk14-169.jar
has unsigned entries - org/bouncycastle/LICENSE.class
at java.base/javax.crypto.JarVerifier.verifySingleJar(JarVerifier.java:470)
at java.base/javax.crypto.JarVerifier.verifyJars(JarVerifier.java:317)
at java.base/javax.crypto.JarVerifier.verify(JarVerifier.java:260)
at java.base/javax.crypto.ProviderVerifier.verify(ProviderVerifier.java:130)
at java.base/javax.crypto.JceSecurity.verifyProvider(JceSecurity.java:190)
at java.base/javax.crypto.JceSecurity.getVerificationResult(JceSecurity.java:218)
at java.base/javax.crypto.Cipher.getInstance(Cipher.java:718)
... 11 more
Root Cause
Usually this Exception is related to the JVM unable to verify that the signed Provider jar has not been tampered with. For example, if the RXOP application is a runnable jar where the dependent libraries have been "exploded" and repackaged.
However, in this case it is likely because the JVM that runs the RXOP application has changed to one that no longer accepts JCE Provider libraries signed with SHA-1 keys after a cut-off date, such as the Bouncy Castle Provider jarfile bundled with RXOP. This library was signed using SHA-1 keys (by the vendor of the library), but not signed before a date in 2019.
Specifically, Oracle Java 8 Update 351, Java 17 (and others) now specifically reject SHA-1 signed libraries:
JARs signed with SHA-1 algorithms are now restricted by default and treated as if they were unsigned. This applies to the algorithms used to digest, sign, and optionally timestamp the JAR. It also applies to the signature and digest algorithms of the certificates in the certificate chain of the code signer and the Timestamp Authority, and any CRLs or OCSP responses that are used to verify if those certificates have been revoked.
Workarounds and Mitigations
The Java 8 Update 351 and Java 17 release notes (and others) discuss workarounds to this breaking change.
If those workarounds (which involve modifying the security configuration of the Java runtime) are not suitable, our recommendation is to use a JRE that does not have this restriction.
- JVMs known to work at time of writing: Amazon Corretto v8, v11, v17, v19; Liberica v19.
- You can use an earlier release of the Oracle JVM. During tests Oracle 1.8.0_171 seems to work.
How to Check a VM
To verify if a JVM will work with RXOP or not you can use the JDK under test to issue this command:
jarsigner -verify -verbose -certs bcprov-jdk14-169.jar
Look for this in the output for proof that the JDK no longer accepts this Provider library:
WARNING: The jar will be treated as unsigned, because it is signed with a weak algorithm ...
In the longer term RXOP will be updated to bundle a Java 8+ SHA-256 signed JCE Provider in the future, but since this library is not API compatible with previous releases this will need to occur in the context of a major release.