JBoss सर्वर पर CSR कैसे जनरेट करें

यह ट्यूटोरियल आपको दिखाता है Java keytool यूटिलिटी का उपयोग करके JBoss EAP और WildFly पर CSR (Certificate Signing Request) कैसे जेनरेट करें। प्रक्रिया दो कमांड्स में होती है: पहले keytool -genkeypair एक चुने हुए alias के अंतर्गत एक keystore और एक प्राइवेट key बनाता है, फिर keytool -certreq मैचिंग CSR को उन Subject Alternative Names के साथ एक्सपोर्ट करता है जिन्हें CA जारी करेगा। बाद में जब आप साइन किया गया सर्टिफिकेट इम्पोर्ट करते हैं तो उसी alias का पुन: उपयोग किया जाता है, इसलिए key, CSR, और अंततः सर्टिफिकेट – सभी एक ही स्थान पर रहते हैं।

वर्शन पर नोट: आधुनिक JBoss है Red Hat JBoss Enterprise Application Platform (EAP) 8, जो फरवरी 2024 में रिलीज़ हुआ और अपस्ट्रीम WildFly प्रोजेक्ट पर आधारित है (WildFly 41, जुलाई 2026 में रिलीज़ हुआ, वर्तमान कम्युनिटी रिलीज़ है)। दोनों HTTPS को elytron सबसिस्टम और Undertow https-listener के माध्यम से वायर करते हैं; पुराने Tomcat या Jetty कनेक्टर कॉन्फ़िगरेशन जो लीगेसी गाइड्स में दिखाया जाता है, अब लागू नहीं होता। हालांकि, CSR चरण स्वयं सभी हाल के वर्शनों में एक समान है क्योंकि यह एक सामान्य Java keytool ऑपरेशन है।

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

• एक Java इंस्टॉलेशन (JDK या JRE) ताकि keytool कमांड उपलब्ध हो। JBoss EAP 8.0 Java 11 (deprecated) या 17 पर चलता है, EAP 8.1 Java 21 जोड़ता है, और WildFly 41 Java 17, 21 या 25 पर चलता है (Java 11 अब अपस्ट्रीम में समर्थित नहीं है)। keytool -help से पुष्टि करें।
• JBoss सर्वर पर शेल या टर्मिनल एक्सेस जो प्राइवेट key को होस्ट करेगा। प्राइवेट key इस सर्वर पर ही रहनी चाहिए।
• वह सटीक fully qualified domain name (FQDN) जिसे आप सुरक्षित करना चाहते हैं, उदाहरण के लिए www.yourdomain.com, साथ ही कोई भी अतिरिक्त होस्टनेम जिन्हें आप SAN फ़ील्ड में कवर करना चाहते हैं।
• CSR के Distinguished Name के लिए आपके संगठन के कानूनी विवरण (देश, राज्य, स्थान, संगठन का नाम)।

चरण 1: keystore और प्राइवेट key बनाएं

यदि आपने पहले ही अपना CSR जेनरेट कर लिया है, तो आगे बढ़ें CSR सबमिट करने पर और फिर JBoss पर अपना SSL सर्टिफिकेट इंस्टॉल करने पर।

JBoss सर्वर पर एक टर्मिनल खोलें और PKCS12 फॉर्मेट में एक नई keystore बनाएं। PKCS12 आधुनिक, पोर्टेबल स्टैंडर्ड (RFC 7292) है और JDK 9 के बाद से Java में डिफ़ॉल्ट keystore फॉर्मेट रहा है; पुराना प्रोप्राइटरी JKS फॉर्मेट deprecated है। चलाएं:

keytool -genkeypair 
  -alias jboss 
  -keyalg RSA -keysize 2048 
  -storetype PKCS12 
  -keystore yourdomain.p12 
  -validity 825

फ्लैग्स का मतलब:

• -alias jboss: keystore के अंदर एंट्री का नाम। एक ऐसा लेबल चुनें जिसे आप पहचान सकें (अक्सर jboss, server, या आपका डोमेन)। इसे लिख लें। आपको यह सटीक alias तब फिर से उपयोग करना होगा जब आप CSR जेनरेट करते हैं और फिर से जब आप साइन किया गया सर्टिफिकेट इम्पोर्ट करते हैं। इम्पोर्ट के समय एक अलग alias का उपयोग करना keytool की सबसे सामान्य गलती है।
• -keyalg RSA -keysize 2048: 2048-बिट RSA key वर्तमान सार्वजनिक न्यूनतम है। ऐसी नई keystores के लिए जिन्हें आप कई सालों तक रखने की योजना बना रहे हैं, 3072 बिट्स एक उचित अपग्रेड है। अधिकांश सार्वजनिक CAs भी ECDSA (-keyalg EC -groupname secp256r1) स्वीकार करते हैं यदि आप एक छोटी, तेज़ key पसंद करते हैं। -groupname विकल्प के लिए JDK 13 या बाद का वर्शन आवश्यक है; Java 11 पर इसके बदले -keyalg EC -keysize 256 का उपयोग करें, जो वही secp256r1 curve चुनता है। keytool एक ही कमांड में दोनों विकल्पों को अस्वीकार करता है।
• -storetype PKCS12: आधुनिक PKCS12 keystore को फोर्स करता है। मैचिंग एक्सटेंशन .p12 (या .pfx) है।
• -keystore yourdomain.p12: बनाई जाने वाली keystore फ़ाइल। इस नाम को किसी ऐसे नाम से बदलें जिसे आप पहचान सकें, और इस फ़ाइल को सुरक्षित रखें; इसमें आपकी प्राइवेट key होती है।
• -validity 825: keystore के अंदर self-signed प्लेसहोल्डर सर्टिफिकेट कितने समय के लिए वैध है। CA से साइन किया गया सर्टिफिकेट बाद में इसे बदल देता है, इसलिए सटीक मान प्रोडक्शन लाइफटाइम को प्रभावित नहीं करता।

keytool फिर एक keystore पासवर्ड मांगता है। एक मजबूत पासवर्ड चुनें और इसे अपने सीक्रेट्स मैनेजर में स्टोर करें: आपको इसकी हर बाद वाली keytool कमांड के लिए और JBoss में कॉन्फ़िगर किए जाने वाले Elytron credential-reference के लिए आवश्यकता होगी। PKCS12 keystores के साथ, key पासवर्ड keystore पासवर्ड के बराबर होता है, इसलिए याद रखने के लिए केवल एक ही पासवर्ड है।

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

keytool अब Distinguished Name (DN) मांगता है: वे पहचान फ़ील्ड्स जो CSR में जाती हैं। हर प्रॉम्प्ट का उत्तर अपने संगठन के सटीक, कानूनी मूल्य से दें। विरामचिह्न और सटीकता महत्वपूर्ण हैं, क्योंकि CA सार्वजनिक बिज़नेस रिकॉर्ड्स के मिसमैच पर इसे अस्वीकार कर देगा।

• First and last name (CN): यह keytool की शब्दावली है, लेकिन यह वास्तव में Common Name फ़ील्ड है। वह सटीक FQDN दर्ज करें जिसे आप सुरक्षित कर रहे हैं, उदाहरण के लिए www.yourdomain.com, या एक वाइल्डकार्ड जैसे *.yourdomain.com। किसी व्यक्ति का नाम दर्ज न करें।
• Organizational unit (OU): यह फ़ील्ड अब सार्वजनिक CAs द्वारा जारी नहीं की जाती और इसे छोड़ देना ही सबसे अच्छा है। ध्यान दें कि Enter दबाने से यह खाली नहीं रहती: keytool अपना स्वयं का डिफ़ॉल्ट प्रतिस्थापित कर देता है, इसलिए DN में OU=Unknown दर्ज हो जाता है, जो फिर CSR में चला जाता है। इस फ़ील्ड को वास्तव में हटाने के लिए, नीचे दिए गए non-interactive -dname फॉर्म का उपयोग करें और स्ट्रिंग में OU को शामिल न करें।
• Organization (O): आपकी कंपनी का पूरा कानूनी नाम, उदाहरण के लिए Your Company LLC। OV और EV सर्टिफिकेट्स के लिए यह आवश्यक है; DV सर्टिफिकेट्स के लिए कई CAs इसे सूचनात्मक रूप में स्वीकार करते हैं, इसलिए इसे भरना खाली छोड़ने से अधिक सुरक्षित है।
• City or locality (L): पूरा शहर का नाम, उदाहरण के लिए San Jose। संक्षिप्त न करें।
• State or province (ST): पूरा राज्य या प्रांत का नाम, उदाहरण के लिए California। दो-अक्षर वाले कोड का उपयोग न करें।
• Country code (C): दो-अक्षर वाला ISO देश कोड, उदाहरण के लिए US, GB, DE।

