Android पर CSR कैसे जनरेट करें

यह ट्यूटोरियल आपको दिखाता है कि Java keytool यूटिलिटी का उपयोग करके Android के लिए CSR (Certificate Signing Request) कैसे जनरेट करें।

Android फोन पर स्वयं पब्लिक-CA TLS CSR जनरेट नहीं करता: पब्लिक-CA सर्टिफिकेट किसी सर्वर (या उपयोगकर्ता द्वारा नियंत्रित डिवाइस) के लिए जारी किया जाता है, और Android ऐप्स तथा ब्राउज़र इसका उपयोग करते हैं। नीचे दिया गया keytool फ़्लो Java keystore से एक PKCS #10 अनुरोध तैयार करता है, जो सही तरीका है जब आपको ऐसे TLS सर्टिफिकेट की आवश्यकता हो जिस पर कोई Android ऐप या मोबाइल-टार्गेटेड वेबसाइट भरोसा करे।

अपने मामले के लिए सही प्रक्रिया चुनें

“Android के लिए CSR” का मतलब तीन अलग-अलग चीज़ें हो सकता है। कोई भी कमांड चलाने से पहले सुनिश्चित कर लें कि आप सही पेज पर हैं:

• ऐसे सर्वर के लिए TLS सर्टिफिकेट जिससे Android क्लाइंट संपर्क करेंगे। यह सबसे सामान्य मामला है, और इस पेज का बाकी हिस्सा इसी को कवर करता है। नीचे दिए गए keytool का उपयोग करें या हमारे CSR Generator के साथ ऑफ-सर्वर CSR जनरेट करें, फिर जारी किए गए सर्टिफिकेट को उस वेब सर्वर, API गेटवे, या MQTT ब्रोकर पर इंस्टॉल करें जिस तक आपका ऐप पहुँचता है।
• APK या AAB के लिए साइनिंग की। Android ऐप साइनिंग Java keystore में एक सेल्फ-साइन्ड RSA या EC की का उपयोग करती है: इसमें कोई पब्लिक CA शामिल नहीं होता और न ही जमा करने के लिए कोई CSR होता है। Android Studio के Build > Generate Signed Bundle / APK विज़ार्ड से (या keytool को हाथ से चलाकर) की जनरेट करें, फिर उस की को Google Play App Signing के साथ एनरोल करें। इसके लिए पब्लिक सर्टिफिकेट ऑर्डर न करें।
• MDM या EMM द्वारा प्रोविज़न किया गया डिवाइस सर्टिफिकेट। Android Enterprise SCEP, EST, या Managed Configurations API के माध्यम से मैनेज्ड डिवाइस को क्लाइंट सर्टिफिकेट जारी करता है। CSR जनरेट किया जाता है और सर्टिफिकेट को MDM द्वारा स्वचालित रूप से इंस्टॉल किया जाता है। इसमें कोई मैन्युअल keytool स्टेप नहीं होता।

यदि आपका मामला पहला वाला है, तो जारी रखें। इस फ़्लो के दो हिस्से हैं: प्राइवेट की रखने वाला एक PKCS12 keystore बनाना, फिर उस keystore से CSR एक्सपोर्ट करना।

आपको क्या चाहिए होगा

• एक Java इंस्टॉलेशन (JDK या JRE) ताकि keytool कमांड आपके PATH पर उपलब्ध हो। keytool -help से पुष्टि करें। Windows पर, Java का bin फ़ोल्डर PATH पर होना चाहिए, या आप JDK की bin डायरेक्टरी से सीधे keytool चला सकते हैं।
• वह सटीक पूरी तरह से क्वालिफाइड डोमेन नाम (FQDN) जिसे आप सुरक्षित करना चाहते हैं (उदाहरण के लिए www.yoursite.com), साथ ही उसी सर्टिफिकेट पर चाहिए कोई अन्य होस्टनाम (Subject Alternative Name सूची के लिए)।
• Distinguished Name के लिए आपके संगठन का कानूनी विवरण (देश, राज्य, शहर, संगठन का नाम)। मान बिल्कुल वैसे ही उपयोग करें जैसे वे पब्लिक बिज़नेस रिकॉर्ड्स पर दिखाई देते हैं: CA मेल न खाने पर उन्हें अस्वीकार कर देगा।

चरण 1: keystore और प्राइवेट की बनाएँ

