Java: Why does SSL handshake give 'Could not generate DH keypair' exception? -


when make ssl connection irc servers (but not others - presumably due server's preferred encryption method) following exception:

caused by: java.lang.runtimeexception: not generate dh keypair     @ com.sun.net.ssl.internal.ssl.dhcrypt.<init>(dhcrypt.java:106)     @ com.sun.net.ssl.internal.ssl.clienthandshaker.serverkeyexchange(clienthandshaker.java:556)     @ com.sun.net.ssl.internal.ssl.clienthandshaker.processmessage(clienthandshaker.java:183)     @ com.sun.net.ssl.internal.ssl.handshaker.processloop(handshaker.java:593)     @ com.sun.net.ssl.internal.ssl.handshaker.process_record(handshaker.java:529)     @ com.sun.net.ssl.internal.ssl.sslsocketimpl.readrecord(sslsocketimpl.java:893)     @ com.sun.net.ssl.internal.ssl.sslsocketimpl.performinitialhandshake(sslsocketimpl.java:1138)     @ com.sun.net.ssl.internal.ssl.sslsocketimpl.starthandshake(sslsocketimpl.java:1165)     ... 3 more 

final cause:

caused by: java.security.invalidalgorithmparameterexception: prime size must multiple of 64, , can range 512 1024 (inclusive)     @ com.sun.crypto.provider.dhkeypairgenerator.initialize(dashoa13*..)     @ java.security.keypairgenerator$delegate.initialize(keypairgenerator.java:627)     @ com.sun.net.ssl.internal.ssl.dhcrypt.<init>(dhcrypt.java:100)     ... 10 more 

an example of server demonstrates problem aperture.esper.net:6697 (this irc server). example of server not demonstrate problem kornbluth.freenode.net:6697. [not surprisingly, servers on each network share same respective behaviour.]

my code (which noted work when connecting ssl servers) is:

    sslcontext sslcontext = sslcontext.getinstance("ssl");     sslcontext.init(null, trustallcerts, new securerandom());     s = (sslsocket)sslcontext.getsocketfactory().createsocket();     s.connect(new inetsocketaddress(host, port), timeout);     s.setsotimeout(0);     ((sslsocket)s).starthandshake(); 

it's last starthandshake throws exception. , yes there magic going on 'trustallcerts'; code forces ssl system not validate certs. (so... not cert problem.)

obviously 1 possibility esper's server misconfigured, searched , didn't find other references people having problems esper's ssl ports, , 'openssl' connects (see below). i'm wondering if limitation of java default ssl support, or something. suggestions?

here's happens when connect aperture.esper.net 6697 using 'openssl' commandline:

~ $ openssl s_client -connect aperture.esper.net:6697 connected(00000003) depth=0 /c=gb/st=england/l=london/o=espernet/ou=aperture.esper.net/cn=*.esper.net/emailaddress=support@esper.net verify error:num=18:self signed certificate verify return:1 depth=0 /c=gb/st=england/l=london/o=espernet/ou=aperture.esper.net/cn=*.esper.net/emailaddress=support@esper.net verify return:1 --- certificate chain  0 s:/c=gb/st=england/l=london/o=espernet/ou=aperture.esper.net/cn=*.esper.net/emailaddress=support@esper.net    i:/c=gb/st=england/l=london/o=espernet/ou=aperture.esper.net/cn=*.esper.net/emailaddress=support@esper.net --- server certificate -----begin certificate----- [there certificate here, deleted save space] -----end certificate----- subject=/c=gb/st=england/l=london/o=espernet/ou=aperture.esper.net/cn=*.esper.net/emailaddress=support@esper.net issuer=/c=gb/st=england/l=london/o=espernet/ou=aperture.esper.net/cn=*.esper.net/emailaddress=support@esper.net --- no client certificate ca names sent --- ssl handshake has read 2178 bytes , written 468 bytes --- new, tlsv1/sslv3, cipher dhe-rsa-aes256-sha server public key 2048 bit secure renegotiation supported compression: none expansion: none ssl-session:     protocol  : tlsv1     cipher    : dhe-rsa-aes256-sha     session-id: 51f1d40a1b044700365d3bd1c61abc745fb0c347a334e1410946dcb5efe37afd     session-id-ctx:      master-key: df8194f6a60b073e049c87284856b5561476315145b55e35811028c4d97f77696f676db019bb6e271e9965f289a99083     key-arg   : none     start time: 1311801833     timeout   : 300 (sec)     verify return code: 18 (self signed certificate) --- 

as noted, after that, connect more can java app.

should relevant, i'm using os x 10.6.8, java version 1.6.0_26.

the problem prime size. maximum-acceptable size java accepts 1024 bits. known issue (see jdk-6521495).

the bug report linked mentions workaround using bouncycastle's jce implementation. should work you.

update

this reported bug jdk-7044060 , fixed recently.

note, however, limit raised 2048 bit. sizes > 2048 bit, there jdk-8072452 - remove maximum prime size of dh keys; fix appears 9.


Comments

Popular posts from this blog

php - Vagrant up error - Uncaught Reflection Exception: Class DOMDocument does not exist -

vue.js - Create hooks for automated testing -

.htaccess - ERR_TOO_MANY_REDIRECTS htaccess -