सवाल Https के लिए उचित रूप से "डिफ़ॉल्ट" nginx सर्वर सेट अप करें


मेरे पास एक ही मशीन पर चलने वाले कई सर्वर हैं, कुछ केवल http के साथ हैं, कुछ http और https दोनों के साथ हैं। अलग-अलग फ़ाइलों में परिभाषित कई सर्वर ब्लॉक हैं जो मुख्य कॉन्फ़िगरेशन फ़ाइल से शामिल हैं।

मैंने http के लिए एक "डिफ़ॉल्ट" सर्वर स्थापित किया है जो अनुरोधों के लिए एक सामान्य "रखरखाव पृष्ठ" प्रदान करेगा जो अन्य कॉन्फ़िगरेशन फ़ाइलों में किसी भी अन्य सर्वर_नाम से मेल नहीं खाता है। Http डिफ़ॉल्ट सर्वर अपेक्षित के रूप में काम करता है, यह server_name "_" का उपयोग करता है और यह पहले शामिल सूची में दिखाई देता है (क्योंकि मैंने देखा है कि सर्वर पर डुप्लिकेट सर्वर_नाम के मामले में, पहले दिखाई देने वाला कोई भी उपयोग किया जाता है)। यह बहुत अच्छा काम करता है।

मैं एक ही सटीक सर्वर ब्लॉक की अपेक्षा करता हूं (केवल "सुनें 80 डिफ़ॉल्ट_सर्वर" को "443 डिफ़ॉल्ट_सर्वर सुनें" और पृष्ठ "वापसी 444" की सेवा करने के बजाय)। इसके बजाए, ऐसा प्रतीत होता है कि नया डिफ़ॉल्ट https सर्वर वास्तव में सभी आने वाले https कनेक्शन को पकड़ रहा है और उन्हें असफल कर रहा है, हालांकि अन्य सर्वर ब्लॉक में आने वाले अनुरोधों के लिए अधिक उपयुक्त सर्वर_नाम हैं। नए डिफ़ॉल्ट https सर्वर को हटाने से सेमी-सही व्यवहार फिर से शुरू हो जाएगा: https वाली वेबसाइटें सभी ठीक से लोड हो जाएंगी; लेकिन https के बिना वेबसाइटों को सभी फ़ाइलों में शामिल होने वाले पहले https सर्वर पर भेजा जाएगा (जो दस्तावेज़ों के अनुसार, यदि कोई "default_server" प्रकट नहीं होता है, तो दिखाई देने वाला पहला सर्वर ब्लॉक "डिफ़ॉल्ट" होगा)।

तो मेरा सवाल यह है कि एसएसएल कनेक्शन के लिए nginx में "डिफ़ॉल्ट सर्वर" को परिभाषित करने का सही तरीका क्या है? ऐसा क्यों है कि जब मैं स्पष्ट रूप से "डिफ़ॉल्ट_ सर्वर" सेट करता हूं तो यह लालची हो जाता है और सभी कनेक्शन पकड़ता है, जबकि जब मैं निस्संदेह nginx को "डिफ़ॉल्ट सर्वर" का निर्णय लेता हूं जैसे कि मैं अपेक्षा करता हूं (गलत सर्वर डिफ़ॉल्ट के रूप में सेट किया गया है और अन्य वास्तविक सर्वर सही तरीके से व्यवहार करना)?

यहां मेरे "डिफ़ॉल्ट सर्वर" हैं। एचटीपी अन्य सर्वर तोड़ने के बिना काम करता है। एचटीपीएस अन्य सर्वर तोड़ता है और सभी का उपभोग करता है।

server {
    listen 443 ssl default_server;
    server_name _;

    access_log /var/log/nginx/maintenance.access.log;
    error_log /var/log/nginx/maintenance.error.log error;

    return 444;
}

server {
    listen *:80 default_server;
    server_name _;
    charset utf-8;

    access_log /var/log/nginx/maintenance.access.log;
    error_log /var/log/nginx/maintenance.error.log error;

    root /home/path/to/templates;

    location / {
        return 503;
    }

    error_page 503 @maintenance;

    location @maintenance {
        rewrite ^(.*)$ /maintenance.html break;
    }
}

