SSL हैंडशेक 'डीएच कीपर' अपवाद क्यों नहीं दे सकता है?

142

जब मैं कुछ आईआरसी सर्वरों के साथ एक एसएसएल कनेक्शन बनाता हूं (लेकिन अन्य नहीं - सर्वर की पसंदीदा एन्क्रिप्शन विधि के कारण संभवतः) मुझे निम्न अपवाद मिलते हैं:

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

अंतिम कारण:

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

सर्वर का एक उदाहरण जो इस समस्या को प्रदर्शित करता है वह है aperture.esper.net:6697 (यह एक IRC सर्वर है)। सर्वर का एक उदाहरण जो समस्या को प्रदर्शित नहीं करता है वह है kornbluth.freenode.net:6697। [आश्चर्य की बात नहीं, प्रत्येक नेटवर्क पर सभी सर्वर एक ही संबंधित व्यवहार साझा करते हैं।]

मेरा कोड (जो कुछ एसएसएल सर्वर से कनेक्ट होने पर काम करता है) है:

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

यह आखिरी शुरुआत है, जो अपवाद को फेंकता है। और हाँ 'ट्रस्टएल्कॉर्ट्स' के साथ कुछ जादू चल रहा है; वह कोड SSL सिस्टम को मजबूर करता है कि वह सीट्स को मान्य न करे। (अतः प्रमाणित समस्या नहीं है।)

स्पष्ट रूप से एक संभावना यह है कि एस्पर का सर्वर गलत है, लेकिन मैंने खोज की और एस्पर के एसएसबी पोर्ट के साथ समस्या वाले लोगों को कोई अन्य संदर्भ नहीं मिला, और 'ओपनसेल' इससे जुड़ता है (नीचे देखें)। तो मैं सोच रहा था कि यह जावा डिफ़ॉल्ट एसएसएल समर्थन, या कुछ और की एक सीमा है। कोई सुझाव?

यहाँ तब होता है जब मैं aperture.esper.net से कनेक्ट होता हूँ 6697 कमांडलाइन से 'ओपनस्लैल' का उपयोग करके:

~ $ 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)
---

जैसा कि कहा गया है, आखिरकार, यह सफलतापूर्वक कनेक्ट होता है जो मेरे जावा ऐप के लिए कह सकता है।

क्या यह प्रासंगिक होना चाहिए, मैं ओएस एक्स 10.6.8, जावा संस्करण 1.6.0_26 का उपयोग कर रहा हूं।

java  ssl  cryptography  diffie-hellman 
— सैम
स्रोत
2
कारण यह प्रतीत होता है Prime size must be multiple of 64, and can only range from 512 to 1024 (inclusive):। यह पता नहीं है कि सर्वर द्वारा किस आकार को यहां भेजा गया था, और विनिर्देश इस बारे में क्या कहते हैं।
— पाओलो एबरमन जू
@ Pa @loEbermann: वास्तव में आप opensslप्रश्न में आउटपुट में प्रयुक्त सर्वर का आकार देख सकते हैं : "सिफर डीएचई-आरएसए-एईएस 256-एसएचए है, सर्वर सार्वजनिक कुंजी 2048 बिट है"। और 2048> 1024 :-)।
— sleske
@ स्लेस्क: बिल्कुल नहीं। Server public key (size)है, और है, प्रमाणपत्र में कुंजी है। s_client2011 में अल्पकालिक कुंजी बिल्कुल नहीं दिखाई गई; 2015 में 1.0.2 और ऊपर Server Temp Keyकई लाइनों के रूप में अधिक है। हालांकि एक अच्छा सर्वर आमतौर पर डीएचई आकार को आरएसए-ऑर्टिकल आकार के समान बनाना चाहिए ।
— dave_thompson_085

जवाबों:

117

समस्या मुख्य आकार है। जावा स्वीकार करता है कि अधिकतम स्वीकार्य आकार 1024 बिट्स है। यह एक ज्ञात मुद्दा है (देखें JDK-6521495 )।

