SSL anlaşması neden 'DH anahtar çifti oluşturulamadı' istisnası veriyor?

Bazı IRC sunucuları ile SSL bağlantısı kurduğumda (ancak diğerleri değil - muhtemelen sunucunun tercih ettiği şifreleme yöntemi nedeniyle) aşağıdaki istisnayı alıyorum:

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:556)
    at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:183)
    at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:593)
    at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:529)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:893)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1138)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1165)
    ... 3 more

Son neden:

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)
    ... 10 more

Bu sorunu gösteren bir sunucu örneği aperture.esper.net:6697'dir (bu bir IRC sunucusudur). Sorunu göstermeyen bir sunucu örneği kornbluth.freenode.net:6697. [Şaşırtıcı olmayan bir şekilde, her ağdaki tüm sunucular aynı davranışları paylaşır.]

Kodum (belirtildiği gibi bazı SSL sunucularına bağlanırken çalışır):

    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();

İstisnayı atan el sıkışması. Ve evet 'trustAllCerts' ile biraz sihir oluyor; bu kod SSL sistemini sertifikaları doğrulamamaya zorlar. (Yani ... sertifika sorunu değil.)

Açıkçası bir olasılık, esper sunucusunun yanlış yapılandırılmış olması, ancak aradım ve esper'in SSL bağlantı noktalarında sorun yaşayan insanlara başka referanslar bulamadım ve 'openssl' ona bağlanıyor (aşağıya bakın). Bunun Java varsayılan SSL desteğinin bir kısıtlaması olup olmadığını merak ediyorum. Baska öneri?

Komut satırından 'openssl' kullanarak aperture.esper.net 6697'ye bağlandığımda şöyle olur:

~ $ 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 was a certificate here, but I deleted it to 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 and written 468 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS 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)
---

Belirtildiği gibi, bundan sonra, Java uygulamam için söyleyebileceğinizden daha fazla olan başarılı bir şekilde bağlanıyor.

İlgili olması durumunda, OS X 10.6.8, Java sürüm 1.6.0_26 kullanıyorum.

Sorun asal boyut. Java'nın kabul ettiği maksimum kabul edilebilir boyut 1024 bittir. Bu bilinen bir sorundur (bkz. JDK-6521495 ).

Bağlandığım hata raporu BouncyCastle'ın JCE uygulamasını kullanarak bir geçici çözümden bahsediyor . Umarım bu sizin için işe yarar.

GÜNCELLEME

Bu hata JDK-7044060 olarak bildirildi ve son zamanlarda düzeltildi.

Bununla birlikte, sınırın sadece 2048 bit'e yükseltildiğine dikkat edin. 2048 bit'ten büyük boyutlar için JDK-8072452 vardır - DH Anahtarlarının maksimum ana boyutunu kaldırın ; düzeltme 9 için görünüyor.

"Java Şifreleme Uzantısı (JCE) Sınırsız Gücü Yargı Yetkisi Politikası Dosyaları" yanıtı benim için işe yaramadı, ancak BouncyCastle'ın JCE sağlayıcı önerisi işe yaradı.

Mac OSC 10.7.5'te Java 1.6.0_65-b14-462'yi kullanarak attığım adımlar şunlardır

1) Bu kavanozları indirin:

• bcprov-jdk15on-154.jar

• bcprov-ext-jdk15on-154.jar

2) Bu kavanozları $ JAVA_HOME / lib / ext dizinine taşıyın

3) $ JAVA_HOME / lib / security / java.security'yi aşağıdaki gibi düzenleyin: security.provider.1 = org.bouncycastle.jce.provider.BouncyCastleProvider

JRE kullanarak uygulamayı yeniden başlatın ve bir deneyin

İşte benim çözüm (java 1.6), ayrıca neden bunu yapmak zorunda kaldım:

Javax.security.debug = ssl, bazen kullanılan şifre paketinin TLS_DHE _... olduğunu ve bazen TLS_ECDHE _.... olduğunu fark ettim. TLS_ECDHE_ seçildiyse, ÇOK ÇALIŞTI, ancak HER ZAMAN değil, bu nedenle BouncyCastle sağlayıcısı bile eklenemezdi (her defasında aynı hata ile başarısız oldu). Sun SSL uygulamasında bir yerlerde bazen DHE , bazen ECDHE'yi seçiyorum .

Burada yayınlanan çözüm TLS_DHE_ şifrelemelerini tamamen kaldırmaya dayanıyor. NOT: Çözüm için BouncyCastle gerekli DEĞİLDİR.

Sunucu sertifikası dosyasını şu şekilde oluşturun:

echo |openssl s_client -connect example.org:443 2>&1 |sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'

TLS_DHE_ şifre süitleri hariç, daha sonra atıfta bulunulacağı için bunu bir SSL http get için çözüm olarak kaydedin.

package org.example.security;

import java.io.BufferedInputStream;
import java.io.BufferedReader;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.net.InetAddress;
import java.net.Socket;
import java.net.URL;
import java.net.UnknownHostException;
import java.security.KeyStore;
import java.security.cert.Certificate;
import java.security.cert.CertificateFactory;
import java.security.cert.X509Certificate;
import java.util.ArrayList;
import java.util.List;

import javax.net.ssl.HttpsURLConnection;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLParameters;
import javax.net.ssl.SSLSocket;
import javax.net.ssl.SSLSocketFactory;
import javax.net.ssl.TrustManagerFactory;

import org.apache.log4j.Logger;

public class SSLExcludeCipherConnectionHelper {

    private Logger logger = Logger.getLogger(SSLExcludeCipherConnectionHelper.class);

    private String[] exludedCipherSuites = {"_DHE_","_DH_"};

    private String trustCert = null;

    private TrustManagerFactory tmf;

    public void setExludedCipherSuites(String[] exludedCipherSuites) {
        this.exludedCipherSuites = exludedCipherSuites;
    }

    public SSLExcludeCipherConnectionHelper(String trustCert) {
        super();
        this.trustCert = trustCert;
        //Security.addProvider(new BouncyCastleProvider());
        try {
            this.initTrustManager();
        } catch (Exception ex) {
            ex.printStackTrace();
        }
    }

    private void initTrustManager() throws Exception {
        CertificateFactory cf = CertificateFactory.getInstance("X.509");
        InputStream caInput = new BufferedInputStream(new FileInputStream(trustCert));
        Certificate ca = null;
        try {
            ca = cf.generateCertificate(caInput);
            logger.debug("ca=" + ((X509Certificate) ca).getSubjectDN());
        } finally {
            caInput.close();
        }

        // Create a KeyStore containing our trusted CAs
        KeyStore keyStore = KeyStore.getInstance("jks");
        keyStore.load(null, null);
        keyStore.setCertificateEntry("ca", ca);

        // Create a TrustManager that trusts the CAs in our KeyStore
        String tmfAlgorithm = TrustManagerFactory.getDefaultAlgorithm();
        tmf = TrustManagerFactory.getInstance(tmfAlgorithm);
        tmf.init(keyStore);
    }

    public String get(URL url) throws Exception {
        // Create an SSLContext that uses our TrustManager
        SSLContext context = SSLContext.getInstance("TLS");
        context.init(null, tmf.getTrustManagers(), null);
        SSLParameters params = context.getSupportedSSLParameters();
        List<String> enabledCiphers = new ArrayList<String>();
        for (String cipher : params.getCipherSuites()) {
            boolean exclude = false;
            if (exludedCipherSuites != null) {
                for (int i=0; i<exludedCipherSuites.length && !exclude; i++) {
                    exclude = cipher.indexOf(exludedCipherSuites[i]) >= 0;
                }
            }
            if (!exclude) {
                enabledCiphers.add(cipher);
            }
        }
        String[] cArray = new String[enabledCiphers.size()];
        enabledCiphers.toArray(cArray);

        // Tell the URLConnection to use a SocketFactory from our SSLContext
        HttpsURLConnection urlConnection =
            (HttpsURLConnection)url.openConnection();
        SSLSocketFactory sf = context.getSocketFactory();
        sf = new DOSSLSocketFactory(sf, cArray);
        urlConnection.setSSLSocketFactory(sf);
        BufferedReader in = new BufferedReader(new InputStreamReader(urlConnection.getInputStream()));
        String inputLine;
        StringBuffer buffer = new StringBuffer();
        while ((inputLine = in.readLine()) != null) 
            buffer.append(inputLine);
        in.close();

        return buffer.toString();
    }