आप में से कोई भी यहां क्या गलत हो सकता है?


56
2018-02-26 22:29


मूल




जवाब:


आपके पास आपके "डिफ़ॉल्ट" https ब्लॉक में परिभाषित कोई ssl_certificate या ssl_certificate_key नहीं है। यद्यपि आपके पास इस डिफ़ॉल्ट परिदृश्य के लिए असली कुंजी नहीं है या नहीं, आपको अभी भी एक कॉन्फ़िगर करने की आवश्यकता है या नहीं, nginx में आपके द्वारा वर्णित अवांछित व्यवहार होगा।

एक सामान्य नाम के साथ एक स्व-हस्ताक्षरित प्रमाणपत्र बनाएं * और इसे अपनी कॉन्फ़िगरेशन में प्लग करें और यह वैसे ही काम करना शुरू कर देगा जैसा आप चाहते हैं।

इस सेट अप के तहत "डिफ़ॉल्ट" व्यवहार यह होगा कि ब्राउज़र को चेतावनी मिलेगी कि प्रमाणपत्र को भरोसा नहीं किया जा सकता है, यदि उपयोगकर्ता प्रमाणपत्र को अपवाद के रूप में जोड़ता है, तो कनेक्शन nginx द्वारा छोड़ा जाएगा और वे अपने ब्राउज़र का डिफ़ॉल्ट देखेंगे त्रुटि संदेश "कनेक्ट नहीं हो सका"।


19
2018-02-27 16:27



मैंने कोशिश की है लेकिन यह अभी भी काम नहीं करता है: आईपी के लिए सभी एसएसएल अनुरोध मेरे अन्य एसएसएल मेजबान पर जाते हैं। मैं और कुछ और कोशिश कर सकता हूँ? - Michael Härtl


हम मूल रूप से सभी लागतों से बचना चाहते हैं कि हमारी कॉन्फ़िगरेशन फ़ाइल में पहली सर्वर परिभाषा SSL कनेक्शन के लिए कैच-ऑल-सर्वर के रूप में कार्य की जाती है। हम सभी जानते हैं कि यह ऐसा करता है (http का विरोध करता है और default_server कॉन्फ़िगरेशन का उपयोग करता है जो अच्छी तरह से काम करता है)।

यह एसएसएल (अभी तक) के लिए घोषणात्मक रूप से हासिल नहीं किया जा सकता है, इसलिए हमें इसे एक आईएफ के साथ कोड करना होगा ...

चर $host अनुरोध लाइन या http शीर्षलेख से होस्ट नाम है। चर $server_name सर्वर ब्लॉक का नाम है जो हम अभी में हैं।

तो यदि ये दोनों बराबर नहीं हैं तो आपने इस होस्ट सर्वर ब्लॉक को किसी अन्य होस्ट के लिए सेवा दी है ताकि इसे अवरोधित किया जाना चाहिए।

कोड में आपके सर्वर आईपी पतों के विशिष्ट संदर्भ नहीं हैं, इसलिए इसे बिना किसी संशोधन के अन्य सर्वर कॉन्फ़िगरेशन के लिए आसानी से पुन: उपयोग किया जा सकता है।

उदाहरण:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    ###
    ### Section: SSL

    #
    ## Check if this certificate is really served for this server_name
    ##   http://serverfault.com/questions/578648/properly-setting-up-a-default-nginx-server-for-https
    if ($host != $server_name) {
        #return 404 "this is an invalid request";
        return       444;
    }

    ...

13
2017-07-02 00:12



क्या आप समझा सकते हैं कि क्या listen [::]:443 ssl http2; कर देता है? मुझे इसके लिए दस्तावेज खोजने में परेशानी हो रही है। - Andrew Brown
मुझे लगता है कि मैंने इसे पाया, सिर्फ यह जानना आवश्यक था कि क्या खोजना है। आईपीवी 4 और आईपीवी 6 निर्देश। - Andrew Brown


मैं nginx के साथ एक एकल आईपी पर साझा समर्पित होस्टिंग को कॉन्फ़िगर करने में कामयाब रहा। अज्ञात डोमेन के लिए 404 की सेवा करने वाले डिफ़ॉल्ट HTTP और HTTPS।

