Ivanti Connect Secure (Pulse Secure) पर CSR कैसे जनरेट करें

यह गाइड आपको दिखाती है कि Ivanti Connect Secure पर, जो कई सालों तक Pulse Secure के नाम से बेचा जाने वाला SSL VPN उपकरण है, CSR (Certificate Signing Request) कैसे जेनरेट करें। आप एडमिन कंसोल में System > Configuration > Certificates > Device Certificates के अंतर्गत रिक्वेस्ट बनाते हैं, अपनी संस्था का विवरण भरते हैं, और एन्कोड की गई रिक्वेस्ट को अपने सर्टिफिकेट ऑर्डर में कॉपी करते हैं। उपकरण उसी समय मेल खाने वाली प्राइवेट की भी बनाता है और उसे डिवाइस पर ही रखता है, इसलिए साइन किया गया सर्टिफिकेट उसी उपकरण पर, उसी पेंडिंग रिक्वेस्ट में वापस आना चाहिए।

नाम को लेकर एक टिप्पणी, क्योंकि दोनों नाम अभी भी उपयोग में हैं। यह प्रोडक्ट Juniper Networks के Junos Pulse के रूप में शुरू हुआ था। 2014 में Siris Capital ने यह बिज़नेस Juniper से खरीदा और Pulse Secure बनाया, और 1 दिसंबर 2020 को Ivanti ने Pulse Secure का अधिग्रहण कर लिया और इस रेंज का नाम बदल दिया: Pulse Connect Secure, Ivanti Connect Secure बन गया, Pulse Policy Secure, Ivanti Policy Secure बन गया, और डेस्कटॉप ऐप जिसे ज़्यादातर लोग Pulse Secure कहते थे, अब Ivanti Secure Access Client है। इस काम के लिए सिर्फ ब्रांडिंग बदली है। मेन्यू पथ, बटन के नाम, और नीचे दिया गया फॉर्म वही हैं जो Ivanti वर्तमान 25.1 रिलीज़ के लिए दस्तावेज़ित करता है, और वे पुराने 22.x और 9.1 बिल्ड पर भी वही हैं जो अभी भी Pulse ब्रांडिंग दिखाते हैं।

Ivanti Connect Secure (Pulse Secure) पर CSR जेनरेट करें

यदि आपने पहले ही अपना CSR जेनरेट कर लिया है और CA से साइन की गई फाइलें प्राप्त कर ली हैं, तो इस सेक्शन को छोड़ें और सीधे Ivanti Connect Secure पर SSL सर्टिफिकेट कैसे इंस्टॉल करें पर जाएँ। अन्यथा, नीचे दिए गए चार चरणों में काम करें। शुरू करने से पहले, वह सटीक होस्ट नाम तय करें जिसे आपके यूज़र VPN तक पहुँचने के लिए टाइप करते हैं, क्योंकि यही वह नाम है जो सर्टिफिकेट में होना चाहिए।

चरण 1: Device Certificates पेज खोलें

1. अपने Ivanti Connect Secure उपकरण के एडमिन कंसोल में साइन इन करें।
2. System > Configuration > Certificates > Device Certificates चुनें।
3. उपकरण पर पहले से मौजूद सर्टिफिकेट्स पेज के ऊपर Certificate issued to के अंतर्गत सूचीबद्ध हैं। उस सूची को पार करके New CSR बटन तक जाएँ, जो Certificate Signing Requests टेबल के ठीक ऊपर होता है, और उस पर क्लिक करें। रिक्वेस्ट फॉर्म खुल जाएगा।

चरण 2: requestor जानकारी भरें

यहाँ जो कुछ भी आप टाइप करते हैं वह रिक्वेस्ट में जाता है, और उसमें से ज़्यादातर जारी किए गए सर्टिफिकेट में भी जाता है। मान पूरी तरह से लिखें और संक्षिप्त न करें।