    private class DOSSLSocketFactory extends javax.net.ssl.SSLSocketFactory {

        private SSLSocketFactory sf = null;
        private String[] enabledCiphers = null;

        private DOSSLSocketFactory(SSLSocketFactory sf, String[] enabledCiphers) {
            super();
            this.sf = sf;
            this.enabledCiphers = enabledCiphers;
        }

        private Socket getSocketWithEnabledCiphers(Socket socket) {
            if (enabledCiphers != null && socket != null && socket instanceof SSLSocket)
                ((SSLSocket)socket).setEnabledCipherSuites(enabledCiphers);

            return socket;
        }

        @Override
        public Socket createSocket(Socket s, String host, int port,
                boolean autoClose) throws IOException {
            return getSocketWithEnabledCiphers(sf.createSocket(s, host, port, autoClose));
        }

        @Override
        public String[] getDefaultCipherSuites() {
            return sf.getDefaultCipherSuites();
        }

        @Override
        public String[] getSupportedCipherSuites() {
            if (enabledCiphers == null)
                return sf.getSupportedCipherSuites();
            else
                return enabledCiphers;
        }

        @Override
        public Socket createSocket(String host, int port) throws IOException,
                UnknownHostException {
            return getSocketWithEnabledCiphers(sf.createSocket(host, port));
        }

        @Override
        public Socket createSocket(InetAddress address, int port)
                throws IOException {
            return getSocketWithEnabledCiphers(sf.createSocket(address, port));
        }

        @Override
        public Socket createSocket(String host, int port, InetAddress localAddress,
                int localPort) throws IOException, UnknownHostException {
            return getSocketWithEnabledCiphers(sf.createSocket(host, port, localAddress, localPort));
        }

        @Override
        public Socket createSocket(InetAddress address, int port,
                InetAddress localaddress, int localport) throws IOException {
            return getSocketWithEnabledCiphers(sf.createSocket(address, port, localaddress, localport));
        }

    }
}

