macOS पर Keychain Access का उपयोग करके Code Signing Certificate के लिए CSR कैसे जनरेट करें

Keychain Access अभी भी हर Mac पर मौजूद है, और इसका Certificate Assistant अभी भी सर्टिफिकेट साइनिंग रिक्वेस्ट जनरेट करता है। वह रिक्वेस्ट कोड साइनिंग के लिए किसी काम की है या नहीं, यह पूरी तरह इस बात पर निर्भर करता है कि आप कौन सा सर्टिफिकेट ऑर्डर कर रहे हैं। एक Apple Developer ID सर्टिफिकेट के लिए, जो आपको Mac App Store के बाहर Mac सॉफ्टवेयर वितरित करने देता है, Keychain Access सही टूल है और नीचे दिए गए स्टेप्स अभी भी लागू हैं। किसी सार्वजनिक Certificate Authority से मिलने वाले कमर्शियल कोड साइनिंग सर्टिफिकेट के लिए, जिस तरह का उपयोग Windows executables, इंस्टॉलर, ड्राइवर और Java एप्लिकेशन साइन करने के लिए होता है, Keychain Access में जनरेट की गई रिक्वेस्ट 1 जून, 2023 से स्वीकार नहीं की जाती, क्योंकि अब प्राइवेट की को हार्डवेयर पर ही बनाना अनिवार्य है।

पहले यह तय करें कि आपको इन दोनों में से कौन सा चाहिए, फिर उसी से मेल खाता सेक्शन फॉलो करें।

आप असल में कौन सा कोड साइनिंग सर्टिफिकेट ले रहे हैं?

दोनों प्रोडक्ट्स को कोड साइनिंग सर्टिफिकेट कहा जाता है और दोनों यह साबित करते हैं कि सॉफ्टवेयर किसने पब्लिश किया है, लेकिन ये अलग-अलग जारीकर्ताओं से आते हैं और अलग-अलग नियमों का पालन करते हैं। पाठक इस पेज पर इसलिए आते हैं क्योंकि Apple और सार्वजनिक Certificate Authorities दो अलग चीज़ों के लिए एक जैसे शब्दों का इस्तेमाल करते हैं।

• Apple Developer ID सर्टिफिकेट। यह Apple द्वारा, अपनी खुद की Developer ID Certification Authority के तहत, Apple Developer Program के सदस्यों को जारी किया जाता है। यह उन Mac ऐप्स, प्लग-इन्स और इंस्टॉलर पैकेजेस को साइन करता है जिन्हें आप खुद वितरित करते हैं, जिससे macOS Gatekeeper आपको एक पहचाने गए डेवलपर के रूप में मान्यता देता है। की-पेयर आपके Mac पर जनरेट होती है और आपकी लॉगिन keychain में रहती है, और रिक्वेस्ट आप Keychain Access में बनाते हैं।
• सार्वजनिक रूप से भरोसेमंद कोड साइनिंग सर्टिफिकेट। यह Sectigo, DigiCert या GlobalSign जैसी किसी सार्वजनिक Certificate Authority से खरीदा जाता है। यह Windows executables, MSI इंस्टॉलर, ड्राइवर, PowerShell स्क्रिप्ट और Java एप्लिकेशन को साइन करता है। यह CA/Browser Forum के Code Signing Baseline Requirements के अंतर्गत आता है, जिनके अनुसार प्राइवेट की को सर्टिफाइड हार्डवेयर पर ही जनरेट और स्टोर किया जाना ज़रूरी है, इसलिए यहां Keychain Access के लिए कोई काम नहीं बचता।

संक्षेप में निर्णय का नियम यह है: अगर जो सॉफ्टवेयर आप साइन कर रहे हैं वह macOS पर चलता है और आप उसे Mac App Store के बाहर शिप कर रहे हैं, तो आपको Developer ID सर्टिफिकेट चाहिए। अगर आप Windows के लिए कुछ भी, या किसी Java एप्लिकेशन को साइन कर रहे हैं, तो आपको कमर्शियल कोड साइनिंग सर्टिफिकेट चाहिए, भले ही आप उसे Mac पर बनाएं। इनमें से कोई भी SSL/TLS सर्टिफिकेट नहीं है। यदि आप वास्तव में Mac सर्वर पर HTTPS चाहते हैं, तो इसके बजाय macOS Servers पर CSR कैसे जनरेट करें देखें।

कमर्शियल रास्ता: Keychain का तरीका अब क्यों लागू नहीं होता

