Author: rjung
Date: Tue May 26 07:54:47 2015
New Revision: 1681701
URL: http://svn.apache.org/r1681701
Log:
Add info about compatibility of old Java clients
with new DH param choices by tcnative (1.1.34
and above).
Modified:
tomcat/trunk/webapps/docs/ssl-howto.xml
Modified: tomcat/trunk/webapps/docs/ssl-howto.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/ssl-howto.xml?rev=1681701&r1=1681700&r2=1681701&view=diff
==============================================================================
--- tomcat/trunk/webapps/docs/ssl-howto.xml (original)
+++ tomcat/trunk/webapps/docs/ssl-howto.xml Tue May 26 07:54:47 2015
@@ -485,6 +485,24 @@ SSL communications, and what to do about
sensitive!</p>
</li>
+<li>My Java-based client aborts handshakes with exceptions such as
+ "java.lang.RuntimeException: Could not generate DH keypair" and
+ "java.security.InvalidAlgorithmParameterException: Prime size must be
multiple
+ of 64, and can only range from 512 to 1024 (inclusive)"
+
+ <p>If you are using the APR/native connector, starting with version 1.1.34
+ it will determine the strength of ephemeral DH keys from the key size of
+ your RSA certificate. For example a 2048 bit RSA key will result in
+ using a 2048 bit primefor the DH keys. Unfortunately Java 6 only supports
+ 768 bit and Java 7 only supports 1024 bit. So if your certificate has a
+ stronger key, old Java clients might produce such handshake failures.
+ As a mitigation you can either try to force them to use another cipher by
+ configuring an appropriate <code>SSLCipherSuite</code> and activate
+ <code>SSLHonorCipherOrder</code>, or embed weak DH params in your
+ certificate file. The latter approach is not recommended because it weakens
+ the SSL security (logjam attack).</p>
+ </li>
+
</ul>
<p>If you are still having problems, a good source of information is the
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