यदि आपने पहले ही अपना CSR जनरेट कर लिया है, तो सीधे CSR जमा करें पर जाएँ और फिर Android SSL इंस्टॉलेशन निर्देशों पर जाएँ।

एक टर्मिनल (या Windows पर Command Prompt) खोलें और नीचे दिया गया keytool कमांड चलाएँ। यह PKCS12 फ़ॉर्मेट में एक नया keystore बनाता है, उसके अंदर 2048-बिट का RSA की-पेयर जनरेट करता है, और आपके द्वारा चुने गए alias के तहत की को स्टोर करता है। PKCS12, JDK 9 के बाद से डिफ़ॉल्ट keystore फ़ॉर्मेट रहा है; पुराना JKS फ़ॉर्मेट अब पदावनत (deprecated) है और नई की के लिए इससे बचना चाहिए।

keytool -genkeypair 
  -alias myalias 
  -keyalg RSA -keysize 2048 
  -storetype PKCS12 
  -keystore yoursite.p12 
  -validity 825

Windows पर, वही कमांड एक ही लाइन में इस तरह दिखेगा (ध्यान दें कि यह एक एब्सोल्यूट पाथ है ताकि आप फ़ाइल को फिर से ढूंढ सकें):

keytool -genkeypair -alias myalias -keyalg RSA -keysize 2048 -storetype PKCS12 -keystore C:certsyoursite.p12 -validity 825

फ्लैग्स क्या करते हैं:

• -alias myalias: keystore के अंदर एंट्री का नाम। ऐसा लेबल चुनें जिसे आप पहचान सकें और उसे लिख कर रखें। CSR एक्सपोर्ट करते समय और बाद में साइन किए गए सर्टिफिकेट को इम्पोर्ट करते समय आपको ठीक यही alias फिर से उपयोग करना होगा।
• -keyalg RSA -keysize 2048: 2048-बिट RSA की वर्तमान न्यूनतम मानक है जिसे हर CA स्वीकार करता है। लंबे समय तक चलने वाली की के लिए 3072 बिट का उपयोग करें, या छोटी, तेज़ की के लिए -keyalg EC -groupname secp256r1 के साथ ECDSA की जनरेट करें (हर आधुनिक CA ECDSA P-256 और P-384 के लिए इशू करता है)।
• -storetype PKCS12: आधुनिक PKCS12 keystore को फोर्स करता है। मैचिंग एक्सटेंशन .p12 (या .pfx) है।
• -keystore yoursite.p12: बनाई जाने वाली keystore फ़ाइल। इस नाम को कुछ ऐसा रखें जो आपको याद रहे, और फ़ाइल को सुरक्षित रखें: इसमें आपकी प्राइवेट की होती है।
• -validity 825: keystore के अंदर मौजूद सेल्फ-साइन्ड प्लेसहोल्डर सर्टिफिकेट कितने समय तक वैध रहेगा। CA का साइन किया हुआ सर्टिफिकेट बाद में इसकी जगह ले लेता है, इसलिए यह वैल्यू प्रोडक्शन लाइफटाइम को प्रभावित नहीं करती।

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

चरण 2: अपने संगठन का विवरण (DN) दर्ज करें

अब keytool आपसे Distinguished Name (DN) मांगता है: वे पहचान फ़ील्ड जो CSR में दिखाई देंगे। हर प्रॉम्प्ट का उत्तर अपने संगठन के सटीक कानूनी मान के साथ दें। केवल मानक ASCII कैरेक्टर का उपयोग करें: गैर-लैटिन अक्षर अनुरोध को बिगाड़ देते हैं। विराम चिह्न भी मायने रखते हैं, क्योंकि CA आपके मानों का मिलान पब्लिक बिज़नेस रिकॉर्ड्स से करता है।