1 - एक डिफ़ॉल्ट क्षेत्र बनाएँ

चूंकि nginx ascii क्रम में vhosts लोड कर रहा है, आपको एक बनाना चाहिए 00-default आपके अंदर फ़ाइल / प्रतीकात्मक लिंक /etc/nginx/sites-enabled

2 - डिफ़ॉल्ट क्षेत्र भरें

अपना भरें 00-default डिफ़ॉल्ट vhosts के साथ। यहां जो ज़ोन मैं उपयोग कर रहा हूं:

server {
    server_name _;
    listen       80  default_server;
    return       404;
}


server {
    listen 443 ssl;
    server_name _;
    ssl_certificate /etc/nginx/ssl/nginx.crt;
    ssl_certificate_key /etc/nginx/ssl/nginx.key;
    return       404;
}

3 - स्वयं हस्ताक्षरित प्रमाणपत्र, परीक्षण, और पुनः लोड बनाएँ

आपको एक स्वयं हस्ताक्षरित प्रमाणपत्र बनाने की आवश्यकता होगी /etc/nginx/ssl/nginx.crt

एक डिफ़ॉल्ट स्वयं हस्ताक्षरित प्रमाणपत्र बनाएँ:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/nginx/ssl/nginx.key -out /etc/nginx/ssl/nginx.crt

याद दिलाने हेतु:

  • पुनः लोड / पुनरारंभ करने से पहले nginx कॉन्फ़िगरेशन का परीक्षण करें: nginx -t
  • एक आनंद दोबारा लोड करें: sudo service nginx reload

आशा करता हूँ की ये काम करेगा।


12
2018-04-24 11:52



एक असुरक्षित साइट पर जाने की ब्राउज़र चेतावनी को हल नहीं करता है। - gdbj
पकड़ने के बाद से हल नहीं किया जा सकता है - सभी को किसी भी डोमेन से मेल खाना चाहिए। कोई एसएसएल सभी डोमेन वाइल्डकार्ड नहीं कर सकता है। कल्पना करें कि क्या आप अपने सर्वर पर google.fr पता खराब कर रहे हैं, तो आप google.fr के रूप में अपने सर्वर को प्रमाणित करने में सक्षम होंगे। यह एक गंभीर सुरक्षा मुद्दा होगा :( - Ifnot
हां, मुझे लगता है कि समझ में आता है। दुर्भाग्य से क्रोम में, आपको 404 पृष्ठ देखने से पहले एक डरावनी चेतावनी प्रस्तुत की जाती है जो सर्वर को यातायात को अस्वीकार करने से भी बदतर है। ऐसा लगता है कि सर्वर की तरह गलत कॉन्फ़िगर किया गया है। - gdbj


रैडमिला मुस्तफा के जवाब पर और विस्तार करने के लिए:

Nginx server_name मिलान के लिए 'होस्ट' शीर्षलेख का उपयोग करता है। यह टीएलएस एसएनआई का उपयोग नहीं करता है। इसका मतलब है कि एक एसएसएल सर्वर के लिए, nginx एसएसएल कनेक्शन स्वीकार करने में सक्षम होना चाहिए, जो सर्टिफिकेट / कुंजी रखने के लिए उबलता है। प्रमाण / कुंजी कोई भी हो सकता है, उदा। स्व-हस्ताक्षरित।

देख प्रलेखन

इसलिए, समाधान है:

server {
    server_name _;
    listen 80 default_server;
    listen 443 ssl default_server;
    ssl_certificate <path to cert>;
    ssl_certificate_key <path to key>;
    return 404; # or whatever
}

3
2018-03-30 21:17



मुझे लगता है कि यह स्वीकार्य उत्तर होना चाहिए। बहुत धन्यवाद। - aggregate1166877


यदि आप पूरी तरह से सुनिश्चित होना चाहते हैं, तो मेजबानों के लिए अलग-अलग आईपी पते का उपयोग करें जिन्हें HTTPS और होस्ट्स पर जवाब नहीं देना चाहिए। यह "अमान्य प्रमाणपत्र" ब्राउज़र चेतावनी समस्या का भी समाधान करता है।


1
2018-02-27 13:19