SSL हैंडशेक अलर्ट: unrecognized_name त्रुटि जावा 1.7.0 में अपग्रेड करने के बाद से

225

मैंने आज जावा 1.6 से जावा 1.7 में अपग्रेड किया। तब से एक त्रुटि तब होती है जब मैं SSL पर अपने वेबसर्वर से संबंध स्थापित करने का प्रयास करता हूं:

javax.net.ssl.SSLProtocolException: handshake alert:  unrecognized_name
    at sun.security.ssl.ClientHandshaker.handshakeAlert(ClientHandshaker.java:1288)
    at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1904)
    at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1027)
    at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1262)
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1289)
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1273)
    at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:523)
    at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1296)
    at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:254)
    at java.net.URL.openStream(URL.java:1035)

यहाँ कोड है:

SAXBuilder builder = new SAXBuilder();
Document document = null;

try {
    url = new URL(https://some url);
    document = (Document) builder.build(url.openStream());
} catch (NoSuchAlgorithmException ex) {
    Logger.getLogger(DownloadLoadiciousComputer.class.getName()).log(Level.SEVERE, null, ex);  
}

इसका केवल एक परीक्षण प्रोजेक्ट है कि मैं कोड के साथ अविश्वसनीय प्रमाणपत्रों की अनुमति क्यों देता हूं और उपयोग करता हूं:

TrustManager[] trustAllCerts = new TrustManager[]{
    new X509TrustManager() {

        public java.security.cert.X509Certificate[] getAcceptedIssuers() {
            return null;
        }

        public void checkClientTrusted(
                java.security.cert.X509Certificate[] certs, String authType) {
        }

        public void checkServerTrusted(
                java.security.cert.X509Certificate[] certs, String authType) {
        }
    }
};

try {

    SSLContext sc = SSLContext.getInstance("SSL");
    sc.init(null, trustAllCerts, new java.security.SecureRandom());
    HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
} catch (Exception e) {

    Logger.getLogger(DownloadManager.class.getName()).log(Level.SEVERE, null, e);
}

मैंने पूरी तरह से https://google.com से जुड़ने की कोशिश की । मेरी गलती कहाँ है

धन्यवाद।

java ssl

— pvomhoff
स्रोत

304

जावा 7 ने एसएनआई समर्थन पेश किया जो डिफ़ॉल्ट रूप से सक्षम है। मुझे पता चला है कि कुछ गलत कॉन्फ़िगर किए गए सर्वर SSL हैंडशेक में एक "अपरिचित नाम" चेतावनी भेजते हैं, जिसे जावा को छोड़कर अधिकांश ग्राहकों द्वारा अनदेखा किया जाता है। जैसा कि @ जरबर्न कर्नस ने उल्लेख किया है, ओरेकल इंजीनियर इस बग / सुविधा को "ठीक" करने से इनकार करते हैं।

वर्कअराउंड के रूप में, वे jsse.enableSNIExtensionसंपत्ति सेट करने का सुझाव देते हैं। अपने कार्यक्रमों को फिर से संकलित किए बिना काम करने की अनुमति देने के लिए, अपना ऐप निम्नानुसार चलाएं:

java -Djsse.enableSNIExtension=false yourClass

संपत्ति को जावा कोड में भी सेट किया जा सकता है, लेकिन इसे किसी भी एसएसएल कार्यों से पहले सेट किया जाना चाहिए । एक बार एसएसएल लाइब्रेरी लोड हो जाने के बाद, आप संपत्ति को बदल सकते हैं, लेकिन एसएनआई स्थिति पर इसका कोई प्रभाव नहीं पड़ेगा । SNI को रनटाइम पर (उपर्युक्त सीमाओं के साथ) अक्षम करने के लिए, उपयोग करें:

System.setProperty("jsse.enableSNIExtension", "false");

इस ध्वज को स्थापित करने का नुकसान यह है कि एसएनआई आवेदन में हर जगह अक्षम है। एसएनआई का उपयोग करने के लिए और अभी भी गलत सर्वर का समर्थन करने के लिए:

SSLSocketउस होस्ट नाम से बनाएं जिसे आप कनेक्ट करना चाहते हैं। इसका नाम बताते हैं sslsock।
चलाने की कोशिश करें sslsock.startHandshake()। यह तब तक ब्लॉक रहेगा जब तक यह किया जाता है या त्रुटि पर अपवाद नहीं फेंकता है। जब भी कोई त्रुटि हुई startHandshake(), अपवाद संदेश प्राप्त करें। यदि यह बराबर है handshake alert: unrecognized_name, तो आपको एक गलत सर्वर मिला है।
जब आपको unrecognized_nameचेतावनी (जावा में घातक) मिली हो, तो खोलने का प्रयास करें SSLSocket, लेकिन इस बार बिना होस्ट नाम के। यह प्रभावी रूप से एसएनआई को निष्क्रिय करता है (आखिरकार, एसएनआई एक्सटेंशन क्लाइंटहेलो संदेश में होस्ट नाम जोड़ने के बारे में है)।

वेबस्पैब एसएसएल प्रॉक्सी के लिए, यह कमिट फ़ॉल-बैक सेटअप लागू करता है।

— Lekensteyn
स्रोत

5

यह काम करता है, धन्यवाद! IntelliJ IDEA सबवर्सन क्लाइंट को HTTPS के माध्यम से कनेक्ट करते समय एक ही त्रुटि थी। बस लाइन के साथ idea.exe.vmoptions फ़ाइल अपडेट करने की आवश्यकता है: -Dss.enableSNIExtension = false

— Dima

2

जावा वेबस्टार्ट के लिए इसका उपयोग करें: javaws -J-Djsse.enableSNIExtension = false yourClass

— Torsten

मैं अपने जर्सी क्लाइंट के साथ https बाकी सर्वर के साथ सटीक एक ही मुद्दा था। पता चला मैंने तुम्हारी चाल का इस्तेमाल किया और यह काम किया !! धन्यवाद!

— शशि 15

4

जावा 8 के बारे में सोच रहे लोगों के लिए, ओरेकल ने अभी भी व्यवहार को नहीं बदला है और अभी भी प्रोग्रामर को सर्वर को पकड़ने की आवश्यकता होती है जो (ठीक से) एसएनआई का

— लेकेनस्टीन

2

@Blauhirn अपने webhost समर्थन से संपर्क करें, उन्हें अपना कॉन्फ़िगरेशन ठीक करना चाहिए। यदि वे अपाचे का उपयोग करते हैं, तो कुछ बदलावों के लिए नीचे देखें जिन्हें बनाने की आवश्यकता है।

— लेकेनस्टाइन

89

मेरा मानना था कि मैं वही मुद्दा हूं। मैंने पाया कि मुझे अपाचे कॉन्फ़िगरेशन को होस्ट के लिए ServerName या ServerAlias शामिल करने की आवश्यकता है।

यह कोड विफल हुआ:

public class a {
   public static void main(String [] a) throws Exception {
      java.net.URLConnection c = new java.net.URL("https://mydomain.com/").openConnection();
      c.setDoOutput(true);
      c.getOutputStream();
   }
}

और इस कोड ने काम किया:

public class a {
   public static void main(String [] a) throws Exception {
      java.net.URLConnection c = new java.net.URL("https://google.com/").openConnection();
      c.setDoOutput(true);
      c.getOutputStream();
   }
}

Wireshark ने खुलासा किया कि TSL / SSL के दौरान चेतावनी चेतावनी (स्तर: चेतावनी, विवरण: अपरिचित नाम), सर्वर हैलो क्लाइंट से सर्वर पर भेजा जा रहा था। यह केवल एक चेतावनी थी, हालांकि, जावा 7.1 ने फिर "घातक, विवरण: अनपेक्षित संदेश" के साथ तुरंत जवाब दिया, जो मुझे लगता है कि जावा SSL पुस्तकालयों को अपरिचित नाम की चेतावनी को देखना पसंद नहीं है।

विकी ऑन ट्रांसपोर्ट लेयर सिक्योरिटी (TLS) से:

112 गैर मान्यता प्राप्त नाम चेतावनी टीएलएस केवल; क्लाइंट का सर्वर नाम संकेतक एक होस्टनाम निर्दिष्ट करता है जो सर्वर द्वारा समर्थित नहीं है

इसने मुझे अपनी अपाचे कॉन्फिग फाइलों को देखने के लिए प्रेरित किया और मैंने पाया कि अगर मैंने क्लाइंट / जावा साइड से भेजे गए नाम के लिए एक सर्वरनेम या सर्वरअलीअस जोड़ा है, तो यह बिना किसी त्रुटि के सही ढंग से काम करता है।

<VirtualHost mydomain.com:443>
  ServerName mydomain.com
  ServerAlias www.mydomain.com

— डेविड मैकलॉघलिन
स्रोत

3

यह जावा के टीएलएस कार्यान्वयन में एक बग जैसा दिखता है।

— पाओलो एबरमन

1

मैं वास्तव में इसके लिए एक बग खोलता हूं। मुझे यह नंबर सौंपा गया है (अभी तक दिखाई नहीं दिया गया है): Bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127374

— eckes

1

धन्यवाद, ServerAliasमेरे लिए एक काम जोड़ रहा है । मैंने वही टीएलएस सतर्कता में देखा था।

— जेरेड बेक बेक

2

यह मेरे लिए भी काम किया। (बेहतर काम किया होगा अगर मुझे लगता है कि यह विश्वास है और एक और रास्ता नीचे शिकार नहीं गया है)

— अंत उपयोगकर्ता

10

@ जोसेफशरीबमैन, ओरेकल कर्मचारी को एक बेवकूफ कहना अनुचित है। जब आप दो ServerNameएस का उपयोग करते हैं , तो अपाचे एक unrecognized_name चेतावनी चेतावनी के साथ प्रतिक्रिया करता है (जो एक घातक चेतावनी भी हो सकती है )। RFC 6066 इस विषय पर ठीक यही कहता है: " चेतावनी-स्तर के गैर-मान्यताप्राप्त_नाम (112) अलर्ट भेजने के लिए यह अनुशंसित नहीं है, क्योंकि चेतावनी-स्तर के अलर्ट के जवाब में ग्राहक का व्यवहार अप्रत्याशित है। " इस कर्मचारी द्वारा की गई एकमात्र गलती यह मान लेना है कि यह एक घातक चेतावनी थी। यह एक JRE बग जितना ही एक अपाचे है।

— ब्रूनो

36

आप सिस्टम गुण jsse.enableSNIExtension = false के साथ SNI रिकॉर्ड भेजने को अक्षम कर सकते हैं।

यदि आप उस कोड को बदल सकते हैं जिसका उपयोग करने में मदद करता है SSLCocketFactory#createSocket()(बिना होस्ट पैरामीटर या जुड़े सॉकेट के)। इस स्थिति में यह एक server_name संकेत नहीं भेजेगा।

— प्रतिध्वनि
स्रोत

11

जो इस प्रकार किया जाता है:System.setProperty ("jsse.enableSNIExtension", "false");

— jn1kk

मैंने पाया है कि हमेशा काम नहीं करता है। मुझे नहीं पता कि यह कुछ मामलों में क्यों काम करता है और दूसरों को नहीं।

— जोसेफ श्राइबमैन

2

मेरे साथ काम करता है -Djsse.enableSNIExtension=false। लेकिन यह और क्या करता है? क्या यह जवास की बाकी सुरक्षा के लिए हानिकारक है?

— ceving

2

इसका मतलब यह नहीं है कि कुछ साइटों (विशेष रूप से वेब सर्वर) जो साझा आईपी के पीछे म्यूटेंट होस्टनाम का उपयोग करते हैं, उन्हें पता नहीं है कि क्या प्रमाण पत्र भेजना है। लेकिन जब तक आपके जावा ऐप को लाखों वेब साइटों से कनेक्ट नहीं करना पड़ता है, तब तक आपको उस सुविधा की आवश्यकता नहीं होगी। यदि आप ऐसे सर्वर से सामना करते हैं तो आपका प्रमाणपत्र सत्यापन विफल हो सकता है और कनेक्शन निरस्त हो सकता है। इसलिए सुरक्षा की कोई समस्या नहीं है।

— eckes

17

हम एक नए अपाचे सर्वर बिल्ड पर इस त्रुटि में भी भाग गए।

हमारे मामले में ठीक एक परिभाषित करने के लिए था ServerAliasमें httpd.confहै कि होस्ट नाम है कि जावा से कनेक्ट करने के लिए कोशिश कर रहा था पत्राचार किया। हमारा ServerNameआंतरिक होस्ट नाम सेट था। हमारा SSL प्रमाणपत्र बाहरी होस्ट नाम का उपयोग कर रहा था, लेकिन यह चेतावनी से बचने के लिए पर्याप्त नहीं था।

डिबग की सहायता के लिए, आप इस ssl कमांड का उपयोग कर सकते हैं:

openssl s_client -servername <hostname> -connect <hostname>:443 -state

यदि उस होस्टनाम के साथ कोई समस्या है, तो यह इस संदेश को आउटपुट के शीर्ष के पास प्रिंट करेगा:

SSL3 alert read: warning:unrecognized name

मुझे यह भी ध्यान देना चाहिए कि आंतरिक होस्ट नाम से कनेक्ट करने के लिए उस कमांड का उपयोग करते समय हमें वह त्रुटि नहीं मिली, हालांकि यह एसएसएल प्रमाणपत्र से मेल नहीं खाता था।

— स्कॉट मैकइंटायर
स्रोत

6

उदाहरण का उपयोग करने के लिए धन्यवाद कैसे समस्या का पुन: उपयोग करें openssl। यह बहुत मददगार है।

— साइडशोबर्कर

2

क्या नाम खुलने वाले संदेश को देखने के लिए एक ओपनस् क्लाइंट के लिए एक तरीका है जो संदेश को उत्पन्न करता है SSL3 alert read: warning:unrecognized name? मैं अलर्ट को मुद्रित देखता हूं, लेकिन आउटपुट मुझे वास्तव में इस नामकरण अंतर को देखने में मदद नहीं करता है

— mox601

यह मेरे लिए काम नहीं करता है। के साथ परीक्षण किया OpenSSL 1.0.1e-fips 11 Feb 2013, OpenSSL 1.0.2k-fips 26 Jan 2017और LibreSSL 2.6.5।

— ग्रेग डबकी

15

अपाचे में डिफ़ॉल्ट वर्चुअल होस्ट तंत्र पर भरोसा करने के बजाय, आप एक अंतिम कैटचॉल वर्चुअलहोस्ट को परिभाषित कर सकते हैं जो एक मनमाना ServerName और एक वाइल्डकार्ड ServerAlias का उपयोग करता है, जैसे।

ServerName catchall.mydomain.com
ServerAlias *.mydomain.com

इस तरह आप एसएनआई का उपयोग कर सकते हैं और अपाचे एसएसएल चेतावनी को वापस नहीं भेजेगा।

बेशक, यह केवल तभी काम करता है जब आप वाइल्डकार्ड सिंटैक्स का उपयोग करके अपने सभी डोमेन का आसानी से वर्णन कर सकते हैं।

— एरिक
स्रोत

जहाँ तक मैं समझता हूँ, अपाचे केवल इस चेतावनी को भेजता है यदि क्लाइंट किसी सर्वरनाम या ServerAlias के रूप में कॉन्फ़िगर नहीं किए गए नाम का उपयोग करता है। इसलिए यदि आपके पास एक वाइल्ड कार्ड प्रमाण पत्र है, तो या तो सभी उपयोग किए गए उप डोमेन निर्दिष्ट करें, या *.mydomain.comसर्वरएलाइज़ के लिए सिंटैक्स का उपयोग करें । ध्यान दें कि आप कई उपनामों का उपयोग करके जोड़ सकते हैं ServerAlias, जैसे ServerAlias *.mydomain.com mydomain.com *.myotherdomain.com।

— बजे माइकल पेसोल्ड

13

यह उपयोगी होना चाहिए। Apache HttpClient 4.4 में एक SNI त्रुटि पर पुन: प्रयास करने के लिए - सबसे आसान तरीका जो हम साथ आए थे (देखें HTTPCLIENT-1522 ):

public class SniHttpClientConnectionOperator extends DefaultHttpClientConnectionOperator {

    public SniHttpClientConnectionOperator(Lookup<ConnectionSocketFactory> socketFactoryRegistry) {
        super(socketFactoryRegistry, null, null);
    }

    @Override
    public void connect(
            final ManagedHttpClientConnection conn,
            final HttpHost host,
            final InetSocketAddress localAddress,
            final int connectTimeout,
            final SocketConfig socketConfig,
            final HttpContext context) throws IOException {
        try {
            super.connect(conn, host, localAddress, connectTimeout, socketConfig, context);
        } catch (SSLProtocolException e) {
            Boolean enableSniValue = (Boolean) context.getAttribute(SniSSLSocketFactory.ENABLE_SNI);
            boolean enableSni = enableSniValue == null || enableSniValue;
            if (enableSni && e.getMessage() != null && e.getMessage().equals("handshake alert:  unrecognized_name")) {
                TimesLoggers.httpworker.warn("Server received saw wrong SNI host, retrying without SNI");
                context.setAttribute(SniSSLSocketFactory.ENABLE_SNI, false);
                super.connect(conn, host, localAddress, connectTimeout, socketConfig, context);
            } else {
                throw e;
            }
        }
    }
}

तथा

public class SniSSLSocketFactory extends SSLConnectionSocketFactory {

    public static final String ENABLE_SNI = "__enable_sni__";

    /*
     * Implement any constructor you need for your particular application -
     * SSLConnectionSocketFactory has many variants
     */
    public SniSSLSocketFactory(final SSLContext sslContext, final HostnameVerifier verifier) {
        super(sslContext, verifier);
    }

    @Override
    public Socket createLayeredSocket(
            final Socket socket,
            final String target,
            final int port,
            final HttpContext context) throws IOException {
        Boolean enableSniValue = (Boolean) context.getAttribute(ENABLE_SNI);
        boolean enableSni = enableSniValue == null || enableSniValue;
        return super.createLayeredSocket(socket, enableSni ? target : "", port, context);
    }
}

तथा

cm = new PoolingHttpClientConnectionManager(new SniHttpClientConnectionOperator(socketFactoryRegistry), null, -1, TimeUnit.MILLISECONDS);

— Shcheklein
स्रोत

यदि आप इसे इस तरह से करते हैं। आप से कैसे निपटते हैं verifyHostname(sslsock, target)में SSLConnectionSocketFactory.createLayeredSocket? चूंकि targetरिक्त स्ट्रिंग में बदल गया है, verifyHostnameइसलिए सफल नहीं हो रहा है। क्या में यहां कुछ भूल रहा हूँ?

— हाओहजुन

2

यह वास्तव में, मैं क्या देख रहा था, बहुत बहुत धन्यवाद! मुझे SNI और सर्वर का समर्थन करने का कोई अन्य तरीका नहीं मिला, जो एक ही समय में इस "अपरिचित_नाम" चेतावनी के साथ प्रतिक्रिया करता है।

— कोरिया जूल

यह समाधान तब तक काम करता है, जब तक आप प्रॉक्सी सर्वर का उपयोग नहीं कर रहे हैं।

— मेंग

बस एक त्वरित डिबग करने के बाद Apache क्लाइंट कोड को, VerHostname () से शुरू करते हुए, मैं यह नहीं देख सकता कि यह DefaultHostnameVerifier का उपयोग करके कैसे काम कर सकता है। मुझे संदेह है कि इस समाधान के लिए होस्टनाम सत्यापन को निष्क्रिय करने की आवश्यकता है (उदाहरण के लिए एक नोओफ़ोस्टेम वीयरिफायर का उपयोग करना), जो कि एक अच्छा विचार नहीं है क्योंकि यह मानव-में-मध्य हमलों की अनुमति देता है।

— फ्लाइंगशीप

11

उपयोग:

System.setProperty ("jsse.enableSNIExtension", "false");
अपने टॉमकैट को पुनः आरंभ करें (महत्वपूर्ण)

— टॉमस जनिस्विसिज़
स्रोत

6

वसंत बूट और jvm 1.7 और 1.8 के साथ इस मुद्दे में भाग गया । AWS पर, हमारे पास ServerName और ServerAlias को मिलान करने के लिए बदलने का विकल्प नहीं था (वे भिन्न हैं) इसलिए हमने निम्नलिखित कार्य किए:

में build.gradle हम निम्नलिखित कहा:

System.setProperty("jsse.enableSNIExtension", "false")
bootRun.systemProperties = System.properties

इसने हमें "अपरिचित नाम" के साथ समस्या को बायपास करने की अनुमति दी।

— रे हंटर
स्रोत

5

आप दुर्भाग्यवश, jarsigner.exe उपकरण को सिस्टम गुण प्रदान नहीं कर सकते।

मैं दोष प्रस्तुत की है 7177232 , @eckes 'दोष संदर्भित 7127374 और समझा क्यों यह त्रुटि में बंद हो गया।

मेरा दोष विशेष रूप से जारसिग्नेर टूल पर प्रभाव के बारे में है, लेकिन शायद यह उन्हें अन्य दोष को फिर से खोलने और समस्या को ठीक से संबोधित करने के लिए प्रेरित करेगा।

अद्यतन: वास्तव में, यह पता चला है कि आप सिस्टम गुणों को जारसिग्नेर उपकरण को आपूर्ति कर सकते हैं, यह सिर्फ मदद संदेश में नहीं है। उपयोगjarsigner -J-Djsse.enableSNIExtension=false

— बॉब केर्न्स
स्रोत

1

फॉलोअप के लिए धन्यवाद बॉब। अफसोस की बात है कि ओरेकल अभी भी पूरी बात नहीं समझ रहा है। एसएनआई अलर्ट घातक नहीं है, यह घातक हो सकता है। लेकिन अधिकांश विशिष्ट एसएसएल क्लाइंट (यानी ब्राउज़र) ने इसे अनदेखा करने का विकल्प चुना क्योंकि यह वास्तविक सुरक्षा समस्या नहीं है (क्योंकि आपको अभी भी सर्वर प्रमाणपत्र की जांच करनी होगी और गलत समापन बिंदुओं का पता लगाना होगा)। बेशक यह दुखद है कि सीए सेट करने में असमर्थ है। ठीक से कॉन्फ़िगर किया गया https सर्वर।

— eckes

2

वास्तव में, यह पता चला है कि आप जारसिग्नर टूल को सिस्टम गुण प्रदान कर सकते हैं, यह मदद संदेश में नहीं है। यह प्रलेखन में शामिल है। मुझे ऑनलाइन पाठ पर विश्वास करने के लिए मूर्खतापूर्ण। बेशक, उन्होंने इसे ठीक न करने के लिए एक बहाने के रूप में इस्तेमाल किया।

— बॉब कर्नेन्स

BTW: मैं वर्तमान में इस मुद्दे पर Security-dev @ openjdk पर चर्चा कर रहा हूं और फिलहाल मैं इसका मूल्यांकन कर रहा था कि ऐसा लग रहा है कि Symantec ने GEOTrust टाइमस्टैम्पिंग सर्वर को ठीक कर दिया है, अब यह URL को बिना किसी चेतावनी के सही रूप से स्वीकार करता है। लेकिन मुझे अभी भी लगता है कि इसे ठीक किया जाना चाहिए। यदि आप एक नज़र रखना चाहते हैं, तो एक परीक्षण ग्राहक परियोजना और चर्चा :

— '

3

मैंने उसी समस्या को मारा और यह पता चला कि रिवर्स डीएनएस सेटअप सही नहीं था, इसने आईपी के लिए गलत होस्टनाम की ओर इशारा किया। जब मैं रिवर्स डीएनएस को सही करता हूं और httpd को पुनरारंभ करता हूं, तो चेतावनी समाप्त हो जाती है। (यदि मैं रिवर्स डीएनएस को सही नहीं करता हूं, तो ServerName को जोड़ने से मेरे लिए भी चाल चली गई)

— user2888387
स्रोत

2

मेरे VirtualHostकी ServerNameडिफ़ॉल्ट रूप से बाहर टिप्पणी की गयी है। यह असुविधाजनक होने के बाद काम करता है।

— अराम परोनिकन
स्रोत

मुझे भी। सर्वर का नाम गायब था।

— डार्क स्टार 1

2

यदि आप Resttemplate के साथ ग्राहक बना रहे हैं, तो आप केवल इस तरह समापन बिंदु सेट कर सकते हैं: https: // IP / path_to_service और अनुरोध को सेट करें।
इस समाधान के साथ आपको अपने TOMCAT या Apache को पुनर्व्यवस्थित करने की आवश्यकता नहीं है:

public static HttpComponentsClientHttpRequestFactory requestFactory(CloseableHttpClient httpClient) {
    TrustStrategy acceptingTrustStrategy = new TrustStrategy() {
        @Override
        public boolean isTrusted(X509Certificate[] chain, String authType) throws CertificateException {
            return true;
        }
    };

    SSLContext sslContext = null;
    try {
        sslContext = org.apache.http.ssl.SSLContexts.custom()
                .loadTrustMaterial(null, acceptingTrustStrategy)
                .build();
    } catch (Exception e) {
        logger.error(e.getMessage(), e);
    }   

    HostnameVerifier hostnameVerifier = new HostnameVerifier() {
        @Override
        public boolean verify(String hostname, SSLSession session) {
            return true;
        }
    };

    final SSLConnectionSocketFactory csf = new SSLConnectionSocketFactory(sslContext,hostnameVerifier);

    final Registry<ConnectionSocketFactory> registry = RegistryBuilder.<ConnectionSocketFactory>create()
            .register("http", new PlainConnectionSocketFactory())
            .register("https", csf)
            .build();

    final PoolingHttpClientConnectionManager cm = new PoolingHttpClientConnectionManager(registry);
    cm.setMaxTotal(100);
    httpClient = HttpClients.custom()
            .setSSLSocketFactory(csf)
            .setConnectionManager(cm)
            .build();

    HttpComponentsClientHttpRequestFactory requestFactory =
            new HttpComponentsClientHttpRequestFactory();

    requestFactory.setHttpClient(httpClient);

    return requestFactory;
}

— अल्फ्रेडो
स्रोत

1

जावा 1.6_29 से 1.7 तक अपग्रेड करते हुए मैं भी इस मुद्दे पर आया हूं।

सतर्कता से, मेरे ग्राहक ने जावा नियंत्रण कक्ष में एक सेटिंग की खोज की है जो इसे हल करता है।

उन्नत टैब में आप 'एसएसएल 2.0 संगत क्लाइंटहेलो प्रारूप का उपयोग करें' की जांच कर सकते हैं।

इस मुद्दे को हल करने के लिए लगता है।

हम इंटरनेट एक्सप्लोरर ब्राउज़र में जावा एप्लेट का उपयोग कर रहे हैं।

उम्मीद है की यह मदद करेगा।

— एलन डी
स्रोत

0

मुझे एक ही समस्या उबंटू लिनक्स सर्वर से चल रही थी जब एक्लिप्स के माध्यम से पहुँचा।

यह दिखाया गया है कि अपाचे (पुनः) शुरू होने पर समस्या को चेतावनी के साथ करना था:

[Mon Jun 30 22:27:10 2014] [warn] NameVirtualHost *:80 has no VirtualHosts

... waiting [Mon Jun 30 22:27:11 2014] [warn] NameVirtualHost *:80 has no VirtualHosts

यह एक नई प्रविष्टि के कारण हुआ है ports.conf, जहां NameVirtualHostनिर्देश के साथ एक और निर्देश दर्ज किया गया था sites-enabled/000-default।

निर्देश को हटाने के बाद ports.conf, समस्या गायब हो गई थी (अपाचे को फिर से शुरू करने के बाद, स्वाभाविक रूप से)

— गेरहार्ड
स्रोत

0

बस यहाँ एक समाधान जोड़ने के लिए। यह LAMP उपयोगकर्ताओं के लिए मदद कर सकता है

Options +FollowSymLinks -SymLinksIfOwnerMatch

वर्चुअल होस्ट कॉन्फ़िगरेशन में उपर्युक्त पंक्ति अपराधी थी।

वर्चुअल होस्ट कॉन्फ़िगरेशन जब त्रुटि

<VirtualHost *:80>
    DocumentRoot /var/www/html/load/web
    ServerName dev.load.com
    <Directory "/var/www/html/load/web">
        Options +FollowSymLinks -SymLinksIfOwnerMatch
        AllowOverride All
        Require all granted
        Order Allow,Deny
        Allow from All
    </Directory>
     RewriteEngine on
     RewriteCond %{SERVER_PORT} !^443$
     RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R=301,L]
