8 Replies Latest reply: Mar 27, 2013 8:53 AM by 998561 RSS

    Could not generate DH keypair (Unlimited Strength Extension doesn't work)

    998561
      Hi!

      I'm trying to do simple https GET from a webserver having a selfsigned 2048 certificate, but it fails since stock java doesn't support > 1024 bits encryption.
      I've hit this with 1.6.0_07 and 1.6.0_43, and for both versions, I've tried downloading:
      http://www.oracle.com/technetwork/java/javase/downloads/jce-6-download-429243.html

      and replacing the two jar files, but with no detectable change. Is there any (simple) way to verify that I actually did install the two files successfully?
      is there something else I need to do?

      Upgrading java is not an option in the short run..

      /Steffen

      The full exception..
      javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair
           at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
           at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1591)
           at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1554)
           at com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1537)
           at com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1463)
           at com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:64)
           at org.apache.http.impl.io.AbstractSessionOutputBuffer.flushBuffer(AbstractSessionOutputBuffer.java:147)
           at org.apache.http.impl.io.AbstractSessionOutputBuffer.flush(AbstractSessionOutputBuffer.java:154)
           at org.apache.http.impl.AbstractHttpClientConnection.doFlush(AbstractHttpClientConnection.java:278)
           at org.apache.http.impl.AbstractHttpClientConnection.flush(AbstractHttpClientConnection.java:283)
           at org.apache.http.impl.conn.ManagedClientConnectionImpl.flush(ManagedClientConnectionImpl.java:175)
           at org.apache.http.protocol.HttpRequestExecutor.doSendRequest(HttpRequestExecutor.java:260)
           at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
           at org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:717)
           at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:522)
           at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
           at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
           at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
           at tp7summerization.RancidParser.findTP7Aggregates(RancidParser.java:122)
           at tp7summerization.RouterThread.run(RouterThread.java:42)
           at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
           at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
           at java.lang.Thread.run(Thread.java:619)
      Caused by: java.lang.RuntimeException: Could not generate DH keypair
           at com.sun.net.ssl.internal.ssl.DHCrypt.<init>(DHCrypt.java:106)
           at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverKeyExchange(ClientHandshaker.java:417)
           at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:145)
           at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:516)
           at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:454)
           at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:884)
           at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1096)
           at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:623)
           at com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:59)
           ... 17 more
      Caused by: java.security.InvalidAlgorithmParameterException: Prime size must be multiple of 64, and can only range from 512 to 1024 (inclusive)
           at com.sun.crypto.provider.DHKeyPairGenerator.initialize(DashoA13*..)
           at java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:627)
           at com.sun.net.ssl.internal.ssl.DHCrypt.<init>(DHCrypt.java:100)
           ... 25 more
        • 1. Re: Could not generate DH keypair (Unlimited Strength Extension doesn't work)
          gimbal2
          995558 wrote:
          and replacing the two jar files, but with no detectable change.
          Then you did it wrong, because when I do it, it works. An often made mistake is to actually do it in the wrong runtime when there are multiple installed. Ex having a separate runtime and a JDK with a runtime part of it.
          Is there any (simple) way to verify that I actually did install the two files successfully?
          Yes, you're doing it! Try a key that would otherwise be unsupported.
          is there something else I need to do?
          Nope.
          >
          Upgrading java is not an option in the short run..
          And won't help because there is a valid reason why you have to manually patch the runtime to open up support for it. Newer versions aren't going to change anything.
          • 2. Re: Could not generate DH keypair (Unlimited Strength Extension doesn't work)
            998561
            Host systems are respectively:
            1. OSX, where all 3 occurrences of the files { local_policy.jar, US_export_policy.jar } has been replaced. (plugin version, installed version & Xcode version)
            2. FreeBSD, where both occurrences of the files has been replaced. (SUN version & Diablo version).

            I also checked that the files have the same attributes/rights set as the original ones.
            I hope the date of the two jars should be ignorable.

            If you check the link in the original post - is it right for 1.6?

            Seems like a dead end to me as it stands..
            • 3. Re: Could not generate DH keypair (Unlimited Strength Extension doesn't work)
              sabre150
              995558 wrote:
              Seems like a dead end to me as it stands..
              I am not convinced that you are using the 'java' you think you are or that you have installed the "Unlimited Strength" files correctly. If you have installed the "Unlimited Strength" files correctly and are using the 'java' version you think you are then the posted code will run without an exception. If you get the exception along the lines of
              Java version : 1.6.0_43
              Exception in thread "main" java.security.InvalidKeyException: Illegal key size or default parameters
                   at javax.crypto.Cipher.a(DashoA13*..)
                   at javax.crypto.Cipher.a(DashoA13*..)
                   at javax.crypto.Cipher.a(DashoA13*..)
                   at javax.crypto.Cipher.init(DashoA13*..)
                   at javax.crypto.Cipher.init(DashoA13*..)
                   at me.grm.research.scratch.y2008.XXXXXXXXXXXXXXXX.main(XXXXXXXXXXXXXXXX.java:40)
              Java Result: 1
              then you have not installed in the the "Unlimited Strength" files in the JRE/JDK being used.
              import javax.crypto.Cipher;
              import javax.crypto.KeyGenerator;
              import javax.crypto.SecretKey;
              
              public class XXXXXXXXXXXXXXXX
              {
                  public static void main(String[] args) throws Exception
                  {
                      System.out.println("Java version : " + System.getProperty("java.version"));
              
                      final KeyGenerator kg = KeyGenerator.getInstance("AES");
                      kg.init(256);
                      final SecretKey sk = kg.generateKey();
                      Cipher cipher = Cipher.getInstance("AES");
                      cipher.init(Cipher.ENCRYPT_MODE, sk);
                  }
              }
              • 4. Re: Could not generate DH keypair (Unlimited Strength Extension doesn't work)
                998561
                I must be jinxed somehow:

                /usr/local/bin/java -jar /store0/JavaApplication4/JavaApplication4.jar
                os.arch : i386
                os.name : FreeBSD
                os.version : 8.1-RELEASE
                Java version : 1.6.0_07

                and:

                java -jar "/Users/ssch/NetBeansProjects/JavaApplication4/dist/JavaApplication4.jar"
                os.arch : x86_64
                os.name : Mac OS X
                os.version : 10.8.3
                Java version : 1.6.0_43


                (No exceptions.. )

                I guess it'd make sense to suspect some other cause then just the amount of bits used in the certificate?
                I'm really not that much of a scolar when it comes to certificates - and as mentioned, I think its a self-signed one.
                its using: SHA-1 with RSA Encryption
                and its issued by RapidSSL.com fwiw.

                I've tried to expand a bit on your code and print out all the available providers, and the getInfo() of each of them:

                Available provider: SUN version 1.6
                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)
                Available provider: Apple version 1.0
                Apple Provider (implements DES, Triple DES, AES, Blowfish, PBE, Diffie-Hellman, HMAC/MD5, HMAC/SHA1)
                Available provider: SunRsaSign version 1.5
                Sun RSA signature provider
                Available provider: SunJSSE version 1.6
                Sun JSSE provider(PKCS12, SunX509 key/trust factories, SSLv3, TLSv1)
                Available provider: SunJCE version 1.6
                SunJCE Provider (implements RSA, DES, Triple DES, AES, Blowfish, ARCFOUR, RC2, PBE, Diffie-Hellman, HMAC)
                Available provider: SunJGSS version 1.0
                Sun (Kerberos v5, SPNEGO)
                Available provider: SunSASL version 1.5
                Sun SASL provider(implements client mechanisms for: DIGEST-MD5, GSSAPI, EXTERNAL, PLAIN, CRAM-MD5; server mechanisms for: DIGEST-MD5, GSSAPI, CRAM-MD5)
                Available provider: XMLDSig version 1.0
                XMLDSig (DOM XMLSignatureFactory; DOM KeyInfoFactory)
                Available provider: SunPCSC version 1.6
                Sun PC/SC provider
                • 5. Re: Could not generate DH keypair (Unlimited Strength Extension doesn't work)
                  sabre150
                  I'm not sure I understand your response. Do you get an exception on either of the OS?

                  I note you are using Netbeans. It is very common for people to fail to configure the Netbeans 'Platform' correctly so that they pick up the Netbeans JDK rather than the one they desire. If in doubt, follow "Properties->Libraries->Manage Platforms" and add the desired JDK then configure "Properties->Libraries->Java Platform" .
                  • 6. Re: Could not generate DH keypair (Unlimited Strength Extension doesn't work)
                    998561
                    Hi!

                    No, there were no exceptions.

                    I now tried on a third machine (OSX also), running JDK7.
                    This is the entire screen-dump. Notice that only the local_policy.jar changes size - I'm not sure if it matters that I'm located in Denmark?
                    The NetBeans project is using the JDK listed below, at least that what the settings for the project says.

                    Is there really no chance that this is something other then the policies not being installed correct?

                    Also - I really appreciate all the help I'm getting in here - really awesome how fast responses are coming and how competent they are!! Excellent!

                    /Steffen


                    iMac:~ root# cd /Library/Java/JavaVirtualMachines/jdk1.7.0_17.jdk/Contents/Home/jre/lib/security/
                    iMac:security root# ls -la
                    total 240
                    drwxrwxr-x 10 root wheel 340 Feb 4 22:10 .
                    drwxrwxr-x 98 root wheel 3332 Feb 4 22:10 ..
                    -rw-rw-r-- 1 root wheel 2487 Mar 1 16:10 US_export_policy.jar
                    -rw-rw-r-- 1 root wheel 2177 Mar 1 16:10 blacklist
                    -rw-rw-r-- 1 root wheel 83581 Mar 1 16:10 cacerts
                    -rw-rw-r-- 1 root wheel 2254 Mar 1 16:10 java.policy
                    -rw-rw-r-- 1 root wheel 15907 Mar 1 16:10 java.security
                    -rw-rw-r-- 1 root wheel 158 Feb 4 22:10 javafx.policy
                    -rw-rw-r-- 1 root wheel 2971 Mar 1 16:10 local_policy.jar
                    -rw-rw-r-- 1 root wheel 0 Mar 1 16:10 trusted.libraries
                    iMac:security root# mkdir policy.backup
                    iMac:security root# mv _policy.jar policy.backup/.
                    iMac:security root# cp /Users/ssch/Downloads/UnlimitedJCEPolicy/*.jar .
                    iMac:security root# ls -la
                    total 240
                    drwxrwxr-x 11 root wheel 374 Mar 25 10:43 .
                    drwxrwxr-x 98 root wheel 3332 Feb 4 22:10 ..
                    -rw-r--r-- 1 root wheel 2487 Mar 25 10:43 US_export_policy.jar
                    -rw-rw-r-- 1 root wheel 2177 Mar 1 16:10 blacklist
                    -rw-rw-r-- 1 root wheel 83581 Mar 1 16:10 cacerts
                    -rw-rw-r-- 1 root wheel 2254 Mar 1 16:10 java.policy
                    -rw-rw-r-- 1 root wheel 15907 Mar 1 16:10 java.security
                    -rw-rw-r-- 1 root wheel 158 Feb 4 22:10 javafx.policy
                    -rw-r--r-- 1 root wheel 2500 Mar 25 10:43 local_policy.jar
                    drwxr-xr-x 4 root wheel 136 Mar 25 10:43 policy.backup
                    -rw-rw-r-- 1 root wheel 0 Mar 1 16:10 trusted.libraries
                    iMac:security root# /Library/Java/JavaVirtualMachines/jdk1.7.0_17.jdk/Contents/Home/jre/bin/java -jar "/Users/ssch/NetBeansProjects/TestHTTPSGet/dist/TestHTTPSGet.jar"
                    javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair
                         at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
                         at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1886)
                         at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1844)
                         at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1827)
                         at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1346)
                         at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1323)
                         at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:515)
                         at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
                         at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1299)
                         at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:254)
                         at testhttpsget.TestHTTPSGet.main(TestHTTPSGet.java:51)
                    Caused by: java.lang.RuntimeException: Could not generate DH keypair
                         at sun.security.ssl.DHCrypt.<init>(DHCrypt.java:136)
                         at sun.security.ssl.ClientHandshaker.serverKeyExchange(ClientHandshaker.java:621)
                         at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:205)
                         at sun.security.ssl.Handshaker.processLoop(Handshaker.java:868)
                         at sun.security.ssl.Handshaker.process_record(Handshaker.java:804)
                         at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1016)
                         at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312)
                         at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1339)
                         ... 6 more
                    Caused by: java.security.InvalidAlgorithmParameterException: Prime size must be multiple of 64, and can only range from 512 to 1024 (inclusive)
                         at com.sun.crypto.provider.DHKeyPairGenerator.initialize(DHKeyPairGenerator.java:120)
                         at java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:658)
                         at sun.security.ssl.DHCrypt.<init>(DHCrypt.java:127)
                         ... 13 more
                    • 7. Re: Could not generate DH keypair (Unlimited Strength Extension doesn't work)
                      998561
                      Also a disclaimer:
                      I don't really know the first thing about the Java Security manager, and I'm not currently including this when I run the software:
                      -Djava.security.manager

                      Maybe I should?
                      • 8. Re: Could not generate DH keypair (Unlimited Strength Extension doesn't work)
                        998561
                        Hi!

                        I think this may actually be due to the certificate issued on the server in question.
                        Its a wildcard certificate which still fails in spite of whatever I try, but trying the same code on a non-wildcard server also having 2048 bits of encryption - everything seems to be working just fine.

                        So I found this googling:
                        http://stackoverflow.com/questions/3166373/can-java-connect-to-wildcard-ssl
                        "The default implementation in Sun's JSSE doesn't support wildcard. You need to write your own X509TrustManager to handle wildcard.", however this was back in july 2010, so this probably doesn't hold true anymore.

                        But I guess I can't yet conclude that this is due to the certificate being a wildcard one?