• आपका पहला और अंतिम नाम क्या है? यह Common Name (CN) के लिए keytool का वाक्यांश है। वह सटीक FQDN दर्ज करें जिसे आप सुरक्षित करना चाहते हैं (उदाहरण के लिए www.yoursite.com), या एक वाइल्डकार्ड जैसे *.yoursite.com। किसी व्यक्ति का नाम दर्ज न करें।
• आपके संगठनात्मक इकाई का नाम क्या है? CA/Browser Forum ने 2022-09-01 को organizationalUnitName एट्रिब्यूट को रिटायर कर दिया, और पब्लिक CA इसे जारी किए गए सर्टिफिकेट्स से हटा देते हैं। ध्यान दें कि Enter दबाने से फ़ील्ड खाली नहीं रहती: keytool अपना डिफ़ॉल्ट मान भर देता है, इसलिए DN में OU=Unknown आ जाता है और यह मान CSR में चला जाता है। इस एट्रिब्यूट को वास्तव में छोड़ने के लिए, प्रॉम्प्ट्स को छोड़ें और -dname के साथ DN इनलाइन पास करें, स्ट्रिंग में OU को शामिल न करें।
• आपके संगठन का नाम क्या है? अपनी कंपनी का पूरा कानूनी नाम दर्ज करें, बिल्कुल वैसे ही जैसा रजिस्टर्ड है (उदाहरण के लिए Your Company LLC)। OV और EV सर्टिफिकेट्स के लिए आवश्यक; Domain Validation (DV) सर्टिफिकेट्स के लिए मान को नज़रअंदाज़ कर दिया जाता है, इसलिए कोई भी छोटा प्लेसहोल्डर काम करता है।
• आपके शहर या इलाके का नाम क्या है? पूरा शहर का नाम लिखें जहाँ आपकी कंपनी रजिस्टर्ड है (उदाहरण के लिए Seattle, न कि SEA)।
• आपके राज्य या प्रांत का नाम क्या है? पूरा राज्य या प्रांत का नाम दर्ज करें (उदाहरण के लिए California, न कि CA)।
• इस इकाई के लिए दो-अक्षर वाला देश कोड क्या है? दो-अक्षर वाला ISO 3166-1 alpha-2 कोड दर्ज करें (उदाहरण के लिए US, GB, DE)। यदि आप निश्चित नहीं हैं तो आधिकारिक ISO सूची देखें।

keytool तैयार किया गया DN प्रिंट करता है और पूछता है Is CN=…, OU=…, O=…, L=…, ST=…, C=… correct? पुष्टि करने के लिए yes टाइप करें और Enter दबाएँ। यदि आपको कोई टाइपो दिखे, तो no टाइप करें और keytool प्रॉम्प्ट्स को फिर से शुरू करेगा।

चरण 3: Subject Alternative Name के साथ CSR एक्सपोर्ट करें

अब keytool -certreq के साथ CSR एक्सपोर्ट करें। हर पब्लिक CA होस्टनाम को Subject Alternative Name (SAN) एक्सटेंशन के विरुद्ध वैलिडेट करता है, न कि Common Name के विरुद्ध (ब्राउज़र्स और आधुनिक TLS लाइब्रेरीज़ ने CN की जाँच करना वर्षों पहले बंद कर दिया था), इसलिए एक ही होस्टनाम के लिए भी SAN शामिल करें। चरण 1 में सेट किए गए उसी alias का उपयोग करें:

keytool -certreq 
  -alias myalias 
  -file certreq.csr 
  -keystore yoursite.p12 
  -ext SAN=DNS:www.yoursite.com,DNS:yoursite.com

Windows पर, वही कमांड एक ही लाइन में:

keytool -certreq -alias myalias -file certreq.csr -keystore C:certsyoursite.p12 -ext SAN=DNS:www.yoursite.com,DNS:yoursite.com

मल्टी-डोमेन सर्टिफिकेट के लिए हर होस्टनाम के लिए एक DNS: एंट्री जोड़ें (उन्हें कॉमा से अलग करें, बिना स्पेस के)। वाइल्डकार्ड के लिए, DNS:*.yoursite.com का उपयोग करें। keytool keystore पासवर्ड मांगता है, फिर CSR को आपकी वर्तमान डायरेक्टरी में certreq.csr के रूप में लिखता है।

चरण 4: CSR खोलें और इसे CA को जमा करें

certreq.csr को किसी भी टेक्स्ट एडिटर (Notepad, TextEdit, nano, vim) में खोलें। आप इसे टर्मिनल में भी प्रिंट कर सकते हैं:

cat certreq.csr

Windows Command Prompt पर:

type certreq.csr

आपको इस तरह का एक ब्लॉक दिखेगा:

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

पूरे ब्लॉक को चुनें, जिसमें BEGIN NEW CERTIFICATE REQUEST और END NEW CERTIFICATE REQUEST लाइनें शामिल हों (कुछ CA उन्हें BEGIN CERTIFICATE REQUEST / END CERTIFICATE REQUEST लेबल करते हैं: दोनों लेबल स्वीकार किए जाते हैं)। इसे कॉपी करें और अपने ऑर्डर फ़ॉर्म पर CSR फ़ील्ड में पेस्ट करें।