</VirtualHost>

कार्य विन्यास

<VirtualHost *:80>
    DocumentRoot /var/www/html/load/web

   ServerName dev.load.com
   <Directory "/var/www/html/load/web">

        AllowOverride All

        Options All

        Order Allow,Deny

        Allow from All

    </Directory>

    # To allow authorization header
    RewriteEngine On
    RewriteCond %{HTTP:Authorization} ^(.*)
    RewriteRule .* - [e=HTTP_AUTHORIZATION:%1]

   # RewriteCond %{SERVER_PORT} !^443$
   # RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R=301,L]


</VirtualHost>

— दौड़ के लिये कभी भी न उतारा गया घोड़ा
स्रोत

0

यहाँ Appache httpclient 4.5.11 के लिए समाधान है। मुझे सर्टिफिकेट की समस्या थी जो वाइल्डकार्ड के अधीन है *.hostname.com। इसने मुझे वही अपवाद लौटाया, लेकिन मैंने संपत्ति से अक्षम होने का उपयोग नहीं किया System.setProperty("jsse.enableSNIExtension", "false");क्योंकि उसने Google स्थान क्लाइंट में त्रुटि की थी।

मुझे सरल समाधान मिला (केवल सॉकेट को संशोधित करना):

import io.micronaut.context.annotation.Bean;
import io.micronaut.context.annotation.Factory;
import org.apache.http.client.HttpClient;
import org.apache.http.conn.ssl.NoopHostnameVerifier;
import org.apache.http.conn.ssl.SSLConnectionSocketFactory;
import org.apache.http.impl.client.HttpClients;
import org.apache.http.ssl.SSLContexts;

