[OT] SSLException after Java upgrade

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[OT] SSLException after Java upgrade

Christopher Schultz-2
All,

(Note that this has nothing whatsoever to to with Apache Tomcat. These
connections are between services running on Tomcat and others, but
Tomcat's TLS code or configuration is in no way involved.)

I recently upgraded my OpenJDK Java 8 installations on a few servers and
started getting this error when connecting between two services
involving a specific server:

javax.net.ssl.SSLException: No preferred signature algorithm for
CertificateVerify

I believe I have tracked this back to the fact that this server's client
key/cert was using the secp256k1 curve instead of the more
widely-supported secp256r1 curve (this is the "NIST P-256" curve). I
think Java dropped support for the non-NIST curves at some point yet the
documentation says that they are supported for compatibility[1].

I founds a bug in the JDK listed here [2] which may or may not be related.

There is a workaround mentioned in the bug report:

"
Configure server so that supported_signature_algorithms prefers
signature algorithms supported by the SunPKCS11 provider
(RSA_PKCS1_SHA256, RSA_PKCS1_SHA384, RSA_PKCS1_SHA_512, RSA_SHA224,
RSA_PKCS1_SHA1).
"

I don't think this will apply to me, since this is all about RSA
signatures, but I suppose it could be adapted to the EC signature
algorithms (e.g. EC_PKCS1_SHA256 or whatever).

Does anyone know how to "configure [...]
supported_signature_algorithms"? I've never heard of that setting before
and some web searching isn't coming up with much for me.

Back to the deprecated curves. I can't find any reference to them being
disabled by default, and the java.security file contains a disabled
algorithms setting that doesn't mention EC crypto at all:

jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, \
     EC keySize < 224, 3DES_EDE_CBC, anon, NULL

and also:

jdk.tls.legacyAlgorithms= \
         K_NULL, C_NULL, M_NULL, \
         DH_anon, ECDH_anon, \
         RC4_128, RC4_40, DES_CBC, DES40_CBC, \
         3DES_EDE_CBC

The documentation for legacyAlgorithms says that they will only be
negotiated when there are no other (non legacy) options available. In my
case, it was a complete failure.

I minted a new certificate using P-256 and I was able to make a
connection again. So the certificate key algorithm was indeed the problem.

I finally found the reference I was looking for regarding Java actually
disabling those curves[3]. It happened in Java 8 u231 about a year ago[4].

One can re-enable the negotiation of these algorithms by setting the
system property "jdk.tls.namedGroups" to an appropriate setting.

This issue must have happened due to the upgrade of my Debian openjdk-8
package, which finally included the (default) disabling of those algorithms.

I started this post to ask some questions from the community but I think
it's turning out to be a little bit of a PSA because I ended up finding
just about everything I needed to recover.

I'm still curious about the supported_signature_algorithms thing, though.

Thanks,
-chris

[1]
https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#legacy-curves-retained-for-compatibility
[2] https://bugs.openjdk.java.net/browse/JDK-8223940
[3] https://java.com/en/configure_crypto.html#DisablenonNIST
[4] https://java.com/en/jre-jdk-cryptoroadmap.html

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [OT] SSLException after Java upgrade

Steve Sanders
Hi Chris,

We ran into similar issues when upgrading to latest JDK 8 (and 11). We
found that the fix was to add the sun.security.ec.SunEC as a security
provider in java.security like so:

security.provider.9=sun.security.ec.SunEC

After adding this we were able to continue using our current certificates
and communicate with services using the updated ciphers. Depending on the
version / flavor of JDK you're using you may also need to apply the
unlimited strength JCE policy patch found here:
https://www.oracle.com/java/technologies/javase-jce8-downloads.html

Steve
Reply | Threaded
Open this post in threaded view
|

Re: [OT] SSLException after Java upgrade

Christopher Schultz-2
Steve,

On 10/26/20 13:02, Steve Sanders wrote:
> We ran into similar issues when upgrading to latest JDK 8 (and 11). We
> found that the fix was to add the sun.security.ec.SunEC as a security
> provider in java.security like so:
>
> security.provider.9=sun.security.ec.SunEC

I'll have to try that. I can easily use my SSLTest tool[1] to test
various permutations.

> After adding this we were able to continue using our current certificates
> and communicate with services using the updated ciphers. Depending on the
> version / flavor of JDK you're using you may also need to apply the
> unlimited strength JCE policy patch found here:
> https://www.oracle.com/java/technologies/javase-jce8-downloads.html

If you still need this, then you really need to upgrade your Java. Java
8 no longer requires application of a separate, "unlimited" policy file
since u162, released January 2018.

-chris

[1] https://github.com/ChristopherSchultz/ssltest
[2]
https://golb.hplar.ch/2017/10/JCE-policy-changes-in-Java-SE-8u151-and-8u152.html

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [OT] SSLException after Java upgrade

Steve Sanders
Chris,

On Mon, Oct 26, 2020 at 2:34 PM Christopher Schultz <
[hidden email]> wrote:

> If you still need this, then you really need to upgrade your Java. Java
> 8 no longer requires application of a separate, "unlimited" policy file
> since u162, released January 2018.
>

Good to know! We are on 8U265 by default. I probably should read the
release notes a bit closer. :)