Java Keytool की मदद से Code Signing Certificate के लिए CSR कैसे जनरेट करें

Java Development Kit (JDK) के साथ आने वाली keytool यूटिलिटी एक Java keystore के अंदर एक की-पेयर बनाती है और उसे CSR (Certificate Signing Request) में बदल देती है, यह एन्कोडेड ब्लॉक है जिसे Certificate Authority (CA) प्रमाणपत्र जारी करने से पहले आपकी पहचान के लिए पढ़ता है। कोड साइनिंग के लिए, keytool को वैध रूप से किस काम में लाया जा सकता है, यह 1 जून, 2023 को बदल गया। यह गाइड पहले नियम बताती है, फिर उन keytool कमांड्स के बारे में बताती है जो अभी भी सही हैं: आंतरिक साइनिंग के लिए एक सॉफ्टवेयर keystore के विरुद्ध, और PKCS#11 के माध्यम से एक हार्डवेयर टोकन या HSM के विरुद्ध।

कोड साइनिंग की-ज़ हार्डवेयर पर ही जनरेट होनी चाहिए

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

इस पेज पर इसका प्रत्यक्ष असर पड़ता है। एक keystore फ़ाइल जिसे keytool आपके लैपटॉप या सर्वर पर बनाता है, चाहे वह PKCS12 हो या पुराना JKS फॉर्मेट, उसमें एक सॉफ्टवेयर की होती है। उससे जनरेट किया गया CSR किसी सार्वजनिक Certificate Authority द्वारा कोड साइनिंग प्रमाणपत्र के लिए स्वीकार नहीं किया जाता। Certificate Authorities ने इन उत्पादों के लिए ब्राउज़र-आधारित की जनरेशन और डाउनलोड करने योग्य की फ़ाइलों का समर्थन बंद कर दिया है। अब आपकी की इन दो स्थानों में से किसी एक से आती है:

• एक पहले से कॉन्फ़िगर किया गया टोकन जो CA आपको भेजता है। CA अपनी तरफ से एक प्रमाणित USB टोकन पर की-पेयर और CSR जनरेट करता है, उस पर जारी किया गया प्रमाणपत्र लोड करता है, और टोकन आपको मेल करता है। इसमें आपको कोई CSR बनाने की आवश्यकता नहीं होती।
• आपका खुद का HSM या टोकन, की एट्टेस्टेशन (key attestation) के साथ। आप डिवाइस के अंदर की जनरेट करते हैं, उससे एक CSR तैयार करते हैं, और एक एट्टेस्टेशन फ़ाइल जमा करते हैं जो CA को यह साबित करती है कि की कंप्लायंट हार्डवेयर पर बनाई गई थी और उसे निर्यात नहीं किया जा सकता। दोनों हिस्से आवश्यक हैं; वैध एट्टेस्टेशन के बिना CSR अस्वीकार कर दिया जाता है।

कौन सा रास्ता लागू होता है, यह आर्डर करते समय तय होता है। तुलना के लिए देखें code signing certificate delivery methods। यदि आपके पास पहले से ही कंप्लायंट हार्डवेयर है, तो अपने डिवाइस के लिए गाइड फॉलो करें: YubiKey 5 FIPS CSR generation and attestation या Luna Network Attached HSM v7.x CSR and attestation guide।

keytool अभी भी कहाँ काम आता है

उपरोक्त में से कोई भी बात keytool को अनुपयोगी नहीं बनाती। यह तीन स्थितियों में सही टूल बना रहता है, और केवल पहली स्थिति में ही एक ऐसा CSR मिलता है जिसे आप किसी सार्वजनिक CA को भेज सकते हैं:

• आपके टोकन या HSM के लिए एक PKCS#11 फ्रंट एंड के रूप में। keytool मूल रूप से PKCS#11 बोलता है। इसे अपने वेंडर की PKCS#11 लाइब्रेरी की ओर इशारा करें और की कभी भी डिवाइस से बाहर नहीं जाती, जबकि परिचित -certreq कमांड अभी भी CSR उत्पन्न करता है। कमांड्स नीचे हार्डवेयर सेक्शन में दिए गए हैं।
• आंतरिक या एंटरप्राइज़ साइनिंग के लिए। यदि आप अपनी संस्था की खुद की CA से इन-हाउस सॉफ्टवेयर साइन करते हैं, तो आपकी आंतरिक नीति की-स्टोरेज को नियंत्रित करती है, न कि सार्वजनिक Baseline Requirements। ऐसे मामलों में एक सॉफ्टवेयर keystore एक सामान्य विकल्प है।
• अभ्यास के लिए। यदि आपने एक बार डिस्पोज़ेबल keystore के विरुद्ध प्रॉम्प्ट्स चलाए हों, तो पहली ही कोशिश में सब्जेक्ट नेम को सही करना आसान हो जाता है।

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

keytool से CSR जनरेट करें

यदि आपने पहले ही अपना CSR बना लिया है और Certificate Authority ने प्रमाणपत्र जारी कर दिया है, तो आगे बढ़ें CA रिप्लाई इम्पोर्ट करने पर, यह वह चरण है जो चुपचाप विफल हो जाता है जब alias मेल नहीं खाता।

keytool JDK के साथ आता है, इसलिए यदि आपके पास एक नहीं है तो पहले एक मौजूदा JDK इंस्टॉल करें। JDK 25 वर्तमान लॉन्ग-टर्म सपोर्ट रिलीज़ है और JDK 26 वर्तमान शॉर्ट-टर्म रिलीज़ है। नीचे दिए गए कमांड्स JDK 17 और उसके बाद के संस्करणों पर चलते हैं, और जो वर्ज़न अंतर मायने रखते हैं उन्हें वहीं नोट किया गया है जहाँ वे आते हैं। पुष्टि करें कि टूल आपके पाथ पर है:

java -version
keytool -help
jarsigner -version

अकेला Java Runtime Environment पर्याप्त नहीं है, और काम करता हुआ keytool यह सबूत नहीं है कि आपके पास JDK है: पुराना Oracle JRE 8 keytool तो देता है लेकिन jarsigner नहीं। अभी तीनों कमांड्स चलाएँ। यदि पहले दो जवाब देते हैं और तीसरा नहीं देता, तो आप JRE पर हैं, और उस समय JDK इंस्टॉल करना उसे साइन करते समय पता चलने से कहीं आसान है।

चरण 1: keystore और की-पेयर बनाएं

इसे टर्मिनल में, या Windows पर Command Prompt या PowerShell में, उस डायरेक्टरी से चलाएं जहाँ आप keystore फ़ाइल रखना चाहते हैं:

keytool -genkeypair -alias codesign -keyalg RSA -keysize 3072 -storetype PKCS12 -keystore codesign.p12

इस कमांड में चार विवरण पुराने निर्देशों से अलग हैं, और हर एक मायने रखता है:

• -genkeypair, न कि -genkey। पुरानी -genkey स्पेलिंग अभी भी चलती है और keytool इसके बारे में कोई चेतावनी नहीं देता, लेकिन इसे सिर्फ सोर्स में एक लीगेसी alias के रूप में रखा गया है और यह अब JDK डॉक्यूमेंटेशन में कहीं भी नज़र नहीं आती। -genkeypair लिखें।
• -storetype PKCS12, न कि JKS। JKS Oracle का प्रोप्राइटरी keystore फॉर्मेट है। PKCS12 इंडस्ट्री स्टैंडर्ड है और Java 9 से JDK का डिफॉल्ट रहा है। यदि आप फिर भी JKS keystore बनाते हैं, तो keytool हर कमांड पर जो इसे छूता है चेतावनी देता है: “The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format.”
• फाइल नाम फॉर्मेट तय नहीं करता। किसी फ़ाइल का नाम keystore.jks रखने से वह JKS keystore नहीं बन जाती। keytool टाइप -storetype से लेता है, या जब आप इसे छोड़ देते हैं तो JDK की सिक्योरिटी फ़ाइल में keystore.type प्रॉपर्टी से। JDK 9 और उसके बाद वह प्रॉपर्टी pkcs12 है, इसलिए -storetype के बिना keystore.jks पर लिखने वाला कमांड चुपचाप एक भ्रामक नाम वाली PKCS12 फ़ाइल बना देता है।
• -keysize 3072, न कि 2048। Baseline Requirements कोड साइनिंग के लिए न्यूनतम RSA 3072 निर्धारित करती हैं, इसलिए 2048-बिट रिक्वेस्ट अस्वीकार कर दिया जाता है। वर्तमान JDKs RSA के लिए डिफॉल्ट रूप से 3072 का उपयोग करते हैं, लेकिन JDK 17 और उससे पहले के संस्करणों में डिफॉल्ट 2048 है, इसलिए इस विकल्प को स्पष्ट रूप से पास करें ताकि कमांड हर जगह एक जैसा व्यवहार करे।

Alias, उदाहरण में codesign, keystore के अंदर इस एंट्री का लेबल है। कुछ ऐसा चुनें जिसे आप पहचान सकें, और इसे लिख लें: बाद के हर कमांड को इसकी आवश्यकता होती है, और मेल न खाना ही वह वजह है जो आगे बताए गए प्रमाणपत्र इम्पोर्ट को बिगाड़ देता है।

एक ECDSA की भी अनुमति है। यदि आप P-256 पसंद करते हैं तो RSA विकल्पों के स्थान पर -keyalg EC -groupname secp256r1 का उपयोग करें, और अपने CA से पुष्टि करें कि आपने जो उत्पाद ऑर्डर किया है वह ECDSA का समर्थन करता है।

चरण 2: अपना डिस्टिंगुइश्ड नेम बनाने वाले प्रॉम्प्ट्स का जवाब दें

keytool दो बार एक keystore पासवर्ड मांगता है, फिर ठीक इसी क्रम में छह सवाल पूछता है। क्रम मायने रखता है: दूसरा प्रॉम्प्ट organizational unit के बारे में पूछता है, organization के बारे में नहीं, और पुरानी गाइड्स इसे गलत क्रम में सूचीबद्ध करती हैं, इसलिए जो पाठक वहाँ कंपनी का नाम टाइप करता है वह इसे नाम के गलत हिस्से में डाल देता है।

• आपका पहला और अंतिम नाम क्या है? शब्दों के बावजूद, यह Common Name (CN) बन जाता है। कोड साइनिंग प्रमाणपत्र के लिए CN वह प्रकाशक पहचान है जिसे उपयोगकर्ता देखेंगे, इसलिए अपनी संस्था का सटीक कानूनी नाम दर्ज करें, या व्यक्तिगत प्रमाणपत्र के लिए अपना पूरा कानूनी नाम। यहां डोमेन नाम न दर्ज करें।
• आपकी organizational unit का नाम क्या है? विभाग, उदाहरण के लिए IT। इसे स्किप करने के लिए Enter न दबाएं: keytool तब नाम में शाब्दिक मान Unknown लिख देता है, और OU=Unknown आपके CSR में आ जाता है। यदि आप बिल्कुल भी कोई organizational unit नहीं चाहते, तो नीचे दिया गया -dname फॉर्म इस्तेमाल करें और स्ट्रिंग में OU कंपोनेंट को छोड़ दें।
• आपकी संस्था का नाम क्या है? पंजीकृत कानूनी नाम, वैसे ही लिखा हुआ जैसे यह आधिकारिक रिकॉर्ड्स में दिखता है। CA इसे सार्वजनिक रजिस्ट्रियों के विरुद्ध सत्यापित करता है।
• आपके शहर या इलाके का नाम क्या है? पंजीकरण का शहर, पूरा लिखा हुआ।
• आपके राज्य या प्रांत का नाम क्या है? पूरा नाम, संक्षिप्त रूप नहीं।
• इस यूनिट के लिए दो-अक्षर वाला देश कोड क्या है? ISO कोड, उदाहरण के लिए US।