अंतिम प्रॉम्प्ट के बाद, keytool एक सारांश दिखाता है जैसे CN=www.yourdomain.com, OU=Unknown, O=Your Company LLC, L=San Jose, ST=California, C=US। पुष्टि करने के लिए yes टाइप करें। keystore फ़ाइल अब एक एंट्री के साथ मौजूद है: आपका alias, जिसमें प्राइवेट key और एक self-signed प्लेसहोल्डर सर्टिफिकेट है।

यदि आप एक non-interactive कमांड पसंद करते हैं, तो DN को इनलाइन पास करें और प्रॉम्प्ट्स को स्किप करें:

keytool -genkeypair 
  -alias jboss 
  -keyalg RSA -keysize 2048 
  -storetype PKCS12 
  -keystore yourdomain.p12 
  -dname "CN=www.yourdomain.com, O=Your Company LLC, L=San Jose, ST=California, C=US" 
  -validity 825

चरण 3: SAN के साथ CSR जेनरेट करें

आधुनिक ब्राउज़र और TLS क्लाइंट्स सर्टिफिकेट्स को केवल Common Name के आधार पर नहीं बल्कि Subject Alternative Name (SAN) एक्सटेंशन के आधार पर वेरिफाई करते हैं। SANs को सीधे CSR में रिक्वेस्ट करें ताकि CA उन्हें जारी किए गए सर्टिफिकेट में शामिल करे। चरण 1 से वही alias और keystore का उपयोग करें:

keytool -certreq 
  -alias jboss 
  -keystore yourdomain.p12 
  -file yourdomain.csr 
  -ext san=dns:yourdomain.com,dns:www.yourdomain.com

फ्लैग्स का मतलब:

• -alias jboss: चरण 1 वाले alias से मैच होना चाहिए। यह वह alias है जिसकी प्राइवेट key रिक्वेस्ट पर साइन करती है।
• -keystore yourdomain.p12: चरण 1 वाली keystore से मैच होना चाहिए।
• -file yourdomain.csr: CSR के लिए आउटपुट फ़ाइलनाम।
• -ext san=dns:…: Subject Alternative Name एक्सटेंशन। हर उस होस्टनेम को सूचीबद्ध करें जिसे सर्टिफिकेट को कवर करना चाहिए, जिसमें apex (yourdomain.com) और www सबडोमेन दोनों शामिल हैं। अधिक एंट्रीज़ को कॉमा से अलग करके जोड़ें, उदाहरण के लिए dns:api.yourdomain.com।

keytool keystore पासवर्ड मांगता है और CSR को वर्तमान डायरेक्टरी में yourdomain.csr के रूप में लिखता है।

महत्वपूर्ण: अपना alias और keystore सुरक्षित रखें

JBoss पर सबसे सामान्य keytool गलती एक नए alias के अंतर्गत साइन किया गया सर्टिफिकेट इम्पोर्ट करना है। ऐसा करने से सर्टिफिकेट को एक स्टैंडअलोन ट्रस्टेड एंट्री के रूप में स्टोर किया जाता है जिसमें कोई प्राइवेट key जुड़ी नहीं होती, और Elytron key-manager TLS सेशन शुरू करने में विफल हो जाएगा। साइन किए गए रिप्लाई को हमेशा उस समान alias में इम्पोर्ट करें जिसमें प्राइवेट key है (चरण 1 वाला alias)।

टर्मिनल बंद करने से पहले इन तीन मूल्यों को नोट कर लें:

• alias (इस गाइड में, jboss)।
• keystore फ़ाइल पथ (उदाहरण के लिए yourdomain.p12; JBoss पर यह सामान्यतः $JBOSS_HOME/standalone/configuration/ में रहती है)।
• keystore पासवर्ड।

यदि आप निश्चित नहीं हैं कि कौन सा alias आपकी key रखता है, तो keystore की सामग्री सूचीबद्ध करें और उस एंट्री की तलाश करें जिसका प्रकार PrivateKeyEntry है:

