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
Post a Comment