CSR जमा करने से पहले उसकी जाँच करें (वैकल्पिक)

CA को अनुरोध भेजने से पहले Common Name, SAN एंट्रीज़, और की साइज़ की पुष्टि कर लेना अच्छा रहता है। keytool keystore एंट्री के लिए वही जानकारी प्रिंट करता है:

keytool -printcertreq -file certreq.csr

ऑनलाइन टूल पसंद करते हैं? विषय, SAN सूची, और पब्लिक-की पैरामीटर पढ़ने के लिए अनुरोध की सामग्री को SSL Dragon के CSR Decoder में पेस्ट करें। पुष्टि करें कि Common Name उस होस्टनाम से मेल खाता है जिसे क्लाइंट उपयोग करेंगे और यह कि हर आवश्यक नाम Subject Alternative Name सूची के अंतर्गत दिखाई देता है।

क्या Android जारी किए गए सर्टिफिकेट पर भरोसा करेगा?

हाँ, किसी भी पब्लिकली ट्रस्टेड CA द्वारा साइन किए गए सर्टिफिकेट के लिए। Android रूट सर्टिफिकेट्स का एक सिस्टम स्टोर शिप करता है जो प्रमुख ब्राउज़र ट्रस्ट लिस्ट्स को प्रतिबिंबित करता है, इसलिए उन रूट्स में से किसी एक के तहत जारी किया गया सर्टिफिकेट Chrome, WebView, और सिस्टम ट्रस्ट स्टोर का उपयोग करने वाले किसी भी ऐप द्वारा भरोसा किया जाता है, बिना किसी अतिरिक्त कॉन्फ़िगरेशन के।

अगर आप सर्टिफिकेट (या किसी प्राइवेट CA रूट) को डिवाइस पर भी इंस्टॉल कर रहे हैं, तो जानने योग्य दो बातें हैं:

• Android 7 और उसके बाद के वर्ज़न पर ऐप्स द्वारा उपयोगकर्ता-इंस्टॉल किए गए CA को नज़रअंदाज़ किया जाता है। Android 7 (Nougat) के बाद से, डिफ़ॉल्ट रूप से ऐप ट्रैफ़िक द्वारा केवल सिस्टम स्टोर पर भरोसा किया जाता है, और Google Chrome भी उपयोगकर्ता-इंस्टॉल किए गए CA को नज़रअंदाज़ करता है। यदि आपके ऐप को किसी प्राइवेट CA पर भरोसा करना ज़रूरी है, तो डेवलपर को network security configuration के माध्यम से इसे शामिल करना होगा जिसमें <certificates src="user" /> हो। पब्लिक-CA सर्टिफिकेट्स को इसकी आवश्यकता नहीं होती: वे पहले से ही सिस्टम स्टोर में मौजूद होते हैं।
• किसी स्थिर आइडेंटिफ़ायर के लिए पिन करें, किसी एक सर्टिफिकेट के लिए नहीं। यदि आप अपने ऐप में सर्टिफिकेट पिनिंग लागू करते हैं, तो पब्लिक-की SPKI हैश या जारी करने वाले CA के लिए पिन करें, किसी विशेष लीफ़ सर्टिफिकेट के लिए नहीं। अन्यथा अगला रिन्यूअल उपयोगकर्ताओं को बाहर कर देगा।

अगले चरण

CA द्वारा CSR को वैलिडेट करने और आपका सर्टिफिकेट जारी करने के बाद, जारी किए गए सर्टिफिकेट को उसी keystore में (उसी alias के तहत) वापस इम्पोर्ट करें, फिर keystore को उस सर्वर पर डिप्लॉय करें जिस तक Android क्लाइंट पहुँचेंगे। डिवाइस-साइड इंस्टॉल स्टेप्स के लिए हमारी Android SSL इंस्टॉलेशन गाइड देखें, या यदि आपका बैक एंड Tomcat, JBoss, Nginx, या किसी अन्य सर्वर पर चलता है तो SSL सर्टिफिकेट कैसे इंस्टॉल करें के अंतर्गत प्लेटफ़ॉर्म-विशिष्ट इंस्टॉल गाइड देखें।