import javax.inject.Named;
import javax.net.ssl.SSLParameters;
import javax.net.ssl.SSLSocket;
import java.io.IOException;
import java.util.List;

@Factory
public class BeanFactory {

    @Bean
    @Named("without_verify")
    public HttpClient provideHttpClient() {
        SSLConnectionSocketFactory connectionSocketFactory = new SSLConnectionSocketFactory(SSLContexts.createDefault(), NoopHostnameVerifier.INSTANCE) {
            @Override
            protected void prepareSocket(SSLSocket socket) throws IOException {
                SSLParameters parameters = socket.getSSLParameters();
                parameters.setServerNames(List.of());
                socket.setSSLParameters(parameters);
                super.prepareSocket(socket);
            }
        };

        return HttpClients.custom()
                .setSSLSocketFactory(connectionSocketFactory)
                .build();
    }


}

— एंड्रयू स्नेक
स्रोत

-1

एक आसान तरीका है जहाँ आप अपने खुद के HostnameVerifier का उपयोग करके कुछ कनेक्शनों पर भरोसा कर सकते हैं। यह मुद्दा जावा 1.7 के साथ आता है जहां SNI एक्सटेंशन जोड़े गए हैं और आपकी गलती एक सर्वर मिसकॉन्फ़िगरेशन के कारण है।

आप पूरे JVM में SNI को निष्क्रिय करने के लिए या तो "-Dss.enableSNIExtension = false" का उपयोग कर सकते हैं या मेरा ब्लॉग पढ़ सकते हैं जहां मैं समझाता हूं कि URL कनेक्शन के शीर्ष पर कस्टम सत्यापनकर्ता कैसे लागू किया जाए।

— MagicDude4Eva
स्रोत