MMC के माध्यम से Code Signing Certificate के लिए CSR कैसे जनरेट करें

Microsoft Management Console (MMC) में Certificates snap-in किसी भी अतिरिक्त सॉफ़्टवेयर के बिना Windows मशीन पर PKCS #10 सर्टिफिकेट रिक्वेस्ट बना सकता है। यह गाइड code signing certificate के लिए उस विज़ार्ड को स्क्रीन दर स्क्रीन कवर करती है, और यह उस हिस्से से शुरू होती है जिसे अधिकांश पुराने निर्देश छोड़ देते हैं: code signing private keys के नियम 1 जून, 2023 को बदल गए, और वे तय करते हैं कि MMC रिक्वेस्ट सिरे से इस्तेमाल के लायक है भी या नहीं।

विज़ार्ड खोलने से पहले उस आवश्यकता को पढ़ें। बाकी गाइड यह मान कर चलती है कि आपको पता है आपका ऑर्डर किस रास्ते पर जाता है।

Code signing keys को हार्डवेयर पर जनरेट किया जाना चाहिए

CA/Browser Forum Code Signing Baseline Requirements के तहत, जो 1 जून, 2023 से प्रभावी है, हर सार्वजनिक रूप से trusted code signing certificate की private key को कम से कम FIPS 140-2 Level 2, Common Criteria EAL 4+, या इसके समकक्ष किसी मानक के अनुसार प्रमाणित हार्डवेयर क्रिप्टो मॉड्यूल में जनरेट, स्टोर और उपयोग किया जाना चाहिए। यह मानक सर्टिफिकेट्स (Organization Validation और Individual Validation) और Extended Validation, दोनों को कवर करता है। EV code signing पहले से ही इसी तरह काम करता था; 2023 के बदलाव ने वही नियम मानक उत्पादों तक भी बढ़ा दिया।

ये आवश्यकताएँ key को स्वयं भी तय करती हैं। RSA keys कम से कम 3072 बिट्स की होनी चाहिए, ECDSA keys को NIST P-256, P-384 या P-521 का उपयोग करना चाहिए, और SHA-1 को code signing certificates के लिए अनुमति नहीं है।

उतना ही महत्वपूर्ण यह है कि Certificate Authority को यह साबित करना होता है कि key वाकई हार्डवेयर में है, इसके लिए आवश्यकताओं में सूचीबद्ध किसी एक तरीके का उपयोग करते हुए। व्यावहारिक रूप से आपको ये तरीके मिलेंगे:

• CA आपको एक हार्डवेयर टोकन भेजता है जिसमें पहले से ही एक key pair मौजूद है जिसे CA ने उसी डिवाइस पर जनरेट किया था।
• आप निर्माता (manufacturer) के सर्टिफिकेट से रिक्वेस्ट को काउंटर-साइन करते हैं, जिसका अर्थ key attestation होता है: यह प्रमाण कि key को एक compliant डिवाइस के अंदर non-exportable तरीके से बनाया गया था।
• आप एक क्रिप्टो लाइब्रेरी और हार्डवेयर मॉड्यूल के संयोजन का उपयोग करते हैं जिसे CA निर्धारित करता है।
• आप एक IT ऑडिट, एक क्लाउड key protection सेवा की रिपोर्ट, या एक ऐसा समझौता प्रदान करते हैं जिस पर आप किसी compliant सिग्निंग सेवा के माध्यम से हस्ताक्षर करते हैं।

इनमें से किसी भी शर्त को वह रिक्वेस्ट पूरा नहीं करता जिसे MMC Microsoft Software Key Storage Provider के विरुद्ध बनाता है। वह provider key को Windows सॉफ़्टवेयर स्टोरेज में बनाता है, इसलिए परिणामी रिक्वेस्ट को सार्वजनिक रूप से trusted code signing certificate के लिए अस्वीकार कर दिया जाएगा, चाहे बाकी विज़ार्ड कैसे भी भरा गया हो। इसी के साथ Certificate Authorities ने इन उत्पादों के लिए ब्राउज़र-आधारित key generation और डाउनलोड करने योग्य .pfx डिलीवरी की पेशकश भी बंद कर दी।