1 जून, 2023 से, CA/Browser Forum Code Signing Baseline Requirements के अनुसार हर सार्वजनिक रूप से भरोसेमंद कोड साइनिंग सर्टिफिकेट, चाहे वह स्टैंडर्ड (OV) हो या Extended Validation (EV), की प्राइवेट की को एक ऐसे हार्डवेयर क्रिप्टो मॉड्यूल में जनरेट और स्टोर करना ज़रूरी है जो FIPS 140-2 Level 2, Common Criteria EAL4+, या किसी समकक्ष मानक को पूरा करता हो, और जो एक्सपोर्ट न किया जा सके। EV कोड साइनिंग के लिए हमेशा से हार्डवेयर ज़रूरी था; 2023 के बदलाव ने यही नियम स्टैंडर्ड सर्टिफिकेट्स पर भी लागू कर दिया।

Certificate Assistant द्वारा बनाई गई की इस टेस्ट में डिज़ाइन के हिसाब से ही फेल हो जाती है, तीन अलग-अलग कारणों से:

• की एक्सपोर्ट करने योग्य सॉफ्टवेयर की सामग्री है। यह आपकी लॉगिन keychain में लिखी जाती है, और आप उसे चुनकर .p12 फ़ाइल के रूप में एक्सपोर्ट कर सकते हैं। यह पोर्टेबिलिटी Apple डेवलपमेंट के लिए सुविधाजनक है, लेकिन ठीक वही गुण है जिसे हटाने के लिए हार्डवेयर आवश्यकता बनाई गई है।
• की का साइज़ मेल नहीं खाता। Baseline Requirements कोड साइनिंग के लिए न्यूनतम RSA 3072 bits तय करते हैं, और Certificate Assistant के Key Size मेन्यू में 3072 का विकल्प है ही नहीं।
• रिक्वेस्ट में लगभग कोई पहचान नहीं होती। Certificate Assistant केवल Common Name और ईमेल पते मांगता है। यहां संगठन (organization), लोकैलिटी, स्टेट या देश जैसी जानकारी दर्ज करने की कोई जगह नहीं है, जिसे एक Certificate Authority ऑर्गेनाइज़ेशन-वैलिडेटेड कोड साइनिंग सर्टिफिकेट के लिए वेरिफाई करती है।

इससे सार्वजनिक रूप से भरोसेमंद कोड साइनिंग सर्टिफिकेट पाने के दो ही मान्य तरीके बचते हैं, और आप कौन सा इस्तेमाल करेंगे यह ऑर्डर करते समय तय होता है:

• टोकन के साथ शिपमेंट। Certificate Authority अपनी तरफ से एक सर्टिफाइड USB टोकन पर की-पेयर और रिक्वेस्ट जनरेट करती है, जारी किया गया सर्टिफिकेट उस पर लोड करती है, और वह टोकन आपको मेल कर देती है। आपको कहीं भी CSR बनाने या पेस्ट करने की ज़रूरत नहीं होती। देखें कौन सा कोड साइनिंग सर्टिफिकेट डिलीवरी तरीका चुनें।
• आपका अपना हार्डवेयर टोकन, HSM या क्लाउड HSM, अटेस्टेशन के साथ। आप डिवाइस के अंदर की जनरेट करते हैं, वहीं रिक्वेस्ट बनाते हैं, और एक अटेस्टेशन फ़ाइल जमा करते हैं जो यह साबित करती है कि की को अनुरूप (compliant) हार्डवेयर पर बनाया गया था और उसे एक्सपोर्ट नहीं किया जा सकता। YubiKey 5 FIPS CSR जनरेशन और अटेस्टेशन गाइड या Luna Network Attached HSM v7.x CSR और अटेस्टेशन गाइड, या अपने HSM विक्रेता के दस्तावेज़ीकरण को फॉलो करें।

एक और बदलाव पहले ही लागू हो चुका है: ballot CSC-31 ने सार्वजनिक रूप से भरोसेमंद कोड साइनिंग सर्टिफिकेट्स की अधिकतम वैधता को 39 महीनों से घटाकर 460 दिन कर दिया है, जो 1 मार्च, 2026 से जारी होने वाले सर्टिफिकेट्स पर लागू होगा, इसलिए अब रिन्यूअल लगभग हर 15 महीने में आएंगे। व्यापक जानकारी के लिए देखें कोड साइनिंग सर्टिफिकेट के लिए CSR कैसे जनरेट करें और इसी गाइड का OpenSSL वर्ज़न।