बग रिपोर्ट जिसे मैंने बाउंसीकैसल के जेसीई कार्यान्वयन का उपयोग करके वर्कअराउंड का उल्लेख किया है। उम्मीद है कि आप के लिए काम करना चाहिए।

अपडेट करें

यह बग JDK-7044060 के रूप में रिपोर्ट किया गया था और हाल ही में तय किया गया था।

हालाँकि, ध्यान दें कि यह सीमा केवल 2048 बिट तक बढ़ाई गई थी। आकारों के लिए> 2048 बिट में, JDK-8072452 है - डीएच कीज का अधिकतम प्राइम आकार निकालें ; तय 9 के लिए प्रतीत होता है।

— विविन पालीथ
स्रोत
14
+1। हर कोई जिसके पास Sun Developer Network Account है, कृपया इस बग को वोट करें।
— पाओलो एबरमन
1
धन्यवाद। सर्वरों के अस्तित्व को देखते हुए एक बहुत गंभीर समस्या का कारण बनता है जो एक बड़े आकार का अनुरोध करता है! :( मैंने बाउंसीकैस्टल की कोशिश की; यदि आप इसे पसंदीदा प्रदाता के रूप में सेट करते हैं तो यह एक अलग अपवाद (आह) के साथ दुर्घटनाग्रस्त हो जाता है, और मैं केवल डीएच के लिए इसका उपयोग करने का एक स्पष्ट तरीका नहीं देख सकता हूं। हालांकि, मुझे एक वैकल्पिक समाधान मिला, जिसे मैंने देखा। 'एक नए उत्तर के रूप में जोड़ दूंगा। (यह सुंदर नहीं है।)
— सैम
3
ठंडा। यह जावा के नए संस्करणों में तय किया गया है। लेकिन मेरा प्रश्न पुराने संस्करण का उपयोग करने के बारे में है .. जब मैं पुराने संस्करण का उपयोग करता हूं, तो कभी-कभी यह काम करता है और कभी-कभी यह अपवाद से ऊपर होता है। इतना यादृच्छिक व्यवहार क्यों? अगर जावा में इसका बग है, तो मुझे लगता है कि इसे कभी काम नहीं करना चाहिए?
— एन ..
2
2048 के निर्धारण को IcedTea 2.5.3 पर वापस भेज दिया गया था। IcedTea के नए संस्करणों ने इसे 4096 तक बढ़ा दिया।
— fuzzyTew
1
समस्या डीएच प्राइम आकार है। जावा स्वीकार करता है कि अधिकतम स्वीकार्य आकार 2048 बिट्स है। जब हम सीमा का विस्तार करने के लिए ओरेकल की प्रतीक्षा करते हैं, तो आप एक्सेलसियर जेट के साथ संकलित कर सकते हैं जिसमें विस्तारित सीमा होती है।
— user1332994
67

"जावा क्रिप्टोग्राफी एक्सटेंशन (जेसीई) असीमित शक्ति क्षेत्राधिकार नीति फाइलें" उत्तर मेरे लिए काम नहीं किया, लेकिन बाउंसीकैसल के जेसीई प्रदाता ने सुझाव दिया।

यहां मैंने मैक ओएससी 10.7.5 पर जावा 1.6.0_65-b14-462 का उपयोग करने वाले कदम उठाए हैं

1) ये जार डाउनलोड करें:

2) इन जार को $ JAVA_HOME / lib / ext में ले जाएं

3) $ JAVA_HOME / lib / सुरक्षा / java.security को इस प्रकार संपादित करें: सुरक्षा ।provider.1 = org.b Councilycastle.jce.provider.BouncyCastleProvider

JRE का उपयोग करके ऐप को पुनरारंभ करें और इसे आज़माएं