keytool -list -v -keystore yourdomain.p12

चरण 4: सबमिट करने से पहले CSR को वेरिफाई करें

CA द्वारा वेरिफाई किए जाने से पहले DN में टाइपो या गायब SANs पकड़ें। keytool से CSR प्रिंट करें:

keytool -printcertreq -file yourdomain.csr

या, यदि OpenSSL इंस्टॉल है, तो आप इसके बदले इसका उपयोग कर सकते हैं:

openssl req -noout -text -in yourdomain.csr

आउटपुट में तीन चीज़ों की पुष्टि करें: Subject आपका सटीक DN दिखाता है, Subject Alternative Name हर उस होस्टनेम को सूचीबद्ध करता है जिसकी आपको ज़रूरत है, और Public-Key का साइज़ उससे मैच करता है जो आपने मांगा था (2048-बिट RSA, या जो भी आपने चुना)। आप समान जांच ब्राउज़र में करने के लिए हमारे CSR Decoder में भी CSR पेस्ट कर सकते हैं।

चरण 5: अपने Certificate Authority को CSR सबमिट करें

yourdomain.csr को किसी भी टेक्स्ट एडिटर में खोलें। फ़ाइल सादा टेक्स्ट है, जो -----BEGIN NEW CERTIFICATE REQUEST----- से शुरू होती है और -----END NEW CERTIFICATE REQUEST----- पर समाप्त होती है। शब्द NEW वह है जो keytool लिखता है, और यह अपेक्षित है: सामग्री एक स्टैंडर्ड PKCS#10 रिक्वेस्ट है जिसे हर CA स्वीकार करता है। पूरा ब्लॉक कॉपी करें, इन हेडर और फुटर लाइनों को शामिल करते हुए, और इसे अपने CA के साथ चेकआउट के दौरान CSR फ़ील्ड में पेस्ट करें। Windows पर, पूरा टेक्स्ट पकड़ने के लिए Ctrl + A फिर Ctrl + C का उपयोग करें; macOS पर, Cmd + A फिर Cmd + C का उपयोग करें।

कुछ और करने से पहले keystore फ़ाइल का बैकअप लें। यदि आप yourdomain.p12 खो देते हैं तो आप प्राइवेट key भी खो देंगे, जिसका मतलब है कि CA द्वारा लौटाया गया साइन किया गया सर्टिफिकेट अनुपयोगी हो जाएगा और आपको एक नए CSR के साथ फिर से शुरू करना होगा।

CA द्वारा आपकी रिक्वेस्ट वेरिफाई करने और सर्टिफिकेट जारी करने के बाद, JBoss पर अपना SSL सर्टिफिकेट कैसे इंस्टॉल करें के साथ आगे बढ़ें। आप साइन किए गए सर्टिफिकेट को समान keystore में समान alias में फिर से इम्पोर्ट करेंगे, फिर उस keystore को एक Elytron key-store, key-manager, और server-ssl-context से संदर्भित करेंगे जो Undertow https-listener में वायर किया गया है।

क्या मैं रिन्यूअल के लिए CSR का पुन: उपयोग कर सकता हूँ?

आप कर सकते हैं, लेकिन सुरक्षा की सर्वोत्तम प्रैक्टिस यह है कि हर सर्टिफिकेट के लिए एक नई keystore, एक नई प्राइवेट key, और एक नया CSR जेनरेट करें। हर रिन्यूअल के लिए एक नई key यह सुनिश्चित करती है कि यदि पुरानी key कभी compromise हो जाए तो प्रभाव सीमित रहे, और प्रक्रिया समान है: एक नई keystore फ़ाइल के विरुद्ध keytool -genkeypair और keytool -certreq चलाएं। CA/Browser Forum के नियमों के अंतर्गत सार्वजनिक TLS सर्टिफिकेट लाइफटाइम्स घट रही हैं (15 मार्च, 2026 से 200 दिन, 2027 में 100 दिन और 2029 में 47 दिन तक घटते हुए), इसलिए अधिक बार-बार होने वाले CSR चक्रों की योजना बनाएं, या जहाँ आपका CA समर्थन करता है वहाँ ACME के माध्यम से जारी करने को स्वचालित करें।