Apple Developer ID सर्टिफिकेट के लिए Keychain Access में CSR जनरेट करें

अगर आपने पहले ही एक .certSigningRequest फ़ाइल सेव कर ली है, तो सीधे अपने डेवलपर अकाउंट में उसे सबमिट करने वाले हिस्से पर जाएं।

शुरू करने से पहले दो बातें जांच लें। आपके पास Apple Developer Program की सदस्यता होनी चाहिए, और Apple को Developer ID सर्टिफिकेट बनाने के लिए Account Holder भूमिका की आवश्यकता है। आपको प्रति टीम अधिकतम पांच Developer ID Application सर्टिफिकेट और पांच Developer ID Installer सर्टिफिकेट की अनुमति है। पोर्टल हर बार सर्टिफिकेट बनाते समय आपसे एक रिक्वेस्ट अपलोड करने के लिए कहता है, इसलिए यह प्रक्रिया हर सर्टिफिकेट के लिए एक बार करें।

स्टेप 1: Keychain Access खोलें और रिक्वेस्ट शुरू करें

Keychain Access अब वहां नहीं है जहां ज़्यादातर ट्यूटोरियल बताते हैं। macOS Sonoma तक यह Applications > Utilities में होता था। macOS Sequoia से आगे, Apple ने इसे /System/Library/CoreServices/Applications/ में डाल दिया है, जो एक सिस्टम फ़ोल्डर है जिसे Finder Applications ब्राउज़ करते समय नहीं दिखाता, इसलिए अब Utilities के अंदर देखने पर कुछ नहीं मिलेगा। इसे खोलने के सबसे तेज़ तरीके हैं Spotlight (Command-Space दबाएं और Keychain Access टाइप करें), या Terminal में एक ही कमांड:

open "/System/Library/CoreServices/Applications/Keychain Access.app"

ऐप खुलने के बाद, मेन्यू बार में Keychain Access > Certificate Assistant > Request a Certificate From a Certificate Authority चुनें।

ऐसा करने से पहले, आइटम लिस्ट के किसी खाली हिस्से पर क्लिक करें ताकि कुछ भी चयनित न हो। अगर कोई की या सर्टिफिकेट हाइलाइट है, तो मेन्यू आइटम बदलकर Request a Certificate From a Certificate Authority With हो जाता है, उसके बाद उस आइटम का नाम आता है, और यह नई की-पेयर बनाने के बजाय मौजूदा की के आधार पर रिक्वेस्ट बनाता है। यह तब उपयोगी है जब आप जानबूझकर किसी की को दोबारा इस्तेमाल करना चाहते हैं, और तब भ्रमित करने वाला है जब आप ऐसा नहीं चाहते।

स्टेप 2: Certificate Information विंडो भरें

Certificate Assistant एक पैनल पर खुलता है जिसका शीर्षक Certificate Information है। यह बहुत कम जानकारी मांगता है:

• User Email Address: आपके Apple Developer अकाउंट पर मौजूद ईमेल पता।
• Common Name: की-पेयर के लिए एक लेबल, उदाहरण के लिए Developer ID Application Key। यह वह नाम नहीं है जो अंततः सर्टिफिकेट में दिखेगा। Apple जारी किए गए सर्टिफिकेट का सब्जेक्ट आपकी टीम के आधार पर बनाता है, इस फॉर्मेट में Developer ID Application: Your Team Name (TEAMID), इसलिए इस फील्ड को अपने खुद के संदर्भ के रूप में लें।
• CA Email Address: इसे खाली छोड़ दें। यह केवल दूसरे डिलीवरी विकल्प के लिए इस्तेमाल होता है।
• Request is: Saved to disk चुनें, Emailed to the CA नहीं। Apple का डेवलपर पोर्टल एक अपलोड की गई फ़ाइल लेता है।

अगर आप की का साइज़ या एल्गोरिद्म भी चुनना चाहते हैं, तो यहां Let me specify key pair information पर टिक करें। फिर Continue पर क्लिक करें।

स्टेप 3: यदि ज़रूरत हो तो की-पेयर सेटिंग्स चुनें