keytool फिर तैयार किया गया नाम वापस दिखाता है और आपसे इसकी पुष्टि करने के लिए कहता है:

Is CN=Example LLC, OU=IT, O=Example LLC, L=Miami, ST=Florida, C=US correct?
  [no]:

डिफॉल्ट जवाब no है, इसलिए Enter दबाने पर आप वापस सभी छह सवालों से गुजरेंगे। स्वीकार करने के लिए yes टाइप करें। पहले लाइन को ध्यान से पढ़ें: यह पूरा डिस्टिंगुइश्ड नेम है, केवल Common Name नहीं, और इसका हर कंपोनेंट CSR में जाता है।

PKCS12 keystore पर कोई अलग की पासवर्ड नहीं होता। पुरानी गाइड्स इस चरण को “की के लिए एक पासवर्ड दर्ज करें” से समाप्त करती हैं, जो JKS का व्यवहार है। PKCS12 keystore पर की पासवर्ड ही स्टोर पासवर्ड होता है, और यदि आप अलग मान के साथ -keypass पास करते हैं तो keytool आपको बताता है: “Different store and key passwords not supported for PKCS12 KeyStores. Ignoring user-specified -keypass value.”

प्रॉम्प्ट्स को पूरी तरह से छोड़ने के लिए, -dname के साथ पूरा नाम प्रदान करें। मान को straight quotation marks के एक जोड़े में रखें:

keytool -genkeypair -alias codesign -keyalg RSA -keysize 3072 -storetype PKCS12 -keystore codesign.p12 -dname "CN=Example LLC, OU=IT, O=Example LLC, L=Miami, ST=Florida, C=US"

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

चरण 3: CSR बनाएं

keystore में अब एक प्राइवेट की और एक अस्थायी सेल्फ-साइन्ड प्रमाणपत्र है। उस एंट्री को एक प्रमाणपत्र रिक्वेस्ट में बदलें:

keytool -certreq -alias codesign -keystore codesign.p12 -file codesign.csr

पूछे जाने पर keystore पासवर्ड दर्ज करें। यहाँ आपको -storetype की आवश्यकता नहीं है: keytool पहले से मौजूद keystore फ़ाइल का फॉर्मेट खुद पहचान लेता है। Alias वही होना चाहिए जो चरण 1 में था, क्योंकि CSR उस एंट्री की प्राइवेट की द्वारा साइन किया जाता है।

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

चरण 4: भेजने से पहले CSR जांचें

एक अस्वीकृत CSR एक सत्यापन चक्र की कीमत लेता है, इसलिए इसे डीकोड करें और पढ़कर जांचें:

keytool -printcertreq -file codesign.csr

आउटपुट में तीन चीज़ों की पुष्टि करें। Subject लाइन में आपका विवरण सही कंपोनेंट्स में सूचीबद्ध होना चाहिए, O में कानूनी संस्था का नाम और CN में प्रकाशक की पहचान के साथ। सार्वजनिक की लाइन में 3072-bit RSA key या उससे बड़ा दिखना चाहिए। सिग्नेचर एल्गोरिथम एक SHA-2 एल्गोरिथम होना चाहिए: वर्तमान JDKs एक 3072-बिट RSA रिक्वेस्ट को SHA384withRSA से साइन करते हैं और पुराने SHA256withRSA का उपयोग करते हैं, और दोनों ठीक हैं। वह एल्गोरिथम केवल यह साबित करता है कि आपके पास प्राइवेट की है, और यह वह एल्गोरिथम नहीं है जिसका उपयोग CA आपके प्रमाणपत्र को साइन करने के लिए करेगा।

आप ब्राउज़र में वही फील्ड्स पढ़ने के लिए रिक्वेस्ट को हमारे CSR decoder में भी पेस्ट कर सकते हैं।

