FileZilla Server पर CSR कैसे जनरेट करें

यह ट्यूटोरियल आपको दिखाता है FileZilla Server के लिए CSR कैसे जनरेट करें। सबसे पहले उस हिस्से से शुरुआत करते हैं जो सबसे ज्यादा समय बचाता है: FileZilla Server एक Certificate Signing Request नहीं बना सकता। एडमिनिस्ट्रेशन इंटरफेस में, किसी भी वर्जन में, इसके लिए कहीं भी कोई बटन नहीं है। सर्वर एक सेल्फ-साइन्ड सर्टिफिकेट जनरेट कर सकता है, Let’s Encrypt से एक स्वचालित रूप से प्राप्त कर सकता है, या आपके द्वारा दिया गया सर्टिफिकेट और प्राइवेट की लोड कर सकता है, और यह तीसरा विकल्प वही है जिसमें एक कमर्शियल Certificate Authority का सर्टिफिकेट जाता है। इसलिए रिक्वेस्ट FileZilla Server के बाहर बनाई जाती है, OpenSSL से या किसी ऑनलाइन जनरेटर से, और सिर्फ तैयार की और सर्टिफिकेट ही सर्वर को दी जाती है।

कमांड्स से पहले वर्जन्स पर एक नोट, क्योंकि यह तय करता है कि आप कौन सा टर्मिनल खोलें। FileZilla Server को सितंबर 2021 में वर्जन 1.0 के लिए फिर से लिखा गया था, और वर्तमान रिलीज़ 1.12.6 है, जो मई 2026 में प्रकाशित हुई। Debian और macOS पैकेज दिसंबर 2021 में वर्जन 1.2.0 के साथ आए; उससे पहले सर्वर केवल Windows पर चलता था, और Windows अभी भी वह जगह है जहाँ ज्यादातर इंस्टॉलेशन्स रहते हैं। पुराने निर्देश जो “SSH के जरिए लॉग इन करें” से शुरू होते हैं, चुपचाप एक Linux होस्ट मान लेते हैं। पुरानी 0.9.x लाइन फरवरी 2017 में 0.9.60.2 के साथ समाप्त हो गई थी और तब से इसमें कोई सिक्योरिटी अपडेट नहीं आया है, इसलिए यदि आप अभी भी इसी पर हैं, तो सर्टिफिकेट के साथ अपग्रेड की भी योजना बनाएं।

FileZilla Server सर्टिफिकेट्स के साथ क्या करता है

रिक्वेस्ट बनाने से पहले मंज़िल को देखना उपयोगी है, क्योंकि यह बताता है कि फाइलों का आकार क्या होना चाहिए। FileZilla Server एडमिनिस्ट्रेशन इंटरफेस खोलें, सर्वर से कनेक्ट करें, फिर मेनू बार से Server और Configure… चुनें (कीबोर्ड शॉर्टकट Ctrl+F है)। बाईं ओर के ट्री में, Protocols settings खोलें, फिर FTP and FTP over TLS (FTPS), फिर Connection Security टैब।

उस पेज पर दो चीज़ें हैं: एक Minimum allowed TLS version मेनू जो v1.2 और v1.3 प्रस्तुत करता है, और एक TLS credentials सिलेक्टर जिसमें तीन विकल्प हैं और कुछ नहीं:

• Provide a X.509 certificate and private key. दो फील्ड्स, Certificate और Private key, जिनमें से प्रत्येक या तो सीधे इंटरफेस में पेस्ट किया गया कच्चा PEM डेटा स्वीकार करती है या सर्वर की फाइल सिस्टम पर किसी फाइल का पथ। की फील्ड अतिरिक्त रूप से एक PKCS#11 URL भी स्वीकार करती है यदि की एक हार्डवेयर टोकन पर हो। उनके नीचे Private key password (stored in plaintext) है। यहीं पर CA-जारी सर्टिफिकेट जाता है।
• Use a self-signed X.509 certificate. एक Generate new बटन जो एक ऐसा सर्टिफिकेट बनाता है जिसे सर्वर खुद साइन करता है। एक बंद टेस्ट के लिए उपयोगी, लेकिन कोई भी क्लाइंट इस पर भरोसा नहीं करता, इसलिए हर कनेक्शन एक चेतावनी उत्पन्न करता है।
• Use a Let’s Encrypt® certificate. बिल्ट-इन ACME सपोर्ट, जो FileZilla Server 1.0 में जोड़ा गया था। सर्वर खुद सर्टिफिकेट का अनुरोध करता है और उसे रिन्यू करता है, आपके लिए संभालने के लिए कोई CSR नहीं।