यह पैनल केवल तभी दिखता है जब आपने स्टेप 2 में बॉक्स को टिक किया हो, और Developer ID सर्टिफिकेट के लिए आप आमतौर पर इसे छोड़ सकते हैं। डिफ़ॉल्ट सेटिंग्स RSA पर 2048 bits हैं, जो Apple के अपने निर्देशों में भी इस्तेमाल होती हैं। RSA चयनित होने पर, Key Size मेन्यू में 2048, 4096 और 8192 bits का विकल्प मिलता है। Algorithm मेन्यू में RSA और ECC का विकल्प है, और ECC पर स्विच करने पर उन साइज़ों की जगह 256, 384 और 521 bits आ जाते हैं। एल्गोरिद्म को RSA पर ही छोड़ें, जब तक कि जिस सेवा में आप एनरोल कर रहे हैं वह विशेष रूप से एक इलिप्टिक कर्व की न मांगे।

इस गाइड के पहले वर्ज़न में यहां कम से कम 3072 bits चुनने के लिए कहा गया था। वह आंकड़ा कमर्शियल कोड साइनिंग सर्टिफिकेट्स के लिए CA/Browser Forum का न्यूनतम मानक है। यह Developer ID पर लागू नहीं होता, और यह इस मेन्यू में उपलब्ध ही नहीं है, इसलिए चुनने के लिए कुछ भी नहीं है। Continue पर क्लिक करें।

स्टेप 4: रिक्वेस्ट सेव करें और जांचें कि उसमें क्या है

फ़ाइल कहां सेव करनी है यह चुनें और Save पर क्लिक करें। आपको .certSigningRequest एक्सटेंशन वाली एक फ़ाइल मिलती है, और Certificate Assistant मैचिंग की-पेयर को आपकी लॉगिन keychain में भी डाल देता है। यह फ़ाइल खुद एक सामान्य PEM टेक्स्ट है, इसलिए आप इसे TextEdit में खोलकर पढ़ सकते हैं, हालांकि एन्कोडेड ब्लॉक अपने आप में आपको ज़्यादा कुछ नहीं बताएगा।

इसे अपलोड करने से पहले विवरण की पुष्टि करने के लिए, Terminal में रिक्वेस्ट को डिकोड करें। यह macOS पर पहले से मौजूद openssl कमांड के साथ काम करता है, जो असल में OpenSSL नहीं बल्कि LibreSSL है, इसलिए कुछ भी इंस्टॉल करने की ज़रूरत नहीं है:

openssl req -noout -text -in CertificateSigningRequest.certSigningRequest

आउटपुट में तीन चीज़ें जांचें: Subject लाइन में आपके द्वारा टाइप किया गया Common Name और ईमेल पता दिखना चाहिए, पब्लिक की लाइन में 2048 bit (या जो भी साइज़ आपने चुना हो) दिखना चाहिए, और सिग्नेचर एल्गोरिद्म SHA-256 होना चाहिए। अगर आप Terminal का इस्तेमाल नहीं करना चाहते, तो उन्हीं फील्ड्स को पढ़ने के लिए फ़ाइल की सामग्री को हमारे CSR डिकोडर में पेस्ट करें।

स्टेप 5: रिक्वेस्ट सबमिट करें और सर्टिफिकेट इंस्टॉल करें

अपने Apple Developer अकाउंट में साइन इन करें और Certificates, Identifiers & Profiles खोलें। साइडबार में Certificates पर क्लिक करें, फिर ऐड बटन पर, और Software के अंतर्गत Developer ID चुनें। अपनी ज़रूरत के अनुसार प्रकार चुनें:

• Developer ID Application एक Mac ऐप, प्लग-इन या बंडल को साइन करता है।
• Developer ID Installer आपके साइन किए गए ऐप वाले Mac इंस्टॉलर पैकेज को साइन करता है।

Continue पर क्लिक करें, फिर Choose File पर, अपनी .certSigningRequest फ़ाइल चुनें, फिर से Continue पर क्लिक करें, और Download पर क्लिक करें। Apple आपको .cer एक्सटेंशन वाली एक सर्टिफिकेट फ़ाइल देता है। इसे इंस्टॉल करने के लिए डबल-क्लिक करें, और यह Keychain Access में My Certificates के अंतर्गत दिखाई देगा, जो स्टेप 4 में बनाई गई प्राइवेट की के साथ जोड़ा गया होगा।

सर्टिफिकेट से साइन करना macOS की जांच का केवल आधा हिस्सा है। Gatekeeper यह उम्मीद करता है कि Mac App Store के बाहर से डाउनलोड किया गया सॉफ्टवेयर Developer ID सर्टिफिकेट से साइन और Apple द्वारा नोटराइज़ किया गया हो, इसलिए वितरित करने से पहले साइन की गई बिल्ड को नोटराइज़ेशन के लिए सबमिट करें। नोटराइज़ेशन सिग्नेचर की जगह नहीं लेता, यह उसके ऊपर काम करता है।