यदि आपका लक्ष्य एक सार्वजनिक रूप से trusted certificate है, तो रास्ता आपके ऑर्डर के समय तय हो जाता है। या तो CA टोकन पर key जनरेट करता है और उसे आपको मेल करता है, इस स्थिति में आपको कोई CSR बनाने की आवश्यकता नहीं है, या आप अपने पहले से मौजूद हार्डवेयर पर key जनरेट करते हैं और रिक्वेस्ट के साथ एक attestation सबमिट करते हैं। code signing certificate delivery methods गाइड इन दोनों की तुलना करती है, और डिवाइस-विशिष्ट चरण यहाँ दिए गए हैं:

• YubiKey 5 FIPS: CSR generation और attestation
• Luna Network Attached HSM v7.x: CSR और attestation गाइड

MMC अभी भी कहाँ फिट बैठता है

विज़ार्ड पुराना नहीं हुआ है। यह वह provider है जिसे आप इसके अंदर चुनते हैं जो तय करता है कि key कहाँ पैदा होती है, और तीन स्थितियाँ ऐसी हैं जहाँ यह अभी भी सही टूल बना हुआ है।

एक हार्डवेयर provider द्वारा समर्थित रिक्वेस्ट। विज़ार्ड में Cryptographic Service Provider सूची मशीन पर इंस्टॉल किए गए हर provider को दिखाती है, न कि केवल Microsoft के सॉफ़्टवेयर वालों को। एक बार टोकन का ड्राइवर या स्मार्ट कार्ड मिनिड्राइवर इंस्टॉल हो जाने पर, उसका provider भी वहाँ दिखाई देता है। फर्क इस बात का है कि key pair कहाँ पैदा होता है: एक सॉफ़्टवेयर provider इसे आपके कंप्यूटर पर जनरेट करता है, जबकि एक हार्डवेयर-आधारित provider, जैसे कि स्मार्ट कार्ड या टोकन provider, डिवाइस को pair जनरेट करने का निर्देश देता है, और फिर डिवाइस ही private key को रखता है और उस तक पहुँच को नियंत्रित करता है। एक हार्डवेयर provider चुनें और MMC ऐसी key के लिए रिक्वेस्ट बनाता है जो कभी सॉफ़्टवेयर में मौजूद ही नहीं रही।

इस पर भरोसा करने से पहले दो सावधानियाँ। MMC सिर्फ एक PKCS #10 रिक्वेस्ट बनाता है और कुछ नहीं, इसलिए यह वह key attestation फ़ाइल नहीं बनाता जिसे अधिकांश Certificate Authorities इसके साथ चाहते हैं। वह डिवाइस के अपने टूलिंग से आती है। और CA तय करता है कि वह किस verification तरीके को स्वीकार करेगा, जिसमें कई CA अपनी खुद की यूटिलिटी निर्धारित करते हैं। कुछ भी जनरेट करने से पहले अपने CA से पूछें कि वह किस रास्ते का समर्थन करता है, क्योंकि गलत टूल से बनाई गई key को बाद में स्थानांतरित नहीं किया जा सकता।

एक आंतरिक या एंटरप्राइज़ CA। Baseline Requirements सार्वजनिक रूप से trusted certificates को नियंत्रित करती हैं। आपके अपने Active Directory Certificate Services CA द्वारा आंतरिक सिग्निंग के लिए जारी किया गया certificate इस दायरे से बाहर है, इसलिए आपकी अपनी पॉलिसी तय करती है कि key कैसे स्टोर की जाए, और एक सॉफ़्टवेयर provider एक वैध विकल्प है। याद रखें आपको क्या मिलता है: इस तरह साइन किया गया कोड केवल उन मशीनों पर trusted होता है जो पहले से ही आपके आंतरिक root पर भरोसा करती हैं, और बाकी हर जगह Windows पब्लिशर को अभी भी अज्ञात मानता है।