जब आप रिक्वेस्ट सबमिट करते हैं, तो फ़ाइल को एक प्लेन-टेक्स्ट एडिटर में खोलें और सब कुछ कॉपी करें, पहली और अंतिम पंक्तियों सहित। keytool ये सटीक मार्कर्स लिखता है, हर तरफ पांच हाइफ़न्स के साथ:

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

NEW CERTIFICATE REQUEST शब्दावली keytool के आउटपुट के लिए सामान्य है और एनरोलमेंट फॉर्म्स इसे स्वीकार करते हैं। यदि आपके एडिटर ने हाइफ़न्स की किसी भी लगातार श्रृंखला को लंबे डैश से बदल दिया है, तो रिक्वेस्ट को अस्वीकार कर दिया जाएगा: मार्कर्स को साधारण हाइफ़न्स के रूप में फिर से टाइप करें या इसके बजाय फ़ाइल को कोड एडिटर से कॉपी करें।

keytool के साथ एक टोकन या HSM पर CSR जनरेट करें

यह वह रास्ता है जो एक ऐसा CSR तैयार करता है जिस पर सार्वजनिक CA कार्रवाई कर सकता है। keytool SunPKCS11 प्रोवाइडर के माध्यम से एक हार्डवेयर टोकन से बात करता है, इसलिए की-पेयर डिवाइस के अंदर बनाया जाता है और कभी भी फ़ाइल के रूप में मौजूद नहीं होता। एक छोटी कॉन्फ़िगरेशन फ़ाइल लिखकर शुरू करें, उदाहरण के लिए token.cfg, जो आपके टोकन का नाम बताए और आपके वेंडर द्वारा इंस्टॉल की गई PKCS#11 लाइब्रेरी की ओर इशारा करे:

name = token
library = /usr/local/lib/libeToken.so

वे दो पंक्तियाँ, name और library, ही आवश्यक हैं। लाइब्रेरी पाथ वेंडर-विशिष्ट है और ऑपरेटिंग सिस्टम के अनुसार अलग होता है, इसलिए इसे इस उदाहरण से नहीं बल्कि अपने टोकन दस्तावेज़ से लें। Windows पर यह सिस्टम डायरेक्टरी के अंतर्गत एक DLL होती है। बिना slot लाइन के, प्रोवाइडर डिवाइस द्वारा रिपोर्ट किए गए पहले slot से जुड़ता है, जो तब सही होता है जब केवल एक टोकन प्लग-इन हो। यदि आपके पास एक से अधिक रीडर या टोकन हैं, तो या तो slotListIndex जोड़ें उस सूची में स्थिति के साथ, शून्य से गिनते हुए, या slot जोड़ें उस न्यूमेरिक slot ID के साथ जो आपकी वेंडर यूटिलिटी प्रिंट करती है। फ़ाइल में इन दोनों में से केवल एक ही आ सकता है, और slot ID सूची की स्थिति के समान संख्या नहीं है, इसलिए slot = 0 का अनुमान न लगाएं।

डिवाइस पर जो है उसे सूचीबद्ध करें। टोकन alias प्रदान करता है, इसलिए बाकी सब कुछ करने से पहले आपको इसकी आवश्यकता होगी:

keytool -list -keystore NONE -storetype PKCS11 -providerClass sun.security.pkcs11.SunPKCS11 -providerArg token.cfg

-keystore NONE आवश्यक है जब भी keystore एक फ़ाइल न हो, और पासवर्ड प्रॉम्प्ट टोकन PIN मांग रहा होता है। keytool -providerClass और -providerArg जोड़ी के स्थान पर -addprovider SunPKCS11 -providerarg token.cfg भी स्वीकार करता है; दोनों फॉर्म काम करते हैं, और Certificate Authority दस्तावेज़ आमतौर पर पुराना वाला दिखाता है।

alias मिलने के बाद, डिवाइस पर की जनरेट करें और फिर उसके विरुद्ध CSR रिक्वेस्ट करें:

keytool -genkeypair -alias codesign -keyalg RSA -keysize 3072 -keystore NONE -storetype PKCS11 -providerClass sun.security.pkcs11.SunPKCS11 -providerArg token.cfg -dname "CN=Example LLC, O=Example LLC, L=Miami, ST=Florida, C=US"

keytool -certreq -alias codesign -keystore NONE -storetype PKCS11 -providerClass sun.security.pkcs11.SunPKCS11 -providerArg token.cfg -file codesign.csr

दो सावधानियाँ लागू होती हैं। कुछ टोकन PKCS#11 पर की जनरेशन की अनुमति नहीं देते और आपसे वेंडर की खुद की यूटिलिटी का उपयोग करने की अपेक्षा करते हैं, जो ठीक है: keytool फिर भी वेंडर टूल द्वारा जनरेट की गई की के विरुद्ध CSR बना सकता है। और keytool आपके CA द्वारा मांगी गई एट्टेस्टेशन फ़ाइल नहीं बना सकता, इसलिए उसे की के साथ ही वेंडर टूलिंग से जनरेट करें, YubiKey या Luna HSM गाइड का पालन करते हुए।

CA रिप्लाई को उसी alias में इम्पोर्ट करें

जब प्रमाणपत्र आ जाए, तो उसे उसी एंट्री में वापस जाना चाहिए जिसने CSR जनरेट किया था। इसे कहीं और इम्पोर्ट करें और keytool फिर भी सफलता की रिपोर्ट करेगा जबकि एक ऐसा keystore तैयार करेगा जो साइन नहीं कर सकता, इसलिए कुछ भी चलाने से पहले यह सेक्शन पढ़ें।

पहले CA का root और कोई भी intermediate प्रमाणपत्र इम्पोर्ट करें, हर एक अपने खुद के alias के अंतर्गत:

keytool -importcert -trustcacerts -alias caroot -file root.crt -keystore codesign.p12

keytool उस प्रमाणपत्र को प्रिंट करता है जिसे वह स्टोर करने वाला है और पूछता है Trust this certificate?, जिसमें डिफॉल्ट के रूप में no होता है, इसलिए yes टाइप करें। जवाब देने से पहले फिंगरप्रिंट को उससे मिलाकर जांचें जो आपकी Certificate Authority प्रकाशित करती है।

root इम्पोर्ट को छोड़ दें और अगला कमांड एक ऐसे मैसेज के साथ विफल हो जाता है जो कारण के बारे में कोई संकेत नहीं देता:

keytool error: java.lang.Exception: Failed to establish chain from reply

अब अपना जारी किया गया प्रमाणपत्र चरण 1 में उपयोग किए गए उसी alias का उपयोग करके इम्पोर्ट करें:

keytool -importcert -alias codesign -file codesign.crt -keystore codesign.p12

जो मैसेज आप चाहते हैं वह है Certificate reply was installed in keystore। इसका मतलब है कि keytool ने उस alias के अंतर्गत एक मौजूदा प्राइवेट की को पहचान लिया और जारी किए गए प्रमाणपत्र व उसकी चेन को उससे जोड़ दिया।

यदि आप इसके बजाय एक नया alias बनाते हैं, तो keytool फ़ाइल को स्वीकार करता है और Certificate was added to keystore प्रिंट करता है। यह सफलता जैसा दिखता है लेकिन है नहीं। keytool ने प्रमाणपत्र को एक स्टैंडअलोन विश्वसनीय एंट्री के रूप में स्टोर कर लिया है जिसके पीछे कोई प्राइवेट की नहीं है, और वह एंट्री कभी भी कुछ भी साइन नहीं कर सकती। इस बीच, मूल alias में अभी भी चरण 1 का अस्थायी सेल्फ-साइन्ड प्रमाणपत्र है। जांचें कि आपके पास इन दोनों में से कौन सा है:

keytool -list -keystore codesign.p12