• Common Name: पूरी तरह से क्वालिफाइड डोमेन नाम जिसे सर्टिफिकेट को सुरक्षित करना है, उदाहरण के लिए vpn.yourcompany.com। यह वही नाम होना चाहिए जो यूज़र वास्तव में ब्राउज़र में या Ivanti Secure Access Client में टाइप करते हैं, न कि उपकरण का आंतरिक होस्ट नाम। वाइल्डकार्ड सर्टिफिकेट के लिए, डोमेन के आगे एक तारांकन चिह्न (asterisk) लगाएं, उदाहरण के लिए *.yourcompany.com।
• Organization Name: आपकी कंपनी का पंजीकृत पूरा कानूनी नाम, उदाहरण के लिए Your Company LLC। एक Domain Validated सर्टिफिकेट इसे नज़रअंदाज़ करता है, लेकिन Organization Validated और Extended Validation सर्टिफिकेट कंपनी रिकॉर्ड के विरुद्ध जाँचे जाते हैं, इसलिए कोई उपनाम या व्यापारिक नाम आपके ऑर्डर को रोक सकता है।
• Org. Unit Name: इसे खाली छोड़ दें। 1 सितंबर 2022 से CA/Browser Forum Baseline Requirements ने सार्वजनिक CA को जारी किए गए सर्टिफिकेट में Organizational Unit डालने से रोक दिया है, इसलिए यहाँ आप जो भी टाइप करें वह छोड़ दिया जाता है।
• Locality: वह शहर जहाँ आपका बिज़नेस पंजीकृत है, पूरा लिखा हुआ, उदाहरण के लिए San Jose। यह आपका पंजीकृत पता है, न कि जहाँ उपकरण रैक में लगा है।
• State (fully spelled out): उस पंजीकृत पते का राज्य या प्रांत, पूरा लिखा हुआ, उदाहरण के लिए California, न कि CA।
• Country (2 letter code): दो-अक्षर वाला ISO देश कोड, उदाहरण के लिए US।
• Email Address: एक संपर्क पता। सार्वजनिक CA आपके ऑर्डर पर दिए गए संपर्क विवरण के माध्यम से वेरिफिकेशन चलाते हैं, न कि इस फील्ड के माध्यम से, इसलिए यह तय नहीं करता कि अनुमोदन ईमेल किसे मिलेंगी।

एपोस्ट्रोफी से सावधान रहें। Ivanti दस्तावेज़ में बताया गया है कि इनमें से किसी भी मान के अंदर एपोस्ट्रोफी को बैकस्लैश से एस्केप करना होगा, इसलिए Children’s Trust के रूप में पंजीकृत कंपनी को Children’s Trust के रूप में दर्ज किया जाता है। ऐसा न करने पर या तो रिक्वेस्ट जेनरेट नहीं हो पाती या नाम गलत तरीके से वापस आता है।

चरण 3: की टाइप और लंबाई चुनें

requestor फील्ड्स के नीचे, फॉर्म पूछता है कि की पेयर कैसे बनाई जानी चाहिए। यहाँ तीन सेटिंग्स दिखाई देती हैं, और पहली दो तय करती हैं कि आपका CA रिक्वेस्ट स्वीकार करेगा या नहीं, इसलिए इन्हें नज़रअंदाज़ न करें।