प्राइवेट की ढूंढें और उसका बैकअप लें

Certificate Assistant द्वारा जनरेट की गई प्राइवेट की के बिना सर्टिफिकेट बेकार है, और वह की तब तक ठीक एक ही जगह मौजूद रहती है जब तक आप उसे कॉपी न करें। इसे ढूंढने के लिए, Keychain Access खोलें, login keychain चुनें, फिर Keys श्रेणी, और स्टेप 2 में आपने जो Common Name टाइप किया था उसे खोजें। उस नाम के तहत आपको दो एंट्रीज़ दिखेंगी, एक पब्लिक की और एक प्राइवेट की। ध्यान दें कि पब्लिक की आपका CSR नहीं है: CSR वह .certSigningRequest फ़ाइल है जिसे आपने डिस्क पर सेव किया था।

एक बार .cer फ़ाइल इंस्टॉल हो जाने के बाद, इसके बजाय My Certificates के अंतर्गत देखें। वहां सर्टिफिकेट और उसकी प्राइवेट की एक ही एंट्री के रूप में दिखाई देती हैं, जो वह साइनिंग आइडेंटिटी है जिसका उपयोग codesign, Xcode और आपकी बिल्ड स्क्रिप्ट्स करती हैं। उस आइडेंटिटी को किसी दूसरे Mac या बिल्ड सर्वर पर ले जाने के लिए, एंट्री पर राइट-क्लिक करें और Export चुनें, जिससे एक .p12 फ़ाइल बनती है जो आपके द्वारा सेट किए गए पासवर्ड से सुरक्षित होती है। उस फ़ाइल को उसी तरह सुरक्षित रखें जैसे आप किसी भी साइनिंग की को रखते हैं, क्योंकि जिसके पास वह फ़ाइल और पासवर्ड दोनों हैं वह आपके नाम पर सॉफ्टवेयर साइन कर सकता है।

ज़रूरत पड़ने से पहले ही इसका बैकअप ले लें। Developer ID सर्टिफिकेट पांच साल के लिए वैध होते हैं और इन्हें रिन्यू नहीं किया जा सकता: जब कोई एक्सपायर हो जाता है तो आप उसकी जगह एक नया बनाते हैं। अगर आप प्राइवेट की खो देते हैं, तो सर्टिफिकेट फिर कभी इस्तेमाल नहीं किया जा सकता और आपको दूसरा बनाना पड़ता है, जो आपके पांच Developer ID Application या पांच Developer ID Installer स्लॉट्स में से एक इस्तेमाल कर लेता है। सफाई के लिए मृत सर्टिफिकेट को रद्द (revoke) करने के लालच में न पड़ें। Apple स्पष्ट रूप से कहता है कि रद्द किए गए Developer ID सर्टिफिकेट से साइन किया गया ऐप इंस्टॉल नहीं होगा, और उस उपयोगकर्ता के लिए भी लॉन्च नहीं होगा जिसके पास वह पहले से मौजूद है, इसलिए रद्द करने से वहां मौजूद हर कॉपी टूट जाएगी। रद्द तभी करें जब की वाकई चोरी हुई हो, और उस टूट-फूट के लिए तैयार रहकर आगे बढ़ें।

जो लोग कमर्शियल सर्टिफिकेट के लिए यहां आए हैं, उनके लिए एक ज़रूरी सफाई: अगर आपने पहले ही किसी सार्वजनिक Certificate Authority ऑर्डर के लिए Keychain Access में की-पेयर बना लिया है, तो उसका इस्तेमाल नहीं किया जा सकता और कोई भी CA उसे स्वीकार नहीं करेगी। अगर आप इसे वैसे ही छोड़ देते हैं तो कुछ नहीं टूटेगा, लेकिन एक्सपोर्ट करने योग्य साइनिंग की सामग्री को keychain में रखे रहने का कोई खास कारण नहीं है। Keys के अंतर्गत पब्लिक और प्राइवेट दोनों की चुनें और उन्हें डिलीट करें, फिर इसके बजाय किसी टोकन या HSM के ज़रिए ऑर्डर करें।

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

संबंधित जानकारी के लिए, हमारे कोड साइनिंग ट्यूटोरियल्स, CSR जनरेट करने के अन्य तरीके, और कोड साइनिंग सर्टिफिकेट का उपयोग करके EXE फ़ाइल कैसे साइन करें देखें।