Son olarak şu şekilde kullanılır (certFilePath, sertifikanın yolu openssl'den kaydedilmişse):

try {
            URL url = new URL("https://www.example.org?q=somedata");            
            SSLExcludeCipherConnectionHelper sslExclHelper = new SSLExcludeCipherConnectionHelper(certFilePath);
            logger.debug(
                    sslExclHelper.get(url)
            );
        } catch (Exception ex) {
            ex.printStackTrace();
        }

Yukarıdaki cevap doğrudur, ancak geçici olarak, tercih edilen sağlayıcı olarak ayarladığımda BouncyCastle uygulamasında sorunlar yaşadım:

java.lang.ArrayIndexOutOfBoundsException: 64
    at com.sun.crypto.provider.TlsPrfGenerator.expand(DashoA13*..)

Bu aynı zamanda bulduğum bir forum dizisinde de tartışılıyor, ki bu bir çözümden bahsetmiyor. http://www.javakb.com/Uwe/Forum.aspx/java-programmer/47512/TLS-problems

Durumumda işe yarayan alternatif bir çözüm buldum, ancak hiç memnun değilim. Çözüm, Diffie-Hellman algoritmasının hiç kullanılamayacağı şekilde ayarlamaktır. Daha sonra, sunucunun alternatif bir algoritmayı desteklediğini varsayarsak, normal görüşme sırasında seçilecektir. Bunun dezavantajı, eğer birisi bir şekilde sadece 1024 bit veya daha az Diffie-Hellman'ı destekleyen bir sunucu bulmayı başarırsa, bu aslında daha önce çalıştığı yerde çalışmayacağı anlamına gelir.

SSLSocket verildiğinde çalışan kod (bağlamadan önce):

List<String> limited = new LinkedList<String>();
for(String suite : ((SSLSocket)s).getEnabledCipherSuites())
{
    if(!suite.contains("_DHE_"))
    {
        limited.add(suite);
    }
}
((SSLSocket)s).setEnabledCipherSuites(limited.toArray(
    new String[limited.size()]));

Pis.

DHE'yi jdk'nizde tamamen devre dışı bırakabilir, jre / lib / security / java.security'yi düzenleyebilir ve DHE'nin devre dışı bırakıldığından emin olabilirsiniz, örn. sevmek

jdk.tls.disabledAlgorithms=SSLv3, DHE.

Sağlayıcıyı dinamik olarak yükleyebilirsiniz:

1) Bu kavanozları indirin:

• bcprov-jdk15on-152.jar
• bcprov-ext-jdk15on-152.jar

2) Kavanozları WEB-INF/lib(veya sınıf yolunuza) kopyalayın

3) Sağlayıcıyı dinamik olarak ekleyin:

import org.bouncycastle.jce.provider.BouncyCastleProvider;

...

Security.addProvider(new BouncyCastleProvider());

Bu oldukça eski bir gönderi, ancak Apache HTTPD kullanıyorsanız, DH boyutunu sınırlayabilirsiniz. Bkz. Http://httpd.apache.org/docs/current/ssl/ssl_faq.html#javadh

Jdk1.7.0_04 kullanıyorsanız, jdk1.7.0_21 sürümüne geçin. Bu güncellemede sorun giderildi.

Maven bağımlılıklarınız yanlış olabilir. Maven bağımlılık hiyerarşisinde şu kütüphaneleri bulmalısınız:

bcprov-jdk14, bcpkix-jdk14, bcmail-jdk14

Hata olan bu bağımlılıklarınız varsa ve bunu yapmanız gerekir:

Bağımlılığı ekleyin:

<dependency>
    <groupId>org.bouncycastle</groupId>
    <artifactId>bcmail-jdk15on</artifactId>
    <version>1.59</version>
</dependency>

Bu bağımlılıkları yanlış bağımlılıkları içeren yapay nesneden hariç tut, benim durumumda:

<dependency>
    <groupId>com.lowagie</groupId>
    <artifactId>itext</artifactId>
    <version>2.1.7</version>
    <exclusions>
        <exclusion>
            <groupId>org.bouncycastle</groupId>
            <artifactId>bctsp-jdk14</artifactId>                
        </exclusion>
        <exclusion>
            <groupId>bouncycastle</groupId>
            <artifactId>bcprov-jdk14</artifactId>               
        </exclusion>
        <exclusion>
            <groupId>bouncycastle</groupId>
            <artifactId>bcmail-jdk14</artifactId>               
        </exclusion>
    </exclusions>       
</dependency>

Java indirme sitesinden "Java Şifreleme Uzantısı (JCE) Sınırsız Güç Yargı Yetkisi Politikası Dosyaları" nı indirmeyi deneyin ve JRE'nizdeki dosyaları değiştirmeyi .

Bu benim için çalıştı ve hatta BouncyCastle kullanmak gerek yoktu - standart Sun JCE sunucuya bağlanabildi.

PS. Politika dosyalarını değiştirmeden önce BouncyCastle kullanarak denediğimde aynı hatayı aldım (ArrayIndexOutOfBoundsException: 64), bu yüzden durumumuz çok benzer görünüyor.