टेस्ट सिग्निंग और तैयारी। एक सॉफ़्टवेयर रिक्वेस्ट एक टेस्ट सर्टिफिकेट के लिए ठीक है, और उन सटीक subject मानों को तय करने के लिए भी जिन्हें आप बाद में अपने हार्डवेयर के विरुद्ध असली रिक्वेस्ट जनरेट करते समय दोबारा उपयोग करेंगे।

चरण 1: Certificates snap-in खोलें

Windows key + R दबाएँ, mmc टाइप करें और Enter दबाएँ। आप टास्कबार सर्च बॉक्स में mmc टाइप करके भी इसे वहाँ से खोल सकते हैं। User Account Control प्रॉम्प्ट को स्वीकार करें। एक खाली Console1 विंडो खुलती है।

File पर क्लिक करें, फिर Add/Remove Snap-in पर। Available snap-ins सूची में Certificates चुनें और Add पर क्लिक करें।

अब Windows पूछता है कि snap-in को किस certificate store को प्रबंधित करना चाहिए: My user account, Service account या Computer account। यह चुनाव code signing certificate के लिए वेब सर्वर certificate की तुलना में अधिक महत्वपूर्ण है, क्योंकि यह तय करता है कि key कहाँ रहती है और आपका सिग्निंग टूल किस store में देखता है:

• My user account key को साइन-इन किए हुए यूज़र के personal store में डालता है। यह तब सामान्य विकल्प होता है जब कोई डेवलपर इंटरैक्टिव रूप से साइन करता है, क्योंकि Microsoft का signtool डिफ़ॉल्ट रूप से वर्तमान यूज़र का My store खोलता है।
• Computer account key को मशीन store में डालता है, जो एक ऐसे बिल्ड सर्वर के लिए उपयुक्त है जहाँ सिग्निंग सर्विस अकाउंट के तहत चलती है। सिग्निंग टूल्स को वहाँ देखने के लिए बताना पड़ता है: signtool मशीन store के लिए /sm स्विच लेता है।

यदि आप My user account चुनते हैं, तो Finish पर क्लिक करें। यदि आप Computer account चुनते हैं, तो Next पर क्लिक करें, Local computer (the computer this console is running on) को चयनित रहने दें और Finish पर क्लिक करें। किसी भी स्थिति में, Add or Remove Snap-ins विंडो बंद करने के लिए OK पर क्लिक करें।

दो शॉर्टकट पूरी तरह से snap-in चरण को छोड़ देते हैं जब आपको सहेजे गए console की आवश्यकता नहीं होती: certmgr.msc सीधे वर्तमान यूज़र के certificate stores को खोलता है, और certlm.msc local computer stores को खोलता है। यदि आपने console को खुद बनाया है और वापस आने की उम्मीद रखते हैं, तो इसे बनाए रखने के लिए File फिर Save का उपयोग करें।

चरण 2: एक कस्टम रिक्वेस्ट शुरू करें

console tree में, Certificates को विस्तृत करें और Personal फ़ोल्डर पर राइट-क्लिक करें (या इसके नीचे Certificates फ़ोल्डर पर, यदि store में पहले से ही सर्टिफिकेट्स मौजूद हैं)। All Tasks चुनें, फिर Advanced Operations, फिर Create Custom Request। यदि आप पसंद करें तो यही कमांड Action मेनू पर भी मौजूद हैं।

Certificate Enrollment विज़ार्ड Before You Begin पर खुलता है। Next पर क्लिक करें।

Select Certificate Enrollment Policy पर, Custom Request शीर्षक के नीचे देखें और Proceed without enrollment policy चुनें, फिर Next पर क्लिक करें। यह Windows को Active Directory टेम्पलेट के विरुद्ध enroll करने के बजाय एक बाहरी CA के लिए एक standalone रिक्वेस्ट बनाने के लिए बताता है।