इन तीनों में से कोई भी एक ऐसा सर्टिफिकेट साइनिंग रिक्वेस्ट नहीं बनाता जिसे आप किसी Certificate Authority को भेज सकें। FileZilla Server आंतरिक रूप से Let’s Encrypt एक्सचेंज के हिस्से के रूप में एक बनाता तो है, लेकिन इसे कभी डिस्क पर नहीं लिखा जाता या इंटरफेस में नहीं दिखाया जाता, और यह उस स्वचालित ऑर्डर से बंधा होता है।

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

FileZilla Server के लिए CSR जनरेट करें

यदि आपने पहले ही अपना CSR जनरेट कर लिया है, तो इस सेक्शन को छोड़ें और सर्टिफिकेट जारी होने के बाद सीधे FileZilla Server पर अपना SSL सर्टिफिकेट इंस्टॉल करना पर जाएं। अन्यथा, नीचे दिए गए दो रास्तों में से एक चुनें। दोनों समान फाइलों की जोड़ी बनाते हैं।

विकल्प 1: SSL Dragon CSR Generator का उपयोग करें

हमारा CSR Generator एक ही फॉर्म से रिक्वेस्ट और मैचिंग प्राइवेट की बनाता है, जिससे केवल एक कमांड चलाने के लिए Windows सर्वर पर OpenSSL इंस्टॉल करने से बचा जा सकता है। इसके द्वारा बनाई गई प्राइवेट की को सेव करें और उसे किसी सुरक्षित जगह पर रखें। CA द्वारा जारी सर्टिफिकेट इसके बिना बेकार है, और कोई भी आपको इसका रिप्लेसमेंट नहीं भेज सकता।

विकल्प 2: OpenSSL के साथ CSR जनरेट करें

आप कमांड कहाँ चलाते हैं यह इस बात पर निर्भर करता है कि FileZilla Server को कौन सा ऑपरेटिंग सिस्टम होस्ट कर रहा है:

• Windows. Command Prompt या PowerShell खोलें। Windows OpenSSL के साथ नहीं आता, इसलिए आपको एक की जरूरत है: Git for Windows में एक बिल्ड शामिल है जो Git Bash के अंदर पथ में है, या आप एक स्टैंडअलोन Windows OpenSSL पैकेज इंस्टॉल कर सकते हैं, या Windows Subsystem for Linux का उपयोग कर सकते हैं। आप जो भी चुनें, पहले openssl version चलाएं और सुनिश्चित करें कि यह जवाब देता है।
• Linux. सर्वर पर एक टर्मिनल खोलें, या SSH के जरिए कनेक्ट करें। OpenSSL मुख्यधारा के डिस्ट्रीब्यूशन्स पर डिफॉल्ट रूप से इंस्टॉल होता है।
• macOS. Terminal खोलें। macOS पर openssl कमांड OpenSSL के बजाय एक LibreSSL बिल्ड है, जो नीचे बताए गए कुछ विकल्पों के लिए मायने रखता है। इस ट्यूटोरियल में हर कमांड दोनों बिल्ड्स पर चलाई गई और दोनों पर काम करती है।

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

openssl req -new -newkey rsa:2048 -nodes -keyout ftp.yourdomain.com.key -out ftp.yourdomain.com.csr -addext "subjectAltName=DNS:ftp.yourdomain.com"

प्रत्येक भाग क्या करता है:

• req -new एक नया सर्टिफिकेट साइनिंग रिक्वेस्ट बनाता है।
• -newkey rsa:2048 साथ ही एक नई 2048-बिट RSA की जनरेट करता है। यह सबसे छोटी की है जिसे पब्लिक CAs साइन करेंगे। यदि आपकी सिक्योरिटी पॉलिसी इसकी मांग करे तो rsa:4096 का उपयोग करें।
• -nodes प्राइवेट की को बिना पासफ्रेज़ के लिखता है, ताकि FileZilla Server रीबूट के बाद इसे बिना किसी दखल के पढ़ सके। इसी स्पेलिंग का उपयोग करें, नए -noenc अलियास का नहीं: OpenSSL 3.x दोनों स्वीकार करता है, लेकिन macOS द्वारा openssl के रूप में भेजा गया LibreSSL बिल्ड -noenc को रिजेक्ट कर देता है और चलने के बजाय अपना उपयोग ब्लॉक प्रिंट कर देता है।
• -keyout और -out दो आउटपुट फाइलों के नाम रखते हैं। इन्हें होस्ट के नाम पर रखना server.key और server.csr से बेहतर है, क्योंकि एक साल बाद आपके पास कई होंगी।
• -addext "subjectAltName=..." होस्ट नाम को Subject Alternative Name एक्सटेंशन में डालता है। इसे न छोड़ें। CA/Browser Forum Baseline Requirements अब Common Name को अनुशंसित नहीं मानता है और मांग करता है कि इसमें कोई भी वैल्यू SAN एंट्रीज़ से ली गई हो, इसलिए SAN लिस्ट ही प्रामाणिक है।

कई होस्ट नामों के लिए, या वाइल्डकार्ड के लिए, उसी विकल्प को कॉमा-सेपरेटेड लिस्ट के साथ विस्तारित करें। इसके अंदर Common Name को दोहराएं:

-addext "subjectAltName=DNS:ftp.yourdomain.com,DNS:files.yourdomain.com"

-addext "subjectAltName=DNS:*.yourdomain.com,DNS:yourdomain.com"

यदि आप elliptic-curve की का उपयोग करना पसंद करते हैं, तो समकक्ष कमांड नीचे है। पहले जांच लें कि आपकी Certificate Authority जो प्रोडक्ट आप खरीद रहे हैं उसके लिए ECDSA सर्टिफिकेट जारी करती है, क्योंकि हर ब्रांड ऐसा नहीं करता।

openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -pkeyopt ec_param_enc:named_curve -nodes -keyout ftp.yourdomain.com.key -out ftp.yourdomain.com.csr -addext "subjectAltName=DNS:ftp.yourdomain.com"

दूसरा -pkeyopt सजावट नहीं है। OpenSSL पर यह कुछ नहीं बदलता, क्योंकि नामित कर्व पहले से ही डिफॉल्ट है, लेकिन macOS के साथ भेजे गए LibreSSL बिल्ड पर इसकी अनुपस्थिति रिक्वेस्ट को कर्व का नाम बताने के बजाय उसके सभी पैरामीटर्स लिखकर उसे वर्णित करा देती है। RFC 5480 पब्लिक सर्टिफिकेट्स में उस रूप को प्रतिबंधित करता है, और इस तरह बनाई गई रिक्वेस्ट किसी भी कर्व की पहचान नहीं करती।

प्रॉम्प्ट्स का जवाब दें

OpenSSL अब उन विवरणों के लिए पूछता है जो रिक्वेस्ट में जाते हैं, इस क्रम में:

1. Country Name (2 letter code): आपके देश का दो अक्षरों वाला कोड, उदाहरण के लिए US। यहाँ देश कोड्स की पूरी सूची है।
2. State or Province Name (full name): पूरा लिखा हुआ। California, न कि CA।
3. Locality Name (eg, city): शहर का पूरा नाम, उदाहरण के लिए San Jose।
4. Organization Name (eg, company): आपके संगठन का सटीक कानूनी नाम, उदाहरण के लिए Example Holding LLC। यदि आप एक Domain Validation सर्टिफिकेट खरीद रहे हैं, तो CA इस फील्ड को सत्यापित या उपयोग नहीं करता, इसलिए इसे छोड़ा जा सकता है।
5. Organizational Unit Name (eg, section): इसे छोड़ दें। 1 सितंबर 2022 से CA/Browser Forum Baseline Requirements ने इस एट्रिब्यूट को उन में सूचीबद्ध किया है जिन्हें CAs को शामिल नहीं करना चाहिए, इसलिए आप जो भी टाइप करें उसे हटा दिया जाता है।
6. Common Name: वह फुली क्वालिफाइड होस्ट नाम जिससे आपके FTPS क्लाइंट कनेक्ट होते हैं, उदाहरण के लिए ftp.yourdomain.com, या वाइल्डकार्ड *.yourdomain.com। इस प्रॉम्प्ट की शब्दावली बिल्ड्स के बीच थोड़ी भिन्न होती है, लेकिन डिफॉल्ट कॉन्फ़िगरेशन में यह छठा प्रश्न है।
7. Email Address: वैकल्पिक, और सामान्य रूप से छोड़ दिया जाता है।
8. A challenge password: इसे छोड़ दें। यह रिक्वेस्ट का ही एक पुराना एट्रिब्यूट है, यह कभी जारी किए गए सर्टिफिकेट तक नहीं पहुंचता, और सर्टिफिकेट ऑर्डर फॉर्म इसके लिए नहीं पूछते।
9. An optional company name: इसे भी छोड़ दें।