Hala bu sorundan ısırılırsanız VE sen Apache v> 2.4.7, bu deneyin kullanıyor: http://httpd.apache.org/docs/current/ssl/ssl_faq.html#javadh

url'den kopyalandı :

2.4.7 sürümünden başlayarak mod_ssl, 1024 bit'ten daha uzun uzunluklu primerler içeren DH parametrelerini kullanacaktır. Bununla birlikte, Java 7 ve önceki sürümleri DH ana boyutları için desteklerini en fazla 1024 bit ile sınırlar.

Java tabanlı istemciniz java.lang.RuntimeException gibi istisnalarla iptal ederse: DH anahtar çifti ve java.security oluşturulamadı.InvalidAlgorithmParameterException: Prime boyutu 64'ten fazla olmalı ve yalnızca 512 ile 1024 (dahil) arasında değişebilir ve httpd tlsv1 uyarısı dahili hatasını (SSL uyarı numarası 80) (LogLevel bilgisinde veya daha yüksekte) kaydeder, mod_ssl'nin şifreleme listesini SSLCipherSuite ile (muhtemelen SSLHonorCipherOrder ile bağlantılı olarak) yeniden düzenleyebilir veya 1024-bit prime ile özel DH parametreleri kullanabilirsiniz yerleşik DH parametrelerinden her zaman önceliğe sahiptir.

Özel DH parametreleri oluşturmak için

openssl dhparam 1024

Komut. Alternatif olarak, RFC 2409, bölüm 6.2'den aşağıdaki standart 1024-bit DH parametrelerini kullanabilirsiniz:

-----BEGIN DH PARAMETERS-----
MIGHAoGBAP//////////yQ/aoiFowjTExmKLgNwc0SkCTgiKZ8x0Agu+pjsTmyJR
Sgh5jjQE3e+VGbPNOkMbMCsKbfJfFDdP4TVtbVHCReSFtXZiXn7G9ExC6aY37WsL
/1y29Aa37e44a/taiZ+lrp8kEXxLH+ZJKGZR7OZTgf//////////AgEC
-----END DH PARAMETERS-----

SSLCertificateFile yönergesini kullanarak yapılandırdığınız ilk sertifika dosyasının sonuna "BEGIN DH PARAMETERS" ve "END DH PARAMETERS" satırlarını içeren özel parametreleri ekleyin.

Java 1.6'yı istemci tarafında kullanıyorum ve sorunumu çözdü. Ben şifre takımları veya benzeri indirmedi, ama sertifika dosyasına özel oluşturulan bir DH param ekledi ..

Yandex Maps sunucusu, JDK 1.6 ve Apache HttpClient 4.2.1 ile aynı problemim var. Hata:

javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated

tarafından etkin hata ayıklama ile -Djavax.net.debug=all bir günlükte bir mesaj vardı

Could not generate DH keypair

BouncyCastle kitaplığı ekleyerek bcprov-jdk16-1.46.jarve bir harita hizmet sınıfında bir sağlayıcı kaydederek bu sorunu giderdim

public class MapService {

    static {
        Security.addProvider(new BouncyCastleProvider());
    }

    public GeocodeResult geocode() {

    }

}

Bir sağlayıcı, ilk kullanımında kayıtlıdır MapService.

JDK 6 çalıştıran bir CentOS sunucusunda SSL hatasıyla karşılaştım.

Planım, JDK 6 ile birlikte var olmak için daha yüksek bir JDK sürümü (JDK 7) yüklemekti, ancak sadece yeni JDK'yı rpm -i yeterli olmadığı ortaya çıktı.

JDK 7 yüklemesi yalnızca rpm -U aşağıda gösterildiği gibi yükseltme seçeneğiyle .

1. JDK 7'yi indirin