Custom request पेज में तीन सेटिंग्स हैं:

• Template. (No template) CNG key चुनें। यह एक Key Storage Provider का उपयोग करता है, जो कि आधुनिक हार्डवेयर provider जिस रूप में रजिस्टर होते हैं वही है। (No template) Legacy key पुराने CryptoAPI providers का उपयोग करता है और तभी आवश्यक है जब कोई विशिष्ट डिवाइस या एप्लिकेशन इसकी माँग करे।
• Suppress default extensions. इसे खाली छोड़ दें जब तक कि आपका इरादा केवल वही extensions भेजने का न हो जो आप हाथ से सेट करते हैं।
• Request format. PKCS #10 चुनें। इसे हर CA स्वीकार करता है। CMC उन रिक्वेस्ट के लिए है जो विशेष रूप से इसकी माँग करने वाले सिस्टम्स के लिए बनाए जाते हैं।

Next पर क्लिक करें। Certificate Information पेज पर आपको Available स्थिति के साथ Custom request लेबल वाली एक ही पंक्ति दिखाई देगी। उस पंक्ति के दाईं ओर Details तीर पर क्लिक करके इसे विस्तृत करें, फिर दिखाई देने वाले Properties बटन पर क्लिक करें। Certificate Properties डायलॉग चार टैब्स के साथ खुलता है: General, Subject, Extensions और Private Key।

चरण 3: subject विवरण दर्ज करें

General टैब पर, एक Friendly name टाइप करें और, यदि आप चाहें, एक Description। दोनों स्थानीय लेबल हैं जो आपको बाद में store में certificate ढूँढने में मदद करते हैं। इनमें से कोई भी रिक्वेस्ट का हिस्सा नहीं है, और न ही किसी को validate किया जाता है।

Subject टैब पर स्विच करें। यहीं वह पहचान बनाई जाती है जो सॉफ़्टवेयर पब्लिशर के रूप में दिखाई देगी। Subject name के तहत, Type ड्रॉप-डाउन से एक प्रविष्टि चुनें, Value बॉक्स में मिलान करने वाला टेक्स्ट टाइप करें, और Add > पर क्लिक करें। प्रत्येक प्रविष्टि दाईं ओर की सूची में चली जाती है, जहाँ Windows इसे संक्षिप्त रूप में दिखाता है (CN=, O=, OU=, L=, S=, C=)। निम्नलिखित में से प्रत्येक के लिए दोहराएँ:

• Common name (CN): आपके संगठन का पंजीकृत नाम, या व्यक्तिगत certificate के लिए व्यक्ति का पूरा कानूनी नाम। यही वह पहचान है जो यूज़र्स तब देखते हैं जब Windows पब्लिशर का नाम बताता है।
• Organization (O): वह पंजीकृत संगठन नाम जिससे certificate संबंधित है। यदि नाम में कोई प्रतीक जैसे ampersand है, तो उसे पूरा लिखें या हटा दें, क्योंकि ये अक्षर इस फील्ड में स्वीकार नहीं किए जाते। “AB & C Corporation” “AB and C Corporation” या “ABC Corporation” बन जाता है।
• Organizational unit (OU): enrollment संभालने वाला विभाग, उदाहरण के लिए IT। वैकल्पिक।
• Locality (L): वह शहर जहाँ संगठन पंजीकृत है।
• State (S): राज्य या प्रांत, पूरा लिखा हुआ। Florida लिखें, FL नहीं।
• Country (C): उस स्थान का दो-अक्षरों का ISO country code जहाँ संगठन पंजीकृत है, उदाहरण के लिए US।

ऐसे विवरण दर्ज करें जो आपके कानूनी रिकॉर्ड्स से बिल्कुल मेल खाते हों, क्योंकि CA कुछ भी जारी करने से पहले उन्हें सार्वजनिक और आधिकारिक स्रोतों के विरुद्ध validate करता है। बेमेल होना code signing ऑर्डर के अटकने का सबसे आम कारण है।