टाइप करना शुरू करने से पहले जानने लायक एक जाल। “इसे छोड़ दें” का मतलब “Enter दबाएं” नहीं है। कई फील्ड्स में OpenSSL की कॉन्फ़िगरेशन फाइल से एक डिफॉल्ट वैल्यू होती है, जो प्रॉम्प्ट के अंत में स्क्वायर ब्रैकेट्स में दिखाई जाती है, और Enter दबाने से फील्ड खाली छोड़ने के बजाय वह डिफॉल्ट स्वीकार हो जाती है। एक स्टॉक OpenSSL कॉन्फ़िगरेशन पर, पहले कुछ सवालों में Enter दबाने से एक ऐसी रिक्वेस्ट बनी जिसमें C=AU, ST=Some-State और O=Internet Widgits Pty Ltd लिखा था, जो कोई भी Certificate Authority को नहीं भेजना चाहता। किसी फील्ड को वास्तव में खाली छोड़ने के लिए, एक सिंगल पीरियड टाइप करें और Enter दबाएं। OpenSSL यही बात सवालों के ठीक ऊपर प्रिंट किए गए प्रस्तावना में कहता है।

जब अंतिम सवाल का जवाब दे दिया जाता है, तो वर्तमान डायरेक्टरी में आपके पास दो नई फाइलें होती हैं:

• ftp.yourdomain.com.csr: सर्टिफिकेट साइनिंग रिक्वेस्ट। यही वह है जिसे आप अपने ऑर्डर फॉर्म में पेस्ट करते हैं।
• ftp.yourdomain.com.key: प्राइवेट की। यह कभी Certificate Authority को नहीं जाती और आपके नियंत्रण से बाहर कभी नहीं जाती। इसे रखने वाला कोई भी व्यक्ति आपके सर्वर का रूप धारण कर सकता है, इसलिए इसे कौन पढ़ सकता है इसे सीमित करें और इसका बैकअप किसी ऐसी जगह रखें जहां तीन साल बाद भी आपकी पहुंच हो। इसे खोने पर जारी किया गया सर्टिफिकेट बेकार हो जाता है: आपको एक नई रिक्वेस्ट जनरेट करनी होगी और फिर से जारी करने के लिए कहना होगा।

ऑर्डर करने से पहले CSR की जांच करें

रिक्वेस्ट में एक टाइपो का मतलब है कि CA एक ऐसा सर्टिफिकेट जारी करता है जिसका आप उपयोग नहीं कर सकते, और इसे ठीक करने में एक और वैलिडेशन राउंड का खर्च आता है। सबमिट करने से पहले रिक्वेस्ट को वापस पढ़ें:

openssl req -noout -text -verify -in ftp.yourdomain.com.csr

आउटपुट में तीन चीज़ें जांचें: Subject लाइन में आपके द्वारा दर्ज किए गए विवरण हैं, Subject Alternative Name सेक्शन में हर वह होस्ट नाम सूचीबद्ध है जिनका उपयोग क्लाइंट्स करेंगे, और सिग्नेचर चेक पास होता है। OpenSSL 3.x इस अंतिम को Certificate request self-signature verify OK के रूप में रिपोर्ट करता है, जबकि macOS पर LibreSSL बिल्ड इसे छोटा कर verify OK कर देता है। दोनों का मतलब एक ही है। यदि आप कमांड लाइन पर काम करना पसंद नहीं करते, तो इसके बजाय रिक्वेस्ट को हमारे CSR Decoder में पेस्ट करें।

यह पुष्टि करना भी उपयोगी है कि डिस्क पर मौजूद की वास्तव में वही है जिससे यह रिक्वेस्ट बनाई गई थी, खासकर यदि आपने कई जनरेट की हों। पब्लिक कीज़ की तुलना करना किसी भी की टाइप पर और OpenSSL तथा LibreSSL दोनों पर काम करता है:

openssl req -noout -pubkey -in ftp.yourdomain.com.csr
openssl pkey -pubout -in ftp.yourdomain.com.key

दोनों ब्लॉक्स बिल्कुल एक जैसे होने चाहिए, अक्षर दर अक्षर। यह उस अधिक परिचित modulus-and-md5 तुलना का पोर्टेबल संस्करण है, जो केवल RSA कीज़ के लिए काम करता है और एक स्वस्थ elliptic-curve जोड़ी को मिसमैच के रूप में रिपोर्ट करता है।

अंत में, .csr फाइल को Notepad या TextEdit जैसे प्लेन टेक्स्ट एडिटर में खोलें और पूरे ब्लॉक को कॉपी करें, पहली और आखिरी लाइनों सहित:

-----BEGIN CERTIFICATE REQUEST-----
MIICvDCCAaQCAQAwdzELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWEx
... (many lines of base64) ...
-----END CERTIFICATE REQUEST-----

हर मार्कर लाइन ठीक पांच हाइफन, शब्द, फिर पांच और हाइफन है। इन्हें हाथ से दोबारा टाइप न करें और किसी वर्ड प्रोसेसर के माध्यम से पेस्ट न करें, जो हाइफन के क्रम को डैश में बदल सकता है और एक ऐसी रिक्वेस्ट बना सकता है जिसे CA विकृत मानकर रिजेक्ट कर देगा।

जब आपको बिल्कुल भी CSR की जरूरत नहीं है

वर्जन 1.0 से, FileZilla Server अपने आप एक फ्री Let’s Encrypt सर्टिफिकेट प्राप्त कर सकता है और उसे रिन्यू कर सकता है, बिना आपके किसी रिक्वेस्ट को जनरेट किए और बिना किसी फाइल को इंपोर्ट किए। वही सेटिंग्स डायलॉग में ट्री में Logging के नीचे एक टॉप-लेवल Let’s Encrypt® पेज है। Enable Let’s Encrypt® certificate generation पर टिक करें, Create new account पर क्लिक करें और सेवा की शर्तें स्वीकार करें, फिर How to perform the challenges के तहत चुनें कि FileZilla Server उन्हें अपने खुद के आंतरिक वेब सर्वर से जवाब दे (यह डिफॉल्ट रूप से पोर्ट 80 प्रस्तावित करता है) या क्या आप इसे उस फोल्डर की ओर इशारा करेंगे जिसका उपयोग एक मौजूदा वेब सर्वर /.well-known/acme-challenge/ के तहत रिक्वेस्ट्स का जवाब देने के लिए करता है। इसके बाद, Connection Security टैब पर Use a Let’s Encrypt® certificate चुनें और Automatically try to renew the certificate in due time को टिक रहने दें।

दो सीमाएं तय करती हैं कि यह आपके लिए व्यावहारिक है या नहीं। सर्वर केवल HTTP वैलिडेशन चैलेंजेस का जवाब देता है, इसलिए सर्टिफिकेट जारी होते समय और हर बार रिन्यू होने पर होस्ट नाम को चैलेंज पोर्ट पर इंटरनेट से पहुंच योग्य होना चाहिए। और चूंकि Let’s Encrypt के वाइल्डकार्ड सर्टिफिकेट्स को DNS-आधारित वैलिडेशन की जरूरत होती है, जिसे FileZilla Server नहीं करता, आप इस तरह वाइल्डकार्ड नहीं प्राप्त कर सकते।

इसलिए ऊपर बताया गया CSR रास्ता अभी भी वही है जिसे अपनाना चाहिए यदि आपको वाइल्डकार्ड, एक Organization Validation या Extended Validation सर्टिफिकेट, या ऐसे सर्वर के लिए सर्टिफिकेट चाहिए जो इंटरनेट के संपर्क में नहीं है। हमारे ACME ट्यूटोरियल्स स्वचालित जारी करने को अधिक गहराई से कवर करते हैं। शेष विकल्प, Use a self-signed X.509 certificate के तहत Generate new बटन, केवल टेस्टिंग के लिए है: यह सेकंडों में FTPS को चालू कर देता है, और यह हर क्लाइंट को एक चेतावनी दिखाता है जिसे यूज़र्स जल्दी ही क्लिक करके आगे बढ़ना सीख जाते हैं।

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