wget -O /root/jdk-7u79-linux-x64.rpm --no-cookies --no-check-certificate --header "Cookie: gpw_e24=http%3A%2F%2Fwww.oracle.com%2F; o raclelicense=accept-securebackup-cookie" "http://download.oracle.com/otn-pub/java/jdk/7u79-b15/jdk-7u79-linux-x64.rpm"

2. RPM kurulumu başarısız

rpm -ivh jdk-7u79-linux-x64.rpm
Preparing...                ########################################### [100%]
        file /etc/init.d/jexec from install of jdk-2000:1.7.0_79-fcs.x86_64 conflicts with file from package jdk-2000:1.6.0_43-fcs.x86_64

3. RPM yükseltme başarılı

rpm -Uvh jdk-7u79-linux-x64.rpm
Preparing...                ########################################### [100%]
   1:jdk                    ########################################### [100%]
Unpacking JAR files...
        rt.jar...
        jsse.jar...
        charsets.jar...
        tools.jar...
        localedata.jar...
        jfxrt.jar...

4. Yeni sürümü onaylayın

java -version
java version "1.7.0_79"
Java(TM) SE Runtime Environment (build 1.7.0_79-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.79-b02, mixed mode)

JDK 8'e yükselterek sorunu çözdüm.

JDK 1.6.45'te coldfusion 8 kullanıyorum ve bana görüntüler yerine sadece kırmızı haçlar vermekle ilgili sorunlar yaşadım ve ayrıca cfhttp ile ssl ile yerel web sunucusuna bağlanamadım.

coldfusion 8 ile çoğaltılacak test senaryom

<CFHTTP URL="https://www.onlineumfragen.com" METHOD="get" ></CFHTTP>
<CFDUMP VAR="#CFHTTP#">

bu bana "I / O İstisna: eş kimliği doğrulanmadı" gibi oldukça genel bir hata verdi. Daha sonra java anahtar deposuna ve ayrıca coldfusion anahtar deposuna kök ve ara sertifikalar dahil olmak üzere sunucunun sertifikalarını eklemeye çalıştım, ancak hiçbir şey yardımcı olmadı. sonra sorunu ayıkladım

java SSLPoke www.onlineumfragen.com 443

ve var

javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair

ve

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:107)
    ... 10 more

Sonra web sunucusu (benim durumumda apache) ssl için çok modern şifreleri vardı ve oldukça kısıtlayıcı (qualys puanı a +) ve 1024'ten fazla bit ile güçlü diffie hellmann anahtarları kullanır fikrini vardı. Açıkçası, coldfusion ve java jdk 1.6.45 bunu yönetemez. Odysee'deki bir sonraki adım, java için alternatif bir güvenlik sağlayıcı kurmayı düşünmekti ve bouncy kaleye karar verdim. ayrıca bkz. http://www.itcsolutions.eu/2011/08/22/how-to-use-bouncy-castle-cryptographic-api-in-netbeans-or-eclipse-for-java-jse-projects/

Sonra indirdim

bcprov-ext-jdk15on-156.jar

dan http://www.bouncycastle.org/latest_releases.html ve C altında yüklü: \ jdk6_45 \ jre \ lib \ ext veya jdk olduğu bir zamanda, orijinal o C altında olacağını coldfusion 8 yükleyin: \ JRun4 \ jre \ lib \ ext ama coldfusion dizininin dışında bulunan daha yeni bir jdk (1.6.45) kullanıyorum. bcprov-ext-jdk15on-156.jar dosyasını \ ext dizinine koymak çok önemlidir (bu bana yaklaşık iki saat ve biraz saç maliyeti ;-) sonra C: \ jdk6_45 \ jre \ lib \ security \ dosyasını düzenledim java.security (wordpad ile editör.exe ile değil!) ve yeni sağlayıcı için bir satıra yerleştirin. daha sonra liste şöyle görünüyordu