Alternative name बॉक्स को खाली छोड़ दें। Subject Alternative Names सर्वर्स को host name से पहचानते हैं, और एक code signing certificate मशीन के बजाय एक पब्लिशर की पहचान करता है, इसलिए इसमें कोई DNS प्रविष्टियाँ नहीं होतीं।

चरण 4: provider, key size और hash चुनें

Private Key टैब खोलें। इसमें कई collapsible समूह होते हैं: Cryptographic Service Provider, Key options, Select Hash Algorithm, Select Signature Format और Key permissions। इसे विस्तृत करने के लिए किसी शीर्षक पर क्लिक करें।

सबसे पहले Cryptographic Service Provider को विस्तृत करें, क्योंकि यही वह सेटिंग है जिसे Baseline Requirements चालू करती हैं। सूची मशीन पर इंस्टॉल किए गए हर provider को दिखाती है, प्रत्येक के साथ एक चेक बॉक्स। सुनिश्चित करें कि केवल वही provider चुना गया हो जिसे आप वास्तव में चाहते हैं:

• एक सार्वजनिक रूप से trusted code signing certificate के लिए, वह provider चुनें जो आपके टोकन या HSM से संबंधित है। यह इस सूची में तभी दिखाई देता है जब डिवाइस का ड्राइवर या मिनिड्राइवर इंस्टॉल हो, इसलिए पहले डिवाइस को प्लग करें और उसका सॉफ़्टवेयर इंस्टॉल करें।
• RSA, Microsoft Software Key Storage Provider सॉफ़्टवेयर विकल्प है। इसका उपयोग केवल आंतरिक CA या टेस्ट certificate के लिए करें।
• सूची में ECDSA प्रविष्टियाँ भी मौजूद हैं जैसे ECDSA_P256, Microsoft Software Key Storage Provider। इनमें से किसी एक को चुनने से पहले पुष्टि कर लें कि आपका CA code signing के लिए ECDSA का समर्थन करता है, क्योंकि हर उत्पाद ऐसा नहीं करता।

Key options को विस्तृत करें। Key size को 3072 या 4096 पर सेट करें। RSA 3072 code signing के लिए न्यूनतम है, और 2048 से बनाई गई रिक्वेस्ट अस्वीकार कर दी जाएगी। यदि जो provider आपने चुना है उसके लिए ड्रॉप-डाउन में 3072 उपलब्ध नहीं है, तो 4096 का उपयोग करें।

उसी समूह में, Make private key exportable को अनचेक ही रहने दें। यह पुराने MMC निर्देशों में सबसे महत्वपूर्ण सुधार है। एक exportable key को मशीन से .pfx फ़ाइल के रूप में कॉपी किया जा सकता है, जो ठीक वही है जिसे रोकने के लिए हार्डवेयर आवश्यकता बनाई गई है, और attestation रास्ता स्पष्ट रूप से प्रमाणित करता है कि key non-exportable तरीके से बनाई गई थी। इसे चेक करने का एकमात्र मामला एक आंतरिक सिग्निंग सेटअप है जहाँ आपको certificate और key को दूसरी मशीन पर ले जाना ही पड़ता है, और तब भी यह key को कमजोर करता है। Allow private key to be archived को भी अनचेक छोड़ दें। Strong private key protection वैकल्पिक है और यह Windows को हर बार key उपयोग होने पर प्रॉम्प्ट करने के लिए मजबूर करता है, जो साझा वर्कस्टेशन पर सिग्निंग key के लिए उचित है।

Select Hash Algorithm को विस्तृत करें और Hash Algorithm को sha256 पर सेट करें। code signing certificates के लिए SHA-1 की अनुमति नहीं है।

