NGINX पर SSL सर्टिफिकेट कैसे इंस्टॉल करें

यह गाइड आपको दिखाती है कि NGINX पर SSL/TLS सर्टिफिकेट कैसे इंस्टॉल करें। इसमें उस हिस्से को कवर किया गया है जो ज्यादातर लोगों को उलझाता है: सही सर्टिफिकेट चेन (“fullchain”) बनाना जिसकी NGINX को आवश्यकता होती है, सही डायरेक्टिव्स को सही फाइलों की ओर इंगित करना, रीलोड करने से पहले कॉन्फ़िगरेशन का परीक्षण करना, और एक साफ-सुथरा HTTP से HTTPS रीडायरेक्ट जोड़ना ताकि हर विज़िटर आपकी साइट के सुरक्षित वर्जन पर पहुंचे।

NGINX के लिए CSR कोड जनरेट करें

यदि आपने पहले ही अपना CSR जनरेट कर लिया है और जारी किए गए सर्टिफिकेट फाइलें आपके हाथ में हैं, तो आगे बढ़कर NGINX पर SSL सर्टिफिकेट इंस्टॉल करें पर जाएं।

इससे पहले कि कोई सर्टिफिकेट अथॉरिटी आपका सर्टिफिकेट जारी कर सके, आपको एक CSR (सर्टिफिकेट साइनिंग रिक्वेस्ट) सबमिट करना होगा: टेक्स्ट का एक छोटा ब्लॉक जिसमें आपके डोमेन का विवरण और एक पब्लिक की होती है, जो सर्वर पर रखी गई प्राइवेट की के साथ जोड़ी जाती है। आपके पास दो विकल्प हैं:

• हमारे CSR जनरेटर के साथ CSR को स्वचालित रूप से जनरेट करें। यह टूल CSR और उसकी मिलती-जुलती प्राइवेट की दोनों लौटाता है, जिसे आप फिर सर्वर पर अपलोड करते हैं।
• NGINX पर CSR कैसे जनरेट करें, इस पर हमारे ट्यूटोरियल का पालन करके OpenSSL के साथ सर्वर पर ही CSR जनरेट करें: NGINX पर CSR कैसे जनरेट करें। प्राइवेट की सर्वर पर ही रहती है।

परिणामी .csr फाइल को किसी भी टेक्स्ट एडिटर में खोलें; उसके अंदर का टेक्स्ट ब्लॉक (जिसमें —–BEGIN CERTIFICATE REQUEST—– और —–END CERTIFICATE REQUEST—– लाइनें शामिल हैं) वही है जिसे आप चेकआउट के दौरान SSL एप्लिकेशन फॉर्म में पेस्ट करते हैं। यदि आप सबमिट करने से पहले CSR की सामग्री की पुष्टि करना चाहते हैं, तो इसे हमारे CSR डिकोडर में पेस्ट करें।

NGINX पर SSL सर्टिफिकेट इंस्टॉल करें

एक बार जब CA सर्टिफिकेट जारी कर देती है, तो आपको आम तौर पर ये मिलेंगे:

• आपका प्राथमिक (सर्वर) सर्टिफिकेट, आमतौर पर आपके डोमेन के नाम पर रखी गई .crt फाइल।
• इंटरमीडिएट (और कभी-कभी रूट) सर्टिफिकेट्स, या तो अलग .crt फाइलों के रूप में या एक .ca-bundle फाइल में बंडल किए गए।
• प्राइवेट की (एक .key फाइल) जो आपके CSR के साथ जनरेट की गई थी।

NGINX को सर्वर सर्टिफिकेट और इंटरमीडिएट चेन को एक ही फाइल में मिलाने की जरूरत होती है (“fullchain”) और इसे ssl_certificate द्वारा इंगित किया जाता है; प्राइवेट की को अलग से ssl_certificate_key द्वारा इंगित किया जाता है। चेन को छोड़ना सबसे आम इंस्टॉलेशन गलती है: सर्टिफिकेट डेस्कटॉप ब्राउज़र में ठीक दिखता है लेकिन Android पर, API क्लाइंट्स में, और हमारे SSL Checker जैसे टूल्स पर विफल हो जाता है।