• Key Type: जब तक कोई विशेष कारण न हो, इसे RSA पर ही छोड़ दें। ECC चुनने पर एक ECC Curve मेन्यू दिखाई देता है: Ivanti का अपना वर्किंग उदाहरण P-256 रिक्वेस्ट बनाता है, और इसका Suite B मार्गदर्शन P-256, P-384 और P-521 को कवर करता है। इस चुनाव के साथ दो शर्तें आती हैं: Ivanti ECC सर्टिफिकेट्स को केवल ISA सीरीज़ गेटवे और वर्चुअल एप्लायंस प्लेटफार्मों पर समर्थित बताता है, और एक बार जब ECC सर्टिफिकेट किसी नेटवर्क पोर्ट से जुड़ जाता है, तो केवल ECC सिफर सूट का समर्थन करने वाले क्लाइंट ही उस पोर्ट पर कनेक्ट कर सकते हैं। RSA दोनों समस्याओं से बचाता है।
• Key Length: कम से कम 2048 चुनें, जो सबसे छोटी RSA की है जिसे सार्वजनिक CA साइन करेंगे। मेन्यू में अभी भी 1024 सूचीबद्ध है, इसलिए सुनिश्चित करें कि आप इसे बदल दें। यदि आपकी नीति एक बड़ी की की मांग करती है तो 3072 या 4096 भी ठीक हैं। वर्तमान Ivanti Connect Secure रिलीज़ 8192 बिट तक की डिवाइस सर्टिफिकेट की के लिए समर्थन दस्तावेज़ित करती हैं, लेकिन पुरानी रिलीज़ में 3072-बिट की सीमा दस्तावेज़ित थी, इसलिए बड़ी की की योजना बनाने से पहले जांच लें कि आपका बिल्ड क्या प्रदान करता है।
• Random Data: इस बॉक्स में यादृच्छिक अक्षरों की एक लंबी श्रृंखला टाइप करें। जब उपकरण की बनाता है तो वह आपके टाइप किए गए डेटा को अपने रैंडम नंबर जनरेटर में मिलाता है। यहाँ कुछ याद रखने या लिखने की ज़रूरत नहीं है।

जानने लायक एक वर्जन नोट। रिलीज़ 25.1.0.0 से आगे, Ivanti Connect Secure अब डिजिटल हस्ताक्षरों में SHA-1 स्वीकार नहीं करता, और केवल SHA-1 साइन किए गए डिवाइस सर्टिफिकेट रखने वाला उपकरण अपना यूज़र इंटरफ़ेस लॉन्च करने में विफल रहता है। सार्वजनिक CA ने 2016 की शुरुआत में SHA-1 सर्टिफिकेट जारी करना बंद कर दिया था, इसलिए आज किसी सार्वजनिक CA से ऑर्डर किया गया सर्टिफिकेट प्रभावित नहीं होता। यह तब मायने रखता है जब आप किसी आंतरिक या पुराने CA से रिक्वेस्ट कर रहे हों: सुनिश्चित करें कि वह SHA-256 या बेहतर से साइन करता हो।

चरण 4: रिक्वेस्ट बनाएं

कमिट करने से पहले हर फील्ड को दोबारा पढ़ें, फिर Create CSR पर क्लिक करें। उपकरण रिक्वेस्ट जेनरेट करता है और, उसी समय, उससे संबंधित प्राइवेट की भी। की डिवाइस पर ही रहती है और यह कभी भी आपको दिखाई नहीं जाती या CA को नहीं भेजी जाती।

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

CSR कॉपी करें और इसे अपने CA को भेजें

स्क्रीन पर दिखने वाला ब्लॉक कुछ इस तरह दिखता है:

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

पूरी चीज़ चुनें, जिसमें -----BEGIN CERTIFICATE REQUEST----- और -----END CERTIFICATE REQUEST----- लाइनें भी शामिल हैं। प्रत्येक मार्कर के दोनों ओर पांच हाइफ़न होते हैं। शब्द REQUEST पर ध्यान दें: एक certificate signing request BEGIN CERTIFICATE से डीलिमिट नहीं होता, और छोटा मार्कर पेस्ट करना एक सामान्य कारण है जिससे ऑर्डर फॉर्म रिक्वेस्ट को अस्वीकार करता है। ब्लॉक को Notepad या TextEdit जैसे प्लेन टेक्स्ट एडिटर में पेस्ट करें, फिर अपने ऑर्डर फॉर्म पर CSR बॉक्स में। वर्ड प्रोसेसर का उपयोग न करें, जो अक्षरों को बदल सकता है और एन्कोडिंग को तोड़ सकता है।