Extensions टैब देखने लायक है अगर आप किसी आंतरिक CA के विरुद्ध enroll कर रहे हैं। Key usage को विस्तृत करें और Digital signature जोड़ें, फिर Extended Key Usage (application policies) को विस्तृत करें और Code Signing जोड़ें। एक सार्वजनिक CA certificate को आपकी रिक्वेस्ट के extensions से नहीं बल्कि आपके द्वारा ऑर्डर किए गए उत्पाद से बनाता है, इसलिए एक सार्वजनिक ऑर्डर के लिए यह टैब कुछ नहीं बदलता। एक आंतरिक CA इसे मान सकता है।

Certificate Properties बंद करने के लिए OK पर क्लिक करें, फिर Next।

चरण 5: रिक्वेस्ट सेव करें

विज़ार्ड पूछता है Where do you want to save the offline request? Browse पर क्लिक करें, एक ऐसा फ़ोल्डर चुनें जिसे आप नियंत्रित करते हों, फ़ाइल को codesigning.req जैसा नाम दें और पुष्टि करें। हमेशा फ़ोल्डर तक ब्राउज़ करें बजाय इसके कि बिना पथ के फ़ाइल नाम टाइप करें: बिना पथ के रिक्वेस्ट उसी फ़ोल्डर में जाकर उतरती है जहाँ से console चल रहा होता है, जो शायद ही कभी वह जगह हो जहाँ आप चाहते हैं और बाद में ढूँढना मुश्किल होता है।

File format के तहत, Base 64 को चयनित रहने दें। यही वह टेक्स्ट रूप है जिसे CAs enrollment बॉक्स में पेस्ट करते हैं। Binary raw DER लिखता है, जिसे अधिकांश ऑर्डर फ़ॉर्म अस्वीकार कर देते हैं। Finish पर क्लिक करें।

फ़ाइल को किसी भी plain-text editor में खोलें, जैसे Notepad, और पहली और आखिरी पंक्तियों सहित पूरा ब्लॉक कॉपी करें:

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIEbDCCA1QCAQAwZDELMAkGA1UEBhMCVVMx...
...base64 encoded request...
-----END NEW CERTIFICATE REQUEST-----

Windows enrollment टूल्स सामान्यतः ऊपर दिखाई गई लंबी वर्डिंग लिखते हैं, जिसमें marker लाइनों में NEW शब्द होता है, जबकि OpenSSL BEGIN CERTIFICATE REQUEST और END CERTIFICATE REQUEST लिखता है। यदि आपकी फ़ाइल छोटा रूप उपयोग करती है, तो कुछ भी गलत नहीं है: सामग्री वही PKCS #10 रिक्वेस्ट है और Certificate Authorities दोनों रूपों को स्वीकार करती हैं। जो आप देखते हैं उसे बिल्कुल वैसे ही कॉपी करें और marker लाइनों को फिर से न लिखें।

एक चीज़ जो विज़ार्ड नहीं बनाता वह है कोई private key फ़ाइल जिसे आप सेव या कॉपी कर सकें, और पुराने गाइड जो आपको public और private key फ़ाइलों को सुरक्षित रखने के लिए कहते हैं, वे एक अलग टूल का वर्णन कर रहे हैं। MMC नई private key को Windows key store के अंदर ही रखता है, उस अकाउंट के तहत जो आपने चरण 1 में चुना था, केवल उसी कंप्यूटर पर। लंबित रिक्वेस्ट सामान्यतः snap-in में Certificate Enrollment Requests के तहत दिखाई देती है। इसके तीन परिणाम होते हैं:

• जब तक आप जारी होने का इंतज़ार कर रहे हों, लंबित रिक्वेस्ट को न हटाएँ। इसे हटाने से key नष्ट हो जाती है, और जारी किया गया certificate तब बेकार हो जाएगा।
• ऑर्डर को उसी कंप्यूटर पर, उसी अकाउंट संदर्भ में पूरा करें। यूज़र store में जनरेट की गई रिक्वेस्ट को मशीन store में पूरा नहीं किया जा सकता, या इसके विपरीत।
• रिक्वेस्ट जनरेट करने और certificate इंस्टॉल करने के बीच मशीन को दोबारा न बनाएँ या re-image न करें।