आपका साइनिंग alias PrivateKeyEntry के रूप में सूचीबद्ध होना चाहिए। trustedCertEntry के रूप में दिखाया गया alias ऊपर बताई गई गलती है। इसे keytool -delete -alias wrongalias -keystore codesign.p12 से डिलीट करें और सही alias के विरुद्ध इम्पोर्ट फिर से दोहराएं। लिस्ट कमांड में -v जोड़कर पुष्टि करें कि एंट्री में अब एक सिंगल सेल्फ-साइन्ड प्रमाणपत्र के बजाय पूरी प्रमाणपत्र चेन है।

ज़्यादातर मामलों में हार्डवेयर टोकन पर इम्पोर्ट करने के लिए कुछ नहीं होता, क्योंकि CA डिवाइस को शिप करने से पहले उस पर प्रमाणपत्र लोड कर देता है। यदि आपका CA आपको अपने खुद के HSM पर जनरेट की गई की के लिए एक प्रमाणपत्र फ़ाइल भेजता है, तो पिछले सेक्शन के PKCS#11 विकल्पों के साथ वही -importcert कमांड इस्तेमाल करें।

प्रमाणपत्र के साथ एक JAR फ़ाइल साइन करें

एक Java keystore में कोड साइनिंग प्रमाणपत्र रखने का उद्देश्य jarsigner से JAR फ़ाइलों को साइन करना है, जो JDK के साथ भी आता है। सही alias के अंतर्गत प्रमाणपत्र इंस्टॉल होने के साथ:

jarsigner -keystore codesign.p12 -tsa https://your-ca-timestamp-url application.jar codesign

हमेशा अपनी Certificate Authority द्वारा प्रकाशित टाइमस्टैम्प URL के साथ -tsa पास करें। एक टाइमस्टैम्प यह रिकॉर्ड करता है कि JAR को साइन तब किया गया था जब प्रमाणपत्र अभी भी वैध था, इसलिए प्रमाणपत्र की अवधि समाप्त होने के बाद भी सिग्नेचर काम करता रहता है। इसके बिना, आपके सॉफ्टवेयर की हर कॉपी उस दिन वैलिडेट होना बंद कर देगी जिस दिन प्रमाणपत्र की अवधि समाप्त हो जाएगी।

जब की एक टोकन पर होती है, तो jarsigner को PKCS#11 की ओर उसी तरह इशारा करें जैसे keytool करता है:

jarsigner -keystore NONE -storetype PKCS11 -providerClass sun.security.pkcs11.SunPKCS11 -providerArg token.cfg -tsa https://your-ca-timestamp-url application.jar codesign

यदि टोकन में पूरी प्रमाणपत्र चेन के लिए बहुत कम जगह है, तो इसे अलग से -certchain के साथ प्रदान करें। बाद में परिणाम जांचें:

jarsigner -verify -verbose -certs application.jar

एक सफल रन साइनर के डिस्टिंगुइश्ड नेम और टाइमस्टैम्प विवरण के साथ jar verified प्रिंट करता है। वर्तमान JDKs डिफॉल्ट डाइजेस्ट एल्गोरिथम के रूप में SHA-384 का उपयोग करते हैं, इसलिए आपको -digestalg या -sigalg को मैन्युअल रूप से सेट करने की शायद ही कभी आवश्यकता होगी।

इस रिक्वेस्ट को बनाने के अन्य तरीके OpenSSL, CertReq, Microsoft Management Console, और macOS Keychain Access गाइड्स में शामिल हैं, और वही हार्डवेयर नियम इन सभी पर लागू होता है। हमारे कोड साइनिंग ट्यूटोरियल्स का पूरा सेट और कोड साइनिंग प्रमाणपत्रों के लिए CSR जनरेशन का अवलोकन भी देखें। यदि आपको कोड साइनिंग प्रमाणपत्र के बजाय वेबसाइट प्रमाणपत्र के लिए keytool CSR चाहिए, तो इसके बजाय Tomcat या JBoss गाइड फॉलो करें।

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