जब आप कर लें तो Back to Device Certificates पर क्लिक करें। आपकी रिक्वेस्ट अब Certificate Signing Requests के अंतर्गत एक Pending CSR लिंक के रूप में दिखाई देती है, और आप इसे किसी भी समय दोबारा खोलकर टेक्स्ट को फिर से कॉपी कर सकते हैं।

प्रतीक्षा करते समय दो चीज़ों से बचें:

• पेंडिंग CSR को न हटाएं। Ivanti स्पष्ट रूप से बताता है इसका क्या परिणाम होता है: रिक्वेस्ट को हटाने से उसके साथ प्राइवेट की भी हट जाती है, और आप उससे जारी किए गए सर्टिफिकेट को इंस्टॉल नहीं कर पाएंगे। यदि ऐसा होता है, तो एकमात्र रास्ता एक नया CSR और रीइश्यू है।
• एक समय में एक से अधिक CSR किसी CA को न भेजें। Ivanti चेतावनी देता है कि ऐसा करने से डुप्लिकेट शुल्क लग सकता है।

यदि ऑर्डर फॉर्म पूछता है कि सर्टिफिकेट किस वेब सर्वर के लिए है, तो Apache चुनें, या यदि कई विकल्प सूचीबद्ध हों तो कोई भी Apache विकल्प चुनें। यदि यह सर्टिफिकेट फॉर्मेट पूछता है, तो स्टैंडर्ड वाला लें। दोनों इस उपकरण के लिए Ivanti की अपनी सिफारिशें हैं।

सबमिट करने से पहले CSR की जांच करें

Common Name में टाइपो का मतलब है कि CA एक ऐसा सर्टिफिकेट जारी करता है जिसे आपके यूज़र उपयोग नहीं कर सकते, और रीइश्यू से आपको एक और वेरिफिकेशन राउंड की लागत उठानी पड़ती है। रिक्वेस्ट को हमारे CSR Decoder में पेस्ट करें और इसे पढ़ें: Common Name वही सटीक होस्ट नाम होना चाहिए जो यूज़र टाइप करते हैं, और संस्था का विवरण आपके पंजीकरण से मेल खाना चाहिए। यदि कुछ गलत है, तो उपकरण पर एक नया CSR बनाएं। एन्कोड किए गए टेक्स्ट को कभी संपादित न करें, क्योंकि रिक्वेस्ट अपनी ही प्राइवेट की द्वारा साइन की जाती है और कोई भी बदलाव इसे अमान्य कर देता है।

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

openssl req -noout -text -verify -in vpn.csr

यह subject, key size, और एक लाइन प्रिंट करता है जो पुष्टि करती है कि रिक्वेस्ट अपनी ही की के विरुद्ध सत्यापित होती है।

जब बिल्ट-इन फॉर्म पर्याप्त न हो

New CSR फॉर्म एक ही Common Name मांगता है और अतिरिक्त होस्ट नामों के लिए कोई फील्ड नहीं देता, इसलिए यह मल्टी-डोमेन (SAN) सर्टिफिकेट के लिए रिक्वेस्ट नहीं बना सकता। यदि एक सर्टिफिकेट को कई अलग-अलग नामों को कवर करना है, उदाहरण के लिए vpn.yourcompany.com और portal.yourcompany.com, तो उपकरण के बाहर रिक्वेस्ट बनाएं और बाद में सर्टिफिकेट को उसकी की के साथ इंपोर्ट करें। वाइल्डकार्ड सर्टिफिकेट को इसकी आवश्यकता नहीं है: वाइल्डकार्ड को Common Name के रूप में दर्ज करें और बिल्ट-इन फॉर्म इसे संभाल लेगा।

हमारा CSR Generator एक ही फॉर्म से SAN रिक्वेस्ट बनाता है। यदि आप किसी भी मशीन पर OpenSSL का उपयोग करना पसंद करते हैं, तो यह रिक्वेस्ट और की दोनों एक साथ बनाता है:

openssl req -new -newkey rsa:2048 -nodes 
-keyout vpn.key 
-out vpn.csr 
-subj "/CN=vpn.yourcompany.com/O=Your Company LLC/L=San Jose/ST=California/C=US" 
-addext "subjectAltName=DNS:vpn.yourcompany.com,DNS:portal.yourcompany.com"

Common Name को SAN सूची में पहली प्रविष्टि के रूप में दोहराएं, जैसा कि दिखाया गया है। क्लाइंट होस्ट नाम को SAN प्रविष्टियों से मिलाते हैं और Common Name को नज़रअंदाज़ करते हैं, इसलिए केवल CN में दिखाई देने वाला नाम कवर नहीं होता। vpn.key को कहीं सुरक्षित रखें: इस तरह बनाई गई रिक्वेस्ट के साथ, उपकरण की को नहीं रखता, इसलिए आप इसे इंपोर्ट के समय खुद Import Certificate & Key के माध्यम से प्रदान करते हैं, न कि किसी पेंडिंग CSR के माध्यम से।

CA द्वारा आपका सर्टिफिकेट जारी करने के बाद

जब वेरिफिकेशन पूरा हो जाता है, तो CA आपको साइन किया गया सर्टिफिकेट और उसकी इंटरमीडिएट (CA) चेन ईमेल करता है, आमतौर पर एक ZIP आर्काइव में। इसे एक्सट्रैक्ट करें, फिर वापस System > Configuration > Certificates > Device Certificates पर जाएं, संबंधित Pending CSR लिंक पर क्लिक करें, और Import signed certificate के अंतर्गत फाइल तक ब्राउज़ करें और Import पर क्लिक करें। पेंडिंग रिक्वेस्ट पर इंपोर्ट करने से सर्टिफिकेट उस की के साथ जुड़ता है जिसे उपकरण चरण 4 से रख रहा है।

उपकरण DER या PEM एन्कोडिंग में X.509 सर्टिफिकेट्स (.cer, .crt, .der और .pem फाइलें) के साथ-साथ PKCS#12 (.pfx और .p12) भी स्वीकार करता है। सर्टिफिकेट को इंपोर्ट करना अंतिम चरण नहीं है: आपको अभी भी इंटरमीडिएट सर्टिफिकेट जोड़ने होंगे और यूज़र्स के लिए कुछ भी बदलने से पहले नए सर्टिफिकेट को अपने पोर्ट्स से बाइंड करना होगा। हमारी गाइड Ivanti Connect Secure पर SSL सर्टिफिकेट कैसे इंस्टॉल करें दोनों को कवर करती है।

यदि आप ऐसा सर्टिफिकेट बदल रहे हैं जो एक्सपायर होने वाला है, तो आपके पास एक विकल्प है। ऊपर बताए अनुसार नया CSR बनाना वह विकल्प है जिसे Ivanti अधिक सुरक्षित बताता है, क्योंकि CA एक नई की के विरुद्ध नया सर्टिफिकेट जारी करता है और पुरानी की सेवानिवृत्त हो जाती है। दूसरा विकल्प मौजूदा की को बनाए रखता है, और Ivanti इसे कम सुरक्षित बताता है: अपने CA से रिन्यूअल का ऑर्डर करें, या तो अपना मूल CSR दोबारा सबमिट करके, या यह पुष्टि करके कि CA के पास अभी भी यह रिकॉर्ड में है, फिर सूची में सर्टिफिकेट खोलें, Renew Certificate पर क्लिक करें, रिन्यू की गई फाइल तक ब्राउज़ करें और Import पर क्लिक करें। इससे आप एक नई रिक्वेस्ट बनाने से बच जाते हैं, लेकिन इसकी कीमत यह है कि वही की आगे बनी रहती है।

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