चरण 6: सबमिट करने से पहले रिक्वेस्ट जाँचें

बनाए जाने के बाद रिक्वेस्ट को संपादित नहीं किया जा सकता, इसलिए validation शुरू होने के बाद टाइपो खोजने के बजाय इसे अभी जाँच लें। Windows बिना किसी अतिरिक्त सॉफ़्टवेयर के इसे वापस पढ़ सकता है। फ़ाइल रखने वाले फ़ोल्डर में एक Command Prompt खोलें और चलाएँ:

certutil -dump codesigning.req

यदि OpenSSL इंस्टॉल है, तो यह उसी फ़ाइल को पढ़ता है और रिक्वेस्ट signature की भी जाँच करता है:

openssl req -noout -text -verify -in codesigning.req

आउटपुट में चार चीज़ों की पुष्टि करें: subject में country, state, locality, organization और common name बिल्कुल वैसे ही सूचीबद्ध हों जैसा आप चाहते हैं; public key 3072 बिट्स या अधिक हो, या एक स्वीकृत ECDSA curve हो; signature algorithm SHA-256 हो; और, OpenSSL कमांड के साथ, एक verify OK लाइन दिखाई दे, जो पुष्टि करती है कि रिक्वेस्ट पर उसकी मिलान करने वाली private key से हस्ताक्षर किए गए थे। आप इसे ब्राउज़र में पढ़ने के लिए ब्लॉक को CSR decoder में भी पेस्ट कर सकते हैं।

यदि कुछ भी गलत है, तो चरण 2 से एक नई रिक्वेस्ट जनरेट करें। मशीन पर उपलब्ध providers देखने के लिए, जिसमें आपके इंस्टॉल किए गए किसी भी हार्डवेयर provider शामिल हैं, चलाएँ:

certutil -csplist

चरण 7: उसी मशीन पर जारी किए गए certificate को इंस्टॉल करें

अपने certificate ऑर्डर के दौरान Base 64 ब्लॉक सबमिट करें, CA जिस validation की माँग करता है उसे पूरा करें, और आने पर जारी किया गया certificate डाउनलोड करें। क्योंकि private key Windows key store में ही रही, certificate को उपयोग योग्य बनने के लिए उसी store में वापस आना होगा।

उसी snap-in में, Personal पर राइट-क्लिक करें, All Tasks चुनें, फिर Import, और विज़ार्ड को फ़ाइल की ओर इंगित करें। Windows certificate को उस key से मिलाता है जो उसने रिक्वेस्ट से रखी थी, और Certificate Enrollment Requests के तहत लंबित प्रविष्टि गायब हो जाती है। इसके बाद certificate खोलें और जाँचें कि General टैब कहता है कि आपके पास इस certificate से मेल खाने वाली private key है। यदि यह पंक्ति गायब है, तो pairing नहीं हुई, और आप certificate के serial number के साथ इसे फिर से जोड़ सकते हैं:

certutil -repairstore My <serial-number>

यदि certificate वर्तमान यूज़र से संबंधित है न कि मशीन से, तो -user स्विच जोड़ें:

certutil -user -repairstore My <serial-number>

वहाँ से आपका सिग्निंग टूल certificate को store से चुन लेता है। चरण 1 में आपने जो store चुना था उसे याद रखें: signtool वर्तमान यूज़र के My store को पढ़ता है जब तक कि आप मशीन store के लिए /sm पास न करें।

वही रिक्वेस्ट बनाने के अन्य तरीके CertReq, OpenSSL, Java Keystore और macOS Keychain Access गाइड में कवर किए गए हैं। आपको व्यापक code signing ट्यूटोरियल्स या CSR जनरेट करने के अन्य तरीके भी उपयोगी लग सकते हैं।

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