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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