चरण 1: सर्टिफिकेट्स को एक फाइल में मिलाएं

संयुक्त फाइल में सर्टिफिकेट्स का क्रम मायने रखता है। आपका सर्वर सर्टिफिकेट पहले आता है, फिर लीफ-इशूइंग CA से ऊपर की ओर प्रत्येक इंटरमीडिएट, रूट अंत में (या छोड़ा जा सकता है, क्योंकि ब्राउज़र पहले से ही अपने बिल्ट-इन स्टोर से रूट्स पर भरोसा करते हैं):

• डोमेन नाम के लिए आपका प्राथमिक सर्टिफिकेट।
• इंटरमीडिएट सर्टिफिकेट(स)।
• रूट सर्टिफिकेट (वैकल्पिक)।

आप fullchain फाइल को टेक्स्ट एडिटर में मैन्युअल रूप से बना सकते हैं (प्रत्येक PEM ब्लॉक को क्रम में पेस्ट करें), या एक ही cat कमांड के साथ। यदि आपको अलग इंटरमीडिएट और रूट फाइलें मिली हैं, तो चलाएं:

cat your_domain.crt intermediate.crt root.crt > ssl-bundle.crt

यदि इंटरमीडिएट्स और रूट पहले से ही एक .ca-bundle फाइल में हैं, तो चलाएं:

cat example_com.crt example_com.ca-bundle > ssl-bundle.crt

फाइल के नामों को अपने खुद के नामों से बदलें। संयुक्त फाइल (और यदि पहले से वहां नहीं है तो प्राइवेट की को भी) को अपने सर्वर पर SSL डायरेक्टरी में ले जाएं, उदाहरण के लिए /etc/ssl/ या /etc/nginx/ssl/। की फाइल को केवल root द्वारा पढ़ने योग्य रखें:

sudo chmod 600 /etc/ssl/your_domain.key
sudo chown root:root /etc/ssl/your_domain.key

चरण 2: NGINX कॉन्फ़िगरेशन फाइल संपादित करें

अपनी साइट के लिए NGINX कॉन्फ़िगरेशन फाइल खोलें। Debian और Ubuntu पर यह /etc/nginx/sites-available/ में रहती है (sites-enabled/ में एक सिमलिंक के साथ); RHEL, CentOS, AlmaLinux, और Rocky Linux पर यह /etc/nginx/conf.d/ में रहती है। पोर्ट 443 पर सुनने वाले सर्वर ब्लॉक को जोड़ें या संपादित करें ताकि यह fullchain फाइल और प्राइवेट की की ओर इंगित करे:

server {
    listen 443 ssl;
    http2 on;
    server_name example.com www.example.com;

    ssl_certificate     /etc/ssl/ssl-bundle.crt;
    ssl_certificate_key /etc/ssl/your_domain.key;

    # Modern TLS only
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;

    ssl_session_timeout 1d;
    ssl_session_cache shared:NginxSSL:10m;
    ssl_session_tickets off;

    access_log /var/log/nginx/example.com.access.log;
    error_log  /var/log/nginx/example.com.error.log;

    root /var/www/example.com;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

उपरोक्त डायरेक्टिव्स पर कुछ नोट्स:

• listen 443 ssl; पोर्ट 443 पर TLS को सक्षम करता है। पुराना ssl on; डायरेक्टिव NGINX 1.25 में हटा दिया गया था और इसे आधुनिक कॉन्फ़िगरेशन में नहीं दिखना चाहिए।
• http2 on; HTTP/2 को अपने खुद के डायरेक्टिव के रूप में चालू करता है (NGINX 1.25.1 और बाद में)। पुराने कॉन्फ़िगरेशन में listen 443 ssl http2; का उपयोग होता था, जो अभी भी काम करता है लेकिन पदावनत है।
• ssl_protocols TLSv1.2 TLSv1.3; पुराने TLS 1.0 और 1.1 को अक्षम करता है। NGINX 1.27.3 से आगे, यदि आप डायरेक्टिव को छोड़ देते हैं तो यह डिफ़ॉल्ट भी है, लेकिन इसे स्पष्ट रूप से सेट करना ऑडिट-फ्रेंडली स्पष्ट विकल्प है।
• सिफर लिस्ट Mozilla के “intermediate” प्रोफाइल से मेल खाती है और हर हाल के क्लाइंट पर काम करती है। यदि आपको केवल TLS 1.3 क्लाइंट्स की आवश्यकता है, तो आप ssl_ciphers को पूरी तरह छोड़ सकते हैं।

चरण 3: HTTP को HTTPS पर रीडायरेक्ट करें

पोर्ट 80 पर एक अलग सर्वर ब्लॉक जोड़ें जो हर अनुरोध को स्थायी रूप से HTTPS पर रीडायरेक्ट करता है, ताकि सादे HTTP से आने वाले विज़िटर सुरक्षित URL पर पहुंचें:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

return 301 का उपयोग करना रेगेक्स-आधारित rewrite नियम की तुलना में तेज़ और सुरक्षित है, और यह वह पैटर्न है जिसकी NGINX खुद सिफारिश करता है।

चरण 4: कॉन्फ़िगरेशन का परीक्षण करें और NGINX को रीलोड करें

रीलोड करने से पहले हमेशा कॉन्फ़िगरेशन को वैलिडेट करें, ताकि कोई टाइपो सेवा को ऑफलाइन न कर दे:

sudo nginx -t

आपको syntax is ok और test is successful दिखना चाहिए। यदि यह किसी त्रुटि की रिपोर्ट करता है, तो संदेश में फाइल और लाइन नंबर शामिल होता है; इसे ठीक करें और परीक्षण फिर से चलाएं। जब परीक्षण पास हो जाए, तो NGINX को रीलोड करें ताकि यह मौजूदा कनेक्शनों को गिराए बिना नए कॉन्फ़िगरेशन को अपना ले:

sudo systemctl reload nginx

systemd के बिना सिस्टम पर, इसके बजाय NGINX के अपने रीलोड सिग्नल का उपयोग करें:

sudo nginx -s reload

restart की तुलना में reload को प्राथमिकता दें: एक रीलोड कॉन्फ़िगरेशन को सक्रिय कनेक्शनों को बंद किए बिना फिर से पढ़ता है, जबकि रीस्टार्ट उन्हें गिरा देता है।

चरण 5 (वैकल्पिक): OCSP स्टेपलिंग सक्षम करें

OCSP स्टेपलिंग NGINX को सर्टिफिकेट के साथ एक ताज़ा, हस्ताक्षरित निरस्तीकरण स्थिति देने देता है, ताकि क्लाइंट्स को हर हैंडशेक पर CA से संपर्क न करना पड़े। अपने HTTPS सर्वर ब्लॉक के अंदर निम्नलिखित जोड़ें:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/ssl-bundle.crt;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;

NGINX को sudo systemctl reload nginx के साथ फिर से रीलोड करें। स्टेपलिंग एक छोटा लेकिन सार्थक हार्डनिंग कदम है, और अधिकांश आधुनिक सर्टिफिकेट इसे शुरू से ही सपोर्ट करते हैं।

इंस्टॉलेशन की पुष्टि करें

ब्राउज़र में https:// पर अपनी साइट खोलें और जांचें कि पैडलॉक बंद है और सर्टिफिकेट आपके डोमेन से मेल खाता है। फिर सर्टिफिकेट, चेन, और आपके सर्वर द्वारा प्रस्तावित प्रोटोकॉल और सिफर्स पर तुरंत रिपोर्ट के लिए हमारे SSL Checker के साथ एक गहरा स्कैन चलाएं। वहां हरे रंग का परिणाम मतलब है कि हर प्रमुख प्लेटफॉर्म के क्लाइंट सर्टिफिकेट पर भरोसा करेंगे, जिसमें मोबाइल और API क्लाइंट्स शामिल हैं।

अक्सर पूछे जाने वाले प्रश्न