Code Signing Certificate के लिए CSR कैसे जनरेट करें

एक कोड सिग्निंग सर्टिफिकेट यह साबित करता है कि किसी सॉफ्टवेयर को किसने प्रकाशित किया है और यह दिखाता है कि साइन किए जाने के बाद कोड में कोई बदलाव नहीं किया गया है। इसे ऑर्डर करने के लिए, आप एक CSR (Certificate Signing Request) बनाते हैं, यह एन्कोडेड टेक्स्ट का ब्लॉक होता है जिसका उपयोग Certificate Authority (CA) आपकी पहचान करने और सर्टिफिकेट जारी करने के लिए करता है। कोड सिग्निंग CSR उन नियमों का पालन करते हैं जो वेबसाइट के लिए बनाए जाने वाले CSR से अलग हैं, और वे नियम 2023 में बदल गए। यह गाइड मौजूदा प्रक्रिया और उन तरीकों को समझाती है जो अभी भी लागू होते हैं।

प्राइवेट की का हार्डवेयर पर होना अनिवार्य है

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

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

• CA से पहले से कॉन्फिगर किया गया हार्डवेयर टोकन। CA की जोड़ी और CSR सीधे एक सर्टिफाइड USB टोकन पर जनरेट करता है, जारी किए गए सर्टिफिकेट को उस पर इंस्टॉल करता है, और वह टोकन आपको भेज देता है। आप उस टोकन को प्लग करकर साइन करते हैं। इस तरीके में आप स्वयं CSR जनरेट नहीं करते।
• अपना खुद का HSM या क्लाउड HSM, key attestation के साथ। अगर आपके पास पहले से एक अनुकूल Hardware Security Module (या क्लाउड HSM जैसे AWS CloudHSM, Azure Dedicated HSM, या Google Cloud HSM) है, तो आप उस डिवाइस पर की और CSR जनरेट करते हैं और एक attestation फाइल प्रदान करते हैं जो CA को यह साबित करती है कि की उस अनुकूल हार्डवेयर पर बनाई गई थी, और उसे वहां से एक्सपोर्ट नहीं किया जा सकता।

आप किस रास्ते को चुनते हैं यह ऑर्डर करते समय तय होता है। साथ-साथ तुलना के लिए, देखें कोड सिग्निंग सर्टिफिकेट डिलीवरी के तरीके।

विकल्प 1: टोकन प्लस शिपमेंट (CA CSR बनाता है)

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

इसके बजाय आपको यह करना होता है:

• CA द्वारा मांगे गए वैलिडेशन चरण पूरे करें (संगठन या पहचान सत्यापन)।
• भौतिक टोकन आने का इंतजार करें।
• टोकन ड्राइवर इंस्टॉल करें (आमतौर पर SafeNet Authentication Client) और टोकन को कनेक्ट रखते हुए अपने सॉफ्टवेयर को साइन करें।

विकल्प 2: अपने खुद के HSM या टोकन पर CSR जनरेट करें

अगर आपके पास पहले से अनुकूल हार्डवेयर है, तो आप उस डिवाइस पर की जोड़ी और CSR जनरेट करते हैं और उससे मिलती हुई attestation प्रदान करते हैं। सटीक चरण हार्डवेयर पर निर्भर करते हैं, इसलिए अपने डिवाइस के लिए गाइड या अपने प्रोवाइडर के दस्तावेज़ का पालन करें:

• YubiKey 5 FIPS: CSR निर्माण और attestation
• Luna Network Attached HSM v7.x: CSR और attestation गाइड

क्लाउड HSM (AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM) के लिए, की को HSM के भीतर जनरेट करें, CSR और प्लेटफॉर्म द्वारा तैयार की गई attestation फाइल को एक्सपोर्ट करें, और दोनों को ऑर्डर के दौरान अपने CA को जमा करें।

कुछ बातें सभी हार्डवेयर-समर्थित CSR पर लागू होती हैं:

• कम से कम 3072 बिट्स की RSA की, या समान ECDSA की का उपयोग करें, जैसा कि Baseline Requirements में निर्धारित है।
• की को non-exportable के रूप में चिह्नित करें ताकि वह डिवाइस से बाहर न जा सके।
• attestation को की के साथ ही जनरेट करें। बिना वैध attestation वाला CSR रिजेक्ट कर दिया जाएगा।

OpenSSL, Java Keytool, MMC, CertReq, और Keychain तरीके अब कहां फिट होते हैं

आपने शायद पुराने निर्देश देखे होंगे जो OpenSSL, Java keytool यूटिलिटी, Microsoft Management Console (MMC), Windows certreq कमांड, या macOS पर Keychain Access का उपयोग करके कोड सिग्निंग CSR बनाते हैं। अपने आप में, ये टूल्स सॉफ्टवेयर में एक की जनरेट करते हैं, इसलिए इस तरह बनाया गया CSR आज पब्लिकली ट्रस्टेड कोड सिग्निंग सर्टिफिकेट के लिए मान्य नहीं है।

जब आप इन्हें सॉफ्टवेयर कीस्टोर के बजाय अनुकूल हार्डवेयर की ओर निर्देशित करते हैं तो इनका अब भी उपयोग है। उदाहरण के लिए, OpenSSL PKCS#11 मॉड्यूल के माध्यम से HSM के विरुद्ध एक CSR बना सकता है, और CertReq या MMC एक ऐसा रिक्वेस्ट बना सकते हैं जो हार्डवेयर की स्टोरेज प्रोवाइडर का उपयोग करता है। इन संदर्भों का उपयोग केवल इस संदर्भ में करें, और हमेशा रिक्वेस्ट को डिवाइस से मिली attestation के साथ जोड़ें:

• OpenSSL के साथ कोड सिग्निंग CSR जनरेट करें
• Java Keystore के साथ कोड सिग्निंग CSR जनरेट करें
• CertReq के साथ कोड सिग्निंग CSR जनरेट करें
• Microsoft Management Console के साथ कोड सिग्निंग CSR जनरेट करें
• macOS Keychain Access के साथ कोड सिग्निंग CSR जनरेट करें

अपने CSR की सामग्री जांचें

CSR जमा करने से पहले, यह पुष्टि करें कि subject की जानकारी सही है। यदि आपके पास OpenSSL उपलब्ध है, तो रिक्वेस्ट को स्थानीय रूप से डिकोड करें और उसे प्लेन टेक्स्ट में पढ़ें:

openssl req -noout -text -in codesigning.csr

आउटपुट में संगठन या common name और की के आकार की जांच करें। एक स्टैंडर्ड वेबसाइट CSR चेकर यहां सही टूल नहीं है, क्योंकि कोड सिग्निंग CSR हार्डवेयर से जुड़ा होता है और उसे पब्लिक HTTPS स्कैन के बजाय attestation के माध्यम से वैलिडेट किया जाता है।

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