— mjj1409
स्रोत
5
मेरे लिये कार्य करता है! हालांकि मुझे यकीन नहीं है कि मैं क्या कर रहा हूं।
— DiveInto
11
Security.provider.2 = org.b Councilycastle.jce.provider.BouncyCastleProvider ने बेहतर काम किया, इसे 1 पर रखा। जिसके परिणामस्वरूप डिफ़ॉल्ट सॉफ़्टवेयर में त्रुटियां हुईं।
— टीनुसस्की
1
यह मेरे लिए भी काम करता है, लेकिन मैंने एक प्रदाता को गतिशील रूप से जोड़ा है। विवरण के लिए यहां अपना उत्तर दें ।
— v.ladynev
एक टन का धन्यवाद, यह मेरे लिए काम करता था और टॉमकैट 7.0.78 स्रोत को सफलतापूर्वक बनाने के लिए आवश्यक था।
— फिलिप्पुविवर्स
@ mjj1409, जावा 1.5 में हमारे पास $ JAVA_HOME / lib / सुरक्षा पथ नहीं है
— Mostafa
15

यहाँ मेरा समाधान है (जावा 1.6), यह भी दिलचस्पी होगी कि मुझे ऐसा क्यों करना पड़ा:

मैंने javax.security.debug = ssl से देखा, कि कभी-कभी इस्तेमाल किया जाने वाला सिफर सूट TLS_DHE _... होता है और कभी-कभी यह TLS_ECDHE _In होता है। बाद में ऐसा होगा जब मैंने जौसीकैस्टल जोड़ा। यदि TLS_ECDHE_ का चयन किया गया था, तो उस समय के MOST ने काम किया था, लेकिन हमेशा नहीं, इसलिए BouncyCastle प्रदाता को भी जोड़ना अविश्वसनीय था (एक ही त्रुटि के साथ विफल रहा, हर दूसरे समय या तो)। मैंने कहीं सूर्य एसएसएल कार्यान्वयन में लगता है कि कभी कभी यह चयन DHE , कभी कभी यह चुनें ECDHE ।

तो यहाँ पर समाधान पूरी तरह से TLS_DHE_ सिफर को हटाने पर निर्भर करता है। नोट: BouncyCastle समाधान के लिए आवश्यक नहीं है।

इसलिए सर्वर सर्टिफिकेशन फाइल बनाएं:

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

इसे सहेजें क्योंकि यह बाद में संदर्भित किया जाएगा, यहाँ से SSL SSL समाधान के लिए समाधान है, TLS_DHE_ सिफर सुइट्स को छोड़कर।

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

    }
}

अंत में यहां बताया गया है कि इसका उपयोग कैसे किया जाता है (अगर सर्टिफिकेट का रास्ता खुलता है)

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();
        }
— Zsozso
स्रोत
9
बस अपने समाधान का परीक्षण किया। यह इरादा के अनुसार काम कर रहा है। धन्यवाद। दरअसल, सिर्फ जोड़ने jdk.tls.disabledAlgorithms=DHE, ECDHEसे JDK_HOME/jre/lib/security/java.securityभी काम चलता है और इस सारे कोड से बचते हैं।
— लुडोविक गुइल्यूम
3
बस अक्षम करने वाले डीएचई ने मेरे लिए काम किया jdk.tls.disabledAlgorithms=DHE:। 1.7.0_85-b15 का उपयोग करना।
— Stephan f
1
जोड़ा गया jdk.tls.disabledAl एल्गोरिदम = DHE, EDHE JDK_HOME / jre / lib / security / java.security में और ठीक काम किया! धन्यवाद! 1.7.0_79 का उपयोग करते हुए
— एरिक ना
1
ECDHE को अक्षम न करें। यह डीएचई से अलग है और प्राइम नंबर का उपयोग भी नहीं करता है।
— कुबंझक
1
क्या कोई मुझे बता सकता है कि मैं 'सर्टिफिकेट' कैसे प्राप्त कर सकता हूं। मैं इस पर एक हफ्ते से अटका हुआ हूं। @Zsozso
— user1172490
13