#
# List of providers and their preference orders (see above):
#
security.provider.1=org.bouncycastle.jce.provider.BouncyCastleProvider
security.provider.2=sun.security.provider.Sun
security.provider.3=sun.security.rsa.SunRsaSign
security.provider.4=com.sun.net.ssl.internal.ssl.Provider
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider
security.provider.7=com.sun.security.sasl.Provider
security.provider.8=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.9=sun.security.smartcardio.SunPCSC
security.provider.10=sun.security.mscapi.SunMSCAPI

(konum 1'deki yenisine bakın)

ardından coldfusion hizmetini tamamen yeniden başlatın. o zaman yapabilirsin

java SSLPoke www.onlineumfragen.com 443 (or of course your url!)

ve hislerin tadını çıkarın ... ve tabii ki

ne gece, ne gündüz. Umarım bu (kısmen veya tamamen) dışarıdaki birine yardım eder. sorularınız varsa, bana bilgi gönderin ... (yukarıdaki alan adı).

Sunucu DH içermeyen bir şifreyi destekliyorsa, istemciyi bu şifreyi seçmeye zorlayabilir ve DH hatasını önleyebilirsiniz. Gibi:

String pickedCipher[] ={"TLS_RSA_WITH_AES_256_CBC_SHA"};
sslsocket.setEnabledCipherSuites(pickedCipher);

Tam bir şifre belirtmenin uzun vadede kırılmaya eğilimli olduğunu unutmayın.

İnternet'te sörf saat sonra kolay oldu düzeltmek için döndürülen aynı istisna hatası aldık.

Oracle.com'da bulabileceğimiz jdk'nin en yüksek sürümünü indirdik, yükledik ve Jboss uygulama sunucusunu kurulu yeni jdk dizinine yönlendirdik.

Yeniden başlatılan Jboss, yeniden işlenmiş, sorun düzeltildi !!!

Bamboo 5.7 + Gradle projesi + Apache ile bu hatayı aldım. Gradle, SSL ile sunucularımızdan birinden bazı bağımlılıklar almaya çalıştı.

Çözüm:

1. DH Param Üret:

OpenSSL ile:

openssl dhparam 1024

örnek çıktı:

-----BEGIN DH PARAMETERS-----
MIGHfoGBALxpfMrDpImEuPlhopxYX4L2CFqQov+FomjKyHJrzj/EkTP0T3oAkjnS
oCGh6p07kwSLS8WCtYJn1GzItiZ05LoAzPs7T3ST2dWrEYFg/dldt+arifj6oWo+
vctDyDqIjlevUE+vyR9MF6B+Rfm4Zs8VGkxmsgXuz0gp/9lmftY7AgEC
-----END DH PARAMETERS-----

2. Sertifika dosyasına çıktı ekle (Apache - SSLCertificateFileparam için)

3. Apache'yi yeniden başlat

4. Bambu Yeniden Başlat

5. Yeniden proje oluşturmaya çalışın

IBM JDK kullanarak jav SVN istemcileri ile svn.apache.org'a erişirken benzer bir hata alırdım. Şu anda, svn.apache.org kullanıcıları istemcilerin tercihlerini şifreler.

Bir paket yakalama / javax.net.debug = ALL ile sadece bir kez çalıştırdıktan sonra sadece tek bir DHE şifresini kara listeye alabildim ve işler benim için işe yarıyor (bunun yerine ECDHE müzakere ediliyor).

.../java/jre/lib/security/java.security:
    jdk.tls.disabledAlgorithms=SSL_DHE_RSA_WITH_AES_256_CBC_SHA

İstemciyi değiştirmek kolay olmadığında güzel bir hızlı düzeltme.

Son zamanlarda aynı sorunu ve yükseltme jdk sürümünden sonra sahip 1.6.0_45 için jdk1.7.0_191 sorunu çözüldü.

Benim için aşağıdaki komut satırı sorunu çözdü:

java -jar -Dhttps.protocols=TLSv1.2 -Ddeployment.security.TLSv1.2=true -Djavax.net.debug=ssl:handshake XXXXX.jar

JDK kullanıyorum 1.7.0_79