उपरोक्त उत्तर सही है, लेकिन वर्कअराउंड के संदर्भ में, मुझे BouncyCastle कार्यान्वयन के साथ समस्या थी जब मैंने इसे पसंदीदा प्रदाता के रूप में सेट किया:

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

यह मैंने पाया एक फोरम थ्रेड में भी चर्चा की गई है, जो एक समाधान का उल्लेख नहीं करता है। http://www.javakb.com/Uwe/Forum.aspx/java-programmer/47512/TLS-problems

मुझे एक वैकल्पिक समाधान मिला जो मेरे मामले के लिए काम करता है, हालांकि मैं इससे बिल्कुल भी खुश नहीं हूं। इसका समाधान यह है कि डिफी-हेलमैन एल्गोरिथम बिल्कुल भी उपलब्ध नहीं है। फिर, सर्वर को दबाने से एक वैकल्पिक एल्गोरिदम का समर्थन होता है, यह सामान्य बातचीत के दौरान चयन होगा। जाहिर तौर पर इसका नकारात्मक पक्ष यह है कि अगर कोई किसी तरह एक सर्वर ढूंढता है जो केवल 1024 बिट्स या उससे कम पर डिफी-हेलमैन का समर्थन करता है, तो वास्तव में इसका मतलब यह नहीं होगा कि यह पहले जहां काम करता था।

यहां एक कोड दिया गया है जो एक SSLSocket दिया गया है (इससे पहले कि आप इसे कनेक्ट करें):

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

बुरा।

— सैम
स्रोत
1
दुखद यह है कि यह एकमात्र तरीका है :(। वह टिकट '07 के बाद से खुला है। अजीब बात है कि 4 साल में कुछ भी नहीं किया गया है।
— विविन पालीथ
मैं जावा सिक्योरिटीज के लिए नया हूं। कृपया मदद करें कि मुझे यह कोड कहां लिखना चाहिए?
— शशांक
मैंने इस धागे में हर समाधान की कोशिश की और यह एकमात्र ऐसा था जिसने मेरे इब्म जेवीएम (ibm-java-s390x-60) के साथ काम किया।
— गियानलुका ग्रीको
@Sam, (SSLSocket) s में क्या परिवर्तनशील है?
— मुस्तफा
13

आप DHE को पूरी तरह से अपने jdk में अक्षम कर सकते हैं, jre / lib / Security / java.security को संपादित कर सकते हैं और सुनिश्चित कर सकते हैं कि DHE अक्षम है, उदा। पसंद

jdk.tls.disabledAlgorithms=SSLv3, DHE।

— टो
स्रोत
4
यह केवल JDK 1.7 और बाद में उपलब्ध है। लिंक
— हुंगथियन
मेरे लिए समस्या का हल JDK 1.8.0_144-b01
— MrSmith42
12

आप प्रदाता को गतिशील रूप से स्थापित कर सकते हैं:

1) ये जार डाउनलोड करें:

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

2) कॉपी जार WEB-INF/lib(या अपने classpath)

3) गतिशील रूप से प्रदाता जोड़ें:

import org.bouncycastle.jce.provider.BouncyCastleProvider;

...

Security.addProvider(new BouncyCastleProvider());

— angelcorral
स्रोत
यह समाधान अच्छी तरह से काम करता है, और मेरे मामले के लिए एक अच्छा फिट था क्योंकि मैं केवल प्रोजेक्ट स्तर पर परिवर्तन करना चाहता था न कि सर्वर / पर्यावरण स्तर पर। धन्यवाद
— ishanbakshi
धन्यवाद! यह मेरे लिए काम किया। मेरे मामले में यह था it1 आयात bcp 1.4 Google को ईमेल विफल होने के कारण।
— जफेट ओन्गेरी - इंकलामेवा
मुझे javax.net.ssl.SSLHandshakeException मिल रही है: असमर्थित वक्र Id: 29 जावा संस्करण 1.6.0_27 के साथ
— एक और कोडर
6

यदि आप jdk1.7.0_04 का उपयोग कर रहे हैं, तो jdk1.7.0_21 में अपग्रेड करें। उस अद्यतन में समस्या ठीक कर दी गई है।

— Lekkie
स्रोत
2
मैंने अभी जावा एसई डेवलपमेंट किट 7u25 डाउनलोड किया है, और छोटे प्रोग्राम के अनुसार मैंने अधिकतम समर्थित डीएच आकार निर्धारित करने के लिए लिखा है , यह अभी भी 1024 है।
— user2666524
1
समस्या अभी भी JDK 1.7.0_25 के साथ मौजूद है
— सेबैस्टियन वैनमेचेलन जूल
अपडेटिंग jre ने मेरे लिए काम किया। समस्या सुलझ गयी।
— एलाजारन
1
@ शशांक - JDK 1.8.0_73 में अपग्रेड करना मेरे लिए काम किया।
— dgoverde
DHKeyPairs बिट लंबाई के साथ 1024 से अधिक JDK 1.7.0_91 से शुरू किया गया, लेकिन यह सार्वजनिक रूप से उपलब्ध नहीं है।
— एक और कोडर
6

यह संभव है कि आपके पास गलत मावेन निर्भरता हो। आपको मावेन निर्भरता पदानुक्रम में इन पुस्तकालयों को खोजना होगा:

bcprov-jdk14, bcpkix-jdk14, bcmail-jdk14

यदि आपके पास ये निर्भरताएं हैं जो त्रुटि है, और आपको यह करना चाहिए:

निर्भरता जोड़ें:

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

इन निर्भरताओं को उस आर्टिकल से बाहर करें जिसमें गलत निर्भरता शामिल थी, मेरे मामले में यह है:

<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>
— जोस एंटोनियो सेंचेज पुजांते
स्रोत
सवाल पहले से ही कई जवाब मिला है और एक मान्य जवाब है। इसके अलावा सवाल 6 साल से अधिक समय से पूछा गया है। मुझे यकीन नहीं है कि यह अभी भी प्रासंगिक है।
— डेविड गयोन
5

जावा डाउनलोड साइट से "जावा क्रिप्टोग्राफ़ी एक्सटेंशन (जेसीई) असीमित शक्ति क्षेत्राधिकार नीति फ़ाइलें" डाउनलोड करने और अपने जेआरई में फ़ाइलों को बदलने का प्रयास करें।

यह मेरे लिए काम करता था और मुझे BouncyCastle का उपयोग करने की भी आवश्यकता नहीं थी - मानक Sun JCE सर्वर से कनेक्ट करने में सक्षम था।

पुनश्च। मुझे वही त्रुटि मिली (ArrayIndexOutOfBoundsException: 64) जब मैंने पॉलिसी फाइलों को बदलने से पहले BouncyCastle का उपयोग करने की कोशिश की, तो ऐसा लगता है कि हमारी स्थिति बहुत समान है।

— mjomble
स्रोत
क्या आपने कुछ और किया है? या सिर्फ 2 फ़ाइलों को फ़ोल्डर में कॉपी किया?
— जोर्जी
यह एक समय हो गया है लेकिन जहां तक ​​मुझे याद है, वह सब मुझे करने की जरूरत थी। इसके बाद किसी भी चल रहे जावा प्रक्रियाओं को फिर से शुरू करने के अलावा।
— 20 अगस्त को
5

यदि आप अभी भी इस समस्या से कटे हुए हैं और आप Apache httpd v> 2.4.7 का उपयोग कर रहे हैं, तो यह प्रयास करें: http://httpd.apache.org/docs/current/ssl/ssl_faq.html#javadh

url से कॉपी किया गया :

संस्करण 2.4.7 से शुरू होकर, mod_ssl डीएच मापदंडों का उपयोग करेगा जिसमें 1024 बिट्स से अधिक की लंबाई वाले प्राइम शामिल हैं। जावा 7 और इससे पहले डीएच प्राइम साइज के लिए उनके समर्थन को अधिकतम 1024 बिट तक सीमित कर देता है।

यदि आपका जावा-आधारित क्लाइंट java.lang.RuntimeException जैसे अपवादों के साथ गर्भपात करता है: DH keypair और java.security.InvalidAl एल्गोरिदमपैरिमैरेप्शन अपवाद उत्पन्न नहीं कर सकता: प्रधानमंत्री का आकार 64 से अधिक होना चाहिए, और केवल 512 से 1024 (समावेशी), और हो सकता है httpd लॉग्स tlsv1 अलर्ट आंतरिक त्रुटि (SSL अलर्ट नंबर 80) (LogLevel जानकारी या उच्चतर पर), आप SSLCipherSuite के साथ mod_ssl की सिफर सूची को पुनर्व्यवस्थित कर सकते हैं (संभवत: SSLHonlineCipherOrder के साथ संयोजन के रूप में), या आप 1024 बिट के साथ कस्टम डीएच मापदंडों का उपयोग कर सकते हैं , जो हमेशा निर्मित डीएच मापदंडों में से किसी पर भी पूर्ववर्ती होगा।

कस्टम डीएच पैरामीटर बनाने के लिए, का उपयोग करें

खुलता है dhparam 1024

आदेश। वैकल्पिक रूप से, आप RFC 2409, खंड 6.2 से निम्न मानक 1024-बिट डीएच मापदंडों का उपयोग कर सकते हैं:

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

"BEGIN DH PARAMETERS" और "END DH PARAMETERS" लाइनों सहित कस्टम मापदंडों को उस पहली सर्टिफिकेट फ़ाइल के अंत में जोड़ें, जिसे आपने SSLCertificateFile निर्देश का उपयोग करके कॉन्फ़िगर किया है।

मैं क्लाइंट साइड पर जावा 1.6 का उपयोग कर रहा हूं, और इसने मेरी समस्या हल कर दी। मैंने सिफर स्वीट या पसंद को कम नहीं किया, लेकिन प्रमाणित फ़ाइल में एक कस्टम जेनरेट किया गया डीएच परम जोड़ा।

— PKA
स्रोत
विदित हो कि अब यह माना जाता है कि 1024 बिट डीएच को कम्प्यूटेशनल रूप से व्यवहार्य (हालांकि नारकीय महंगा) तोड़ना है।
— प्लगवॉश करें
2

Yandex Maps सर्वर, JDK 1.6 और Apache HttpClient 4.2.1 के साथ मुझे यही समस्या है। त्रुटि थी

javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated

-Djavax.net.debug=all लॉग में एक सक्षम डीबग के साथ एक संदेश था

Could not generate DH keypair

मैंने BouncyCastle लाइब्रेरी को जोड़कर bcprov-jdk16-1.46.jarऔर मैप सर्विस क्लास में एक प्रदाता को पंजीकृत करके इस समस्या को ठीक किया है

public class MapService {

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

    public GeocodeResult geocode() {

    }

}

एक प्रदाता के पहले उपयोग पर पंजीकृत है MapService।

— v.ladynev
स्रोत
2

मुझे JDK 6 चलाने वाले एक CentOS सर्वर पर SSL त्रुटि का सामना करना पड़ा।

मेरी योजना JDK 6 के साथ सह-अस्तित्व के लिए एक उच्च JDK संस्करण (JDK 7) स्थापित करने की थी, लेकिन यह पता चला है कि केवल नए JDK को स्थापित करना rpm -iपर्याप्त नहीं था।

JDK 7 इंस्टॉलेशन केवल rpm -Uनीचे दिए गए उदाहरण के रूप में अपग्रेड विकल्प के साथ सफल होगा ।

1. JDK 7 डाउनलोड करें

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 इंस्टॉलेशन विफल

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 अपग्रेड सफल होता है

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. नए संस्करण की पुष्टि करें

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)
— शहीद
स्रोत
1

JDK 8 में अपग्रेड करके समस्या का समाधान किया।

— anre
स्रोत
1

मैं JDK 1.6.45 पर कोल्डफ्यूजन 8 का उपयोग करता हूं और मुझे छवियों के बजाय सिर्फ लाल क्रॉस देने में समस्या थी, और cfhttp के साथ भी स्थानीय वेबसर्वर को ssl से कनेक्ट करने में सक्षम नहीं था।

कोल्डफ्यूजन 8 के साथ पुन: पेश करने के लिए मेरी टेस्ट स्क्रिप्ट थी

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

इससे मुझे "I / O अपवाद: सहकर्मी प्रमाणित नहीं हुआ" की काफी सामान्य त्रुटि मिली। फिर मैंने सर्वर के प्रमाण पत्र को रूट और इंटरमीडिएट प्रमाणपत्रों में जावा कीस्टोर और कोल्डफ्यूजन कीस्टोर सहित जोड़ने का प्रयास किया, लेकिन कुछ भी मदद नहीं की। तब मैंने इस समस्या पर बहस की

java SSLPoke www.onlineumfragen.com 443

और मिला

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

तथा

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

मुझे तब यह विचार आया कि वेबसर्वर (मेरे मामले में अपाचे) के पास ssl के लिए बहुत आधुनिक साइफर थे और यह काफी प्रतिबंधक (क्वालिस स्कोर ए +) है और 1024 से अधिक बिट्स के साथ मजबूत डिफरेंट हेलमैन कीज़ का उपयोग करता है। जाहिर है, कोल्डफ्यूजन और जावा jdk 1.6.45 इसका प्रबंधन नहीं कर सकते। ओडिसी में अगला कदम जावा के लिए एक वैकल्पिक सुरक्षा प्रदाता स्थापित करने के बारे में सोचना था, और मैंने उछाल वाले महल के लिए फैसला किया। http://www.itcsolutions.eu/2011/08/22/how-to-use-bouncy-castle-cryptographic-ap-in-netbeans-or-eclipse-for-java-jse-projects/ भी देखें

मैंने फिर डाउनलोड किया 

bcprov-ext-jdk15on-156.jar

http ://www.b Councilycastle.org/latest_releases.html से और इसे C: \ jdk6_45 \ jre \ lib \ ext या जहाँ कभी आपका jdk है, के तहत स्थापित किया गया है, कोल्डफ़्यूज़न 8 के मूल संस्थापन में यह C: \ JRun4 \ के तहत होगा jre \ lib \ ext लेकिन मैं कोल्डफ्यूजन डायरेक्टरी के बाहर स्थित एक नए jdk (1.6.45) का उपयोग करता हूं। bcprov-ext-jdk15on-156.jar को \ ext निर्देशिका में रखना बहुत महत्वपूर्ण है (इससे मुझे लगभग दो घंटे और कुछ बाल खर्च होंगे;; फिर मैंने फ़ाइल C: \ jdk6_45 \ ji \ lib \ Security \ java.security (वर्डपैड के साथ editor.exe नहीं!) और नए प्रदाता के लिए एक पंक्ति में रखें। बाद में सूची की तरह लग रहा था

#
# 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

(स्थिति 1 में नया देखें)

फिर कोल्डफ़्यूज़न सेवा को पूरी तरह से फिर से शुरू करें। आप तब कर सकते हैं

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

और भावना का आनंद लें ... और निश्चित रूप से

क्या रात और क्या दिन। उम्मीद है कि यह (आंशिक या पूर्ण रूप से) किसी को वहाँ से बाहर निकालने में मदद करेगा। यदि आपके कोई प्रश्न हैं, तो मुझे जानकारी पर मेल करें ... (ऊपर डोमेन)।

— रफेल मीयर
स्रोत
0

यदि सर्वर एक सिफर का समर्थन करता है जिसमें डीएच शामिल नहीं है, तो आप क्लाइंट को उस सिफर का चयन करने और डीएच त्रुटि से बचने के लिए मजबूर कर सकते हैं। जैसे कि:

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

ध्यान रखें कि एक सटीक सिफर निर्दिष्ट करने से लंबे समय में टूटने का खतरा होता है।

— जेसन मार्टिन
स्रोत
0

हमें वही सटीक अपवाद त्रुटि मिली, जिसे ठीक करने के लिए इंटरनेट सर्फिंग के घंटों के बाद यह आसान था।

हमने jdk का उच्चतम संस्करण डाउनलोड किया जिसे हम oracle.com पर पा सकते हैं, इसे स्थापित किया और स्थापित नए jdk की निर्देशिका में Jboss एप्लिकेशन सर्वर को इंगित किया।

फिर से शुरू किया Jboss, पुनर्संसाधन, समस्या तय हो गई !!!

— पीटर अज़ुका मोलोकु
स्रोत
0

मुझे यह त्रुटि बम्बू 5.7 + ग्रैडल प्रोजेक्ट + अपाचे के साथ मिली है। ग्रेड ने एसएसएल के माध्यम से हमारे एक सर्वर से कुछ निर्भरता प्राप्त करने की कोशिश की।

उपाय:

  1. डीएच परम को उत्पन्न करें:

OpenSSL के साथ:

openssl dhparam 1024

उदाहरण आउटपुट:

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

  1. सर्टिफिकेट फ़ाइल के लिए आउटपुट में अपाचे ( SSLCertificateFileपरम के लिए)

  2. फिर से शुरू करें

  3. बाँस को फिर से शुरू करें

  4. फिर से प्रोजेक्ट बनाने की कोशिश करें

— एवगेनी लेबेदेव
स्रोत
0

मैं एक समान त्रुटि प्राप्त करने के लिए svn.apache.org को जावा SVN क्लाइंट के साथ IBM JDK का उपयोग करके प्राप्त करता था। वर्तमान में, svn.apache.org उपयोगकर्ता ग्राहकों की वरीयताओं को समझते हैं।

पैकेट कैप्चर / javax.net.debug = के साथ सिर्फ एक बार चलाने के बाद = सभी मैं केवल एक डीएचईई सिफर और मेरे लिए काम करने में सक्षम होने के लिए सक्षम था (ECDHE के बजाय बातचीत की जाती है)।

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

क्लाइंट को बदलना आसान नहीं होने पर एक अच्छा क्विक फिक्स।

— covener
स्रोत
0

हाल ही में मेरे पास एक ही मुद्दा है और 1.6.0_45 से jdk1.7.0_191 तक jdk संस्करण को अपग्रेड करने के बाद जिसने इस मुद्दे को हल किया।

— सैम
स्रोत
-1

मेरे लिए, निम्न कमांड लाइन ने समस्या को ठीक किया:

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

मैं JDK 1.7.0_79 का उपयोग कर रहा हूं

— रीको-चेंगो
स्रोत
1
मुझे JDK 1.7.0_xx का उपयोग करके समान स्थिति का सामना करना पड़ा। डिफ़ॉल्ट रूप से समस्या jdk 1.8 का उपयोग करने के बाद हल हो जाएगी। लेकिन कभी-कभी हम jdk को जल्दी से अपग्रेड नहीं कर सकते हैं। इसलिए सिस्टम कॉन्फ़िगरेशन जोड़ने के बाद मेरा मुद्दा हल हो गया: System.setProperty ("https.protocols", "TLSv1.2.2); System.setProperty ("परिनियोजन। सुरक्षा .LSv1.2", "सत्य");
— रामगौ
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.