OpenSSL का उपयोग करके Self-Signed Certificate कैसे जनरेट करें?

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

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

सेल्फ-साइन्ड सर्टिफिकेट क्या है

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

यह सेल्फ-साइन्ड सर्टिफिकेट को इनके लिए एक अच्छा विकल्प बनाता है:

• लोकल डेवलपमेंट, जहां आपको HTTPS की आवश्यकता होती है ताकि कुकीज़, सर्विस वर्कर्स, या पेमेंट SDK उसी तरह व्यवहार करें जैसे वे प्रोडक्शन में करेंगे।
• इंटरनल सर्विसेज जैसे कि एक इंट्रानेट डैशबोर्ड, एक मॉनिटरिंग पैनल, या एक प्राइवेट नेटवर्क पर डिवाइस मैनेजमेंट इंटरफ़ेस।
• टेस्टिंग और स्टेजिंग, जहां आप किसी TLS कॉन्फ़िगरेशन का पूर्वाभ्यास करना चाहते हैं बिना उस पर कोई सर्टिफिकेट खर्च किए।
• प्रॉक्सी के पीछे मौजूद ओरिजिन सर्वर जो बैक-एंड लेग पर अविश्वसनीय सर्टिफिकेट स्वीकार करते हैं, जैसे कि Full मोड में Cloudflare।

ये उस किसी भी चीज़ के लिए गलत टूल हैं जिसे कोई वास्तविक विज़िटर लोड करेगा। हम इस अंतर को नीचे विस्तार से कवर करते हैं, “इसे कब उपयोग न करें” सेक्शन में।

शुरू करने से पहले: अपना OpenSSL चेक करें

आपको OpenSSL कमांड-लाइन टूल की आवश्यकता है। पुष्टि करें कि आपके पास क्या है:

openssl version

• Linux: OpenSSL अधिकतर डिस्ट्रिब्यूशन पर पहले से इंस्टॉल होता है। यदि नहीं है, तो हमारी गाइड देखें Ubuntu पर OpenSSL कैसे इंस्टॉल करें।
• Windows: OpenSSL शामिल नहीं है। हमारे निर्देशों का पालन करें Windows पर OpenSSL कैसे इंस्टॉल करें, फिर कमांड को Command Prompt या PowerShell से चलाएं।
• macOS: Apple, OpenSSL के एक फोर्क, LibreSSL को बिल्ट-इन openssl कमांड के रूप में शिप करता है, इसलिए यह OpenSSL वर्शन के बजाय कुछ इस तरह का रिटर्न देता है LibreSSL 3.3.6।

इस गाइड में मुख्य कमांड LibreSSL 3.3.6 के साथ-साथ मौजूदा OpenSSL पर भी काम करता है, इसलिए Mac उपयोगकर्ता बिल्ट-इन टूल का उपयोग कर सकते हैं। यदि आप वास्तविक OpenSSL चाहते हैं (नीचे दिए गए कुछ वैकल्पिक कमांड के लिए इसकी आवश्यकता होती है), तो इसे Homebrew पैकेज मैनेजर के साथ इंस्टॉल करें और इसे इसके पूर्ण पथ से कॉल करें:

brew install openssl@3
/opt/homebrew/opt/openssl@3/bin/openssl version

Intel Mac पर, इसके बजाय पथ /usr/local/opt/openssl@3/bin/openssl है। आउटपुट पढ़ने के बारे में अधिक जानकारी के लिए, हमारी गाइड देखें अपना OpenSSL वर्शन कैसे जांचें।

OpenSSL के साथ सेल्फ-साइन्ड सर्टिफिकेट कैसे बनाएं

चरण 1: एक टर्मिनल खोलें

Linux पर, Ctrl + Alt + T दबाएं या अपने एप्लिकेशन मेनू में “Terminal” खोजें। macOS पर, Applications खोलें, फिर Utilities, फिर Terminal, या Cmd + Space दबाएं और “Terminal” टाइप करें। Windows पर, Win + R दबाएं, cmd टाइप करें, और Enter दबाएं।

चरण 2: उस फ़ोल्डर में जाएं जहां आप फाइलें रखना चाहते हैं

OpenSSL अपना आउटपुट उस डायरेक्टरी में लिखता है जिसमें आप वर्तमान में हैं, न कि उस डायरेक्टरी में जहां OpenSSL इंस्टॉल है। इस सर्टिफिकेट के लिए एक फ़ोल्डर बनाएं और उसमें जाएं ताकि key और सर्टिफिकेट किसी ऐसी जगह पर पहुंचें जहां आप उन्हें ढूंढ सकें:

mkdir my-cert
cd my-cert

Windows पर, Command Prompt में समान दो कमांड का उपयोग करें। OpenSSL प्रोग्राम फ़ोल्डर के अंदर से कमांड न चलाएं: Windows पर वह डायरेक्टरी अक्सर एक सामान्य उपयोगकर्ता द्वारा लिखने योग्य नहीं होती, और अपनी keys को बाइनरी के साथ मिलाने से उन्हें खोना आसान हो जाता है।

चरण 3: सर्टिफिकेट कमांड चलाएं

यह एकल कमांड प्राइवेट key और सेल्फ-साइन्ड सर्टिफिकेट को एक साथ जेनरेट करता है। example.com और www.example.com को उन नामों से बदलें जिनसे आपकी सर्विस वास्तव में एक्सेस की जाएगी:

openssl req -x509 -newkey rsa:2048 -keyout private.key -out certificate.crt -days 365 -nodes -addext "subjectAltName=DNS:example.com,DNS:www.example.com" -addext "basicConstraints=critical,CA:FALSE" -addext "extendedKeyUsage=serverAuth"

इसे एक ही लाइन में रखें। Command Prompt और Unix शेल अलग-अलग लाइन-कंटीन्यूएशन कैरेक्टर उपयोग करते हैं, और एक ही लाइन सब जगह काम करती है। इसी कारण से, सिंगल कोट्स के बजाय डबल कोट्स का उपयोग करें: Command Prompt सिंगल कोट्स को क्वोटिंग के रूप में नहीं मानता है।

यहां बताया गया है कि प्रत्येक भाग क्या करता है:

• req -x509: सर्टिफिकेट साइनिंग रिक्वेस्ट के बजाय एक पूर्ण, साइन किया गया सर्टिफिकेट उत्पन्न करता है।
• -newkey rsa:2048: उसी कमांड के हिस्से के रूप में एक नई 2048-बिट RSA प्राइवेट key बनाता है। 2048 बिट्स मौजूदा न्यूनतम है और एक उचित डिफ़ॉल्ट है। यदि आपकी पॉलिसी को एक बड़ी key की आवश्यकता है तो rsa:4096 का उपयोग करें, धीमे हैंडशेक की कीमत पर।
• -keyout private.key: प्राइवेट key के लिए फ़ाइलनाम।
• -out certificate.crt: सर्टिफिकेट के लिए फ़ाइलनाम।
• -days 365: सर्टिफिकेट कितने समय तक वैध रहता है। इसे बदलने से पहले नीचे दिया गया validity सेक्शन देखें।
• -nodes: प्राइवेट key को अनएन्क्रिप्टेड छोड़ता है, ताकि आपका वेब सर्वर बिना किसी इंसान द्वारा पासफ़्रेज़ टाइप किए बिना शुरू हो सके।
• -addext “subjectAltName=…”: उन होस्टनेम की सूची जिनके लिए सर्टिफिकेट वैध है। इसके बिना, सर्टिफिकेट किसी से भी मेल नहीं खाता।
• -addext “basicConstraints=critical,CA:FALSE”: सर्टिफिकेट को एक सर्टिफिकेट अथॉरिटी के बजाय एक end-entity (सर्वर) सर्टिफिकेट के रूप में चिह्नित करता है।
• -addext “extendedKeyUsage=serverAuth”: बताता है कि सर्टिफिकेट एक TLS सर्वर को प्रमाणित करने के लिए है। Apple प्लेटफ़ॉर्म इसे अनिवार्य मानते हैं।

तीन -addext विकल्प क्यों महत्वपूर्ण हैं

ये तीन फ्लैग एक ऐसे सर्टिफिकेट और एक ऐसे सर्टिफिकेट के बीच का अंतर हैं जिसे क्लाइंट पूरी तरह से मानने से इनकार कर देते हैं। इन्हें समझना उचित है, क्योंकि इनके बिना बनाया गया सेल्फ-साइन्ड सर्टिफिकेट तीन तरीकों से विफल होता है जिनका गलत निदान करना आसान है।

Subject Alternative Name वह जगह है जहां होस्टनेम रहते हैं। ब्राउज़रों ने वर्षों पहले Common Name फ़ील्ड पढ़ना बंद कर दिया था और अब केवल Subject Alternative Name (SAN) एक्सटेंशन के मुताबिक होस्टनेम का मिलान करते हैं। बिना SAN के सर्टिफिकेट किसी साइट से मेल नहीं खाता, भले ही Common Name सही दिखे। हर उस नाम की सूची बनाएं जिसका आप उपयोग करेंगे, कॉमा से अलग करके। एक लोकल सर्विस के लिए आप एक IP एड्रेस भी शामिल कर सकते हैं:

-addext "subjectAltName=DNS:localhost,DNS:dev.example.com,IP:127.0.0.1"

CA:FALSE के बिना, OpenSSL आपके लिए एक CA सर्टिफिकेट बनाता है। जब req -x509 को अपने खुद के डिफ़ॉल्ट पर छोड़ दिया जाता है, तो यह basicConstraints को critical, CA:TRUE पर सेट करता है, जो एक सर्टिफिकेट अथॉरिटी का वर्णन करता है, न कि एक वेब सर्वर का। Chrome और Safari इसे सर्वर सर्टिफिकेट पर स्वीकार करते हैं। Firefox नहीं, और MOZILLA_PKIX_ERROR_CA_CERT_USED_AS_END_ENTITY के साथ रुक जाता है। आप फिर भी Advanced पर क्लिक कर सकते हैं और एक एक्सेप्शन जोड़ सकते हैं, लेकिन आप एक ऐसे सर्टिफिकेट के इर्द-गिर्द काम कर रहे होंगे जिसे आप पहले से जानते हैं कि यह विकृत है, और अन्य क्लाइंट अलग-अलग जगहों पर रेखा खींचते हैं। basicConstraints=critical,CA:FALSE पास करना शुरू से ही इस स्थिति से बचाता है।

macOS द्वारा शिप की गई LibreSSL बिल्ड यहां अलग तरह से व्यवहार करती है: अपने खुद के डिफ़ॉल्ट पर छोड़ी जाने पर यह बिना किसी एक्सटेंशन के एक X.509 वर्शन 1 सर्टिफिकेट लिखती है, इसलिए आपको कोई CA:TRUE समस्या नहीं मिलती लेकिन कोई Subject Alternative Name भी नहीं मिलता। एक्सटेंशन को स्पष्ट रूप से प्रदान करना आपको दोनों टूल पर समान, सही सर्टिफिकेट देता है।

serverAuth के बिना, Apple प्लेटफ़ॉर्म सर्टिफिकेट को रिजेक्ट करते हैं। विश्वसनीय सर्टिफिकेट के लिए Apple की प्रकाशित आवश्यकताएं बताती हैं कि एक TLS सर्वर सर्टिफिकेट में id-kp-serverAuth OID वाला एक ExtendedKeyUsage एक्सटेंशन होना चाहिए। इसके बिना एक सर्टिफिकेट TLS पॉलिसी के अंतर्गत macOS सर्टिफिकेट वैलिडेशन में “Invalid Extended Key Usage for policy” संदेश के साथ विफल हो जाता है, तब भी जब सर्टिफिकेट को इसका अपना ही ट्रस्ट एंकर बताया गया हो। Firefox और Chrome अधिक उदार हैं और सर्वर सर्टिफिकेट पर एक गुम ExtendedKeyUsage को अनुमति के रूप में मानते हैं, इसलिए इसे तब तक अनजान करना आसान है जब तक कि Mac या iPhone ही वह चीज़ न बन जाए जो कनेक्ट नहीं होगी। extendedKeyUsage=serverAuth जोड़ने की अन्य प्लेटफ़ॉर्म पर कोई लागत नहीं है और यह वही है जो एक सार्वजनिक CA वैसे भी जारी करेगा।

चरण 4: सर्टिफिकेट विवरण भरें

OpenSSL उन फ़ील्ड्स के लिए पूछता है जो Distinguished Name बनाते हैं। इनमें से किसी को भी छोड़ने के लिए Enter दबाएं, लेकिन कम से कम एक भरें, और उसे Common Name बनाएं। macOS पर LibreSSL बिल्ड “error, no objects specified in config file” के साथ रुक जाती है और यदि आप हर फ़ील्ड को खाली छोड़ देते हैं तो कुछ भी नहीं लिखती। नीचे दिए गए मान उदाहरण हैं, इसलिए अपने स्वयं के मान का उपयोग करें:

• Country Name: आपके देश के लिए दो-अक्षर वाला कोड, उदाहरण के लिए US।
• State or Province Name: पूरा लिखा गया, उदाहरण के लिए California।
• Locality Name: आपका शहर, उदाहरण के लिए San Jose।
• Organization Name: आपकी कंपनी या प्रोजेक्ट का नाम, उदाहरण के लिए Example Inc।
• Organizational Unit Name: जिम्मेदार टीम, उदाहरण के लिए IT।
• Common Name: मुख्य होस्टनेम, उदाहरण के लिए example.com। वही नाम उपयोग करें जो आपने Subject Alternative Name सूची में पहले रखा था।
• Email Address: एक संपर्क पता, उदाहरण के लिए [email protected]। वैकल्पिक।

यहां केवल Common Name ही वास्तव में महत्वपूर्ण है, और वह भी केवल एक लेबल के रूप में: होस्टनेम मैचिंग उस Subject Alternative Name द्वारा की जाती है जो आपने पहले से ही कमांड लाइन पर सेट किया है। बाकी सब वर्णनात्मक है।

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

चरण 5: उपयोग करने से पहले सर्टिफिकेट को वेरिफ़ाई करें

इसे न छोड़ें। एक सेल्फ-साइन्ड सर्टिफिकेट सफलतापूर्वक जेनरेट किया जा सकता है और फिर भी उपयोग करने योग्य न हो, और विफलता केवल बाद में एक ब्राउज़र एरर के रूप में दिखाई देती है। सर्टिफिकेट को वापस पढ़ें:

openssl x509 -in certificate.crt -noout -text

X509v3 extensions ब्लॉक में आप ठीक तीन चीज़ें देख रहे हैं:

X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com
X509v3 Basic Constraints: critical
    CA:FALSE
X509v3 Extended Key Usage:
    TLS Web Server Authentication

यदि Subject Alternative Name लाइन गुम है, तो सर्टिफिकेट किसी भी होस्टनेम से मेल नहीं खाएगा। यदि Basic Constraints कहता है CA:TRUE, तो Firefox इसे रोक देगा। यदि Extended Key Usage लाइन गुम है, तो Apple प्लेटफ़ॉर्म सर्टिफिकेट को रिजेक्ट कर देंगे। इन में से किसी भी स्थिति में, दो फाइलों को डिलीट करें और सभी तीन -addext विकल्पों के साथ कमांड को फिर से चलाएं।

OpenSSL 3.x पर आप पूरे सर्टिफिकेट को पढ़ने के बजाय केवल उन एक्सटेंशन के लिए पूछ सकते हैं:

openssl x509 -in certificate.crt -noout -ext subjectAltName,basicConstraints,extendedKeyUsage

-ext फ्लैग macOS द्वारा शिप की गई LibreSSL बिल्ड में मौजूद नहीं है, जो “unknown option -ext” रिपोर्ट करता है। एक स्टॉक Mac पर, ऊपर दिया गया -text वर्शन उपयोग करें।

यह पुष्टि करने के लिए कि सर्टिफिकेट और key एक साथ हैं, उनके मॉड्यूलस की तुलना करें। दोनों कमांड को एक ही hash प्रिंट करना चाहिए:

openssl x509 -noout -modulus -in certificate.crt | openssl md5
openssl rsa -noout -modulus -in private.key | openssl md5

सर्टिफिकेट स्वयं एक टेक्स्ट फ़ाइल है। इसे टेक्स्ट एडिटर में खोलने पर BEGIN CERTIFICATE और END CERTIFICATE लाइनों के बीच एक base64 ब्लॉक दिखता है, जो वह है जिसे आप कंट्रोल पैनल में पेस्ट करते हैं जो फ़ाइल अपलोड के बजाय सर्टिफिकेट मांगते हैं।

कमांड में विविधताएं

इसे किसी प्रॉम्प्ट के बिना जेनरेट करें

स्क्रिप्ट्स और CI पाइपलाइन के लिए, -subj के साथ Distinguished Name प्रदान करें और कमांड बिना किसी सहायता के चलता है:

openssl req -x509 -newkey rsa:2048 -keyout private.key -out certificate.crt -days 365 -nodes -subj "/C=US/ST=California/L=San Jose/O=Example Inc/CN=example.com" -addext "subjectAltName=DNS:example.com,DNS:www.example.com" -addext "basicConstraints=critical,CA:FALSE" -addext "extendedKeyUsage=serverAuth"

RSA के बजाय EC key का उपयोग करें

इलिप्टिक-कर्व keys समान शक्ति पर RSA से छोटी और तेज़ होती हैं, और हर मौजूदा ब्राउज़र इनका समर्थन करता है। P-256 मानक विकल्प है:

openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -keyout private.key -out certificate.crt -days 365 -nodes -addext "subjectAltName=DNS:example.com,DNS:www.example.com" -addext "basicConstraints=critical,CA:FALSE" -addext "extendedKeyUsage=serverAuth"

परिणाम को ecdsa-with-SHA256 से साइन किया जाता है। यदि आपको पुराने एम्बेडेड क्लाइंट्स या लीगेसी Java वर्शन का समर्थन करना है, जिनमें कभी-कभी EC सपोर्ट नहीं होता, तो RSA के साथ बने रहें।

इसके लिए वास्तविक OpenSSL का उपयोग करें। macOS पर LibreSSL बिल्ड कमांड को स्वीकार करती है, लेकिन यह कर्व को सर्टिफिकेट में मानक P-256 पहचानकर्ता के बजाय स्पष्ट पैरामीटरों के एक पूर्ण सेट के रूप में लिखती है। RFC 5480 बताता है कि स्पष्ट रूप का सर्टिफिकेट में उपयोग नहीं किया जाना चाहिए, और macOS खुद इस तरह एन्कोड किए गए सर्टिफिकेट को रिजेक्ट करता है।

परिणाम को openssl x509 -in certificate.crt -noout -text से जांचें: आप एक ऐसी लाइन चाहते हैं जो “ASN1 OID: prime256v1” पढ़ती हो, Prime, A, B, और Generator की सूची वाला ब्लॉक नहीं। एक स्टॉक Mac पर, या तो ऊपर दिए गए RSA कमांड का उपयोग करें या पहले Homebrew के माध्यम से OpenSSL इंस्टॉल करें।

-nodes या -noenc?

दोनों फ्लैग एक ही काम करते हैं: वे OpenSSL को प्राइवेट key को पासफ़्रेज़ के साथ एन्क्रिप्ट करने से रोकते हैं। OpenSSL 3.x ने स्पष्ट नाम के रूप में -noenc जोड़ा और -nodes को डिप्रिकेटेड के रूप में सूचीबद्ध करता है, हालांकि यह अभी भी इसे स्वीकार करता है। LibreSSL, जो macOS शिप करता है, -noenc को बिलकुल भी नहीं पहचानता और एरर देता है।

यह गाइड -nodes का उपयोग करती है क्योंकि यह वह विकल्प है जो हर उस बिल्ड पर काम करता है जिसका आप सामना करने की संभावना रखते हैं, जिसमें एक स्टॉक Mac भी शामिल है। यदि आप OpenSSL 3.x पर हैं और डिप्रिकेटेड स्पेलिंग से बचना चाहते हैं, तो -noenc में स्वैप करें। और कुछ नहीं बदलता।

यदि आप फ्लैग को पूरी तरह से छोड़ देते हैं, तो OpenSSL key को आपके द्वारा चुने गए पासफ़्रेज़ से एन्क्रिप्ट करता है, और आपका वेब सर्वर तब हर रीस्टार्ट पर इसके लिए प्रॉम्प्ट करेगा। यह शायद ही कभी वह है जो आप एक डेवलपमेंट सर्टिफिकेट के लिए चाहते हैं।

अपनी मशीन को सर्टिफिकेट पर भरोसा दिलाएं

एक सही सेल्फ-साइन्ड सर्टिफिकेट भी एक ब्राउज़र चेतावनी उत्पन्न करता है, क्योंकि इस पर भरोसा करने के लिए कुछ भी नहीं बताया गया है। इसे अपने लोकल ट्रस्ट स्टोर में जोड़ना वह है जो चेतावनी को बंद करता है, और यह सामान्यतः इसे बनाने का ही उद्देश्य होता है।

ऐसा केवल उन मशीनों पर करें जिन्हें आप नियंत्रित करते हैं, और केवल उन सर्टिफिकेट के लिए जो आपने स्वयं जेनरेट किए हैं। एक विश्वसनीय सर्टिफिकेट उस हर साइट के लिए विश्वसनीय है जिसे यह नाम देता है, इसलिए प्राइवेट key को उसी के अनुसार मानें और इसे कभी शेयर न करें।

macOS Keychain

सर्टिफिकेट को सिस्टम keychain में जोड़ें और इसे TLS के लिए विश्वसनीय के रूप में चिह्नित करें। आपसे आपका एडमिनिस्ट्रेटर पासवर्ड पूछा जाएगा:

sudo security add-trusted-cert -d -r trustRoot -p ssl -k /Library/Keychains/System.keychain certificate.crt

-p ssl भाग ट्रस्ट को TLS कनेक्शन तक सीमित करता है। इसे छोड़ दें और सर्टिफिकेट macOS द्वारा जाने जाने वाले हर उद्देश्य के लिए विश्वसनीय हो जाता है, जिसमें code signing भी शामिल है, जो एक डेवलपमेंट सर्टिफिकेट की आवश्यकता से कहीं अधिक है।

इसके बजाय इंटरफ़ेस के माध्यम से करने के लिए, Keychain Access खोलने हेतु सर्टिफिकेट फ़ाइल पर डबल-क्लिक करें, System keychain के अंतर्गत एंट्री ढूंढें, इसे खोलें, Trust को विस्तार करें, और When using this certificate को Always Trust पर सेट करें। इसे बाद में उलटने के लिए, Keychain Access से एंट्री डिलीट करें।

Windows सर्टिफिकेट स्टोर

Command Prompt को एडमिनिस्ट्रेटर के रूप में खोलें (Win + R दबाएं, cmd टाइप करें, फिर Ctrl + Shift + Enter दबाएं) और सर्टिफिकेट को Trusted Root Certification Authorities स्टोर में जोड़ें:

certutil -addstore -f "Root" certificate.crt

वैकल्पिक रूप से, सर्टिफिकेट फ़ाइल पर डबल-क्लिक करें, Install Certificate चुनें, Local Machine चुनें, फिर Place all certificates in the following store, और Trusted Root Certification Authorities में ब्राउज़ करें। इसे बाद में हटाने के लिए, certmgr.msc खोलें और उस स्टोर से एंट्री डिलीट करें।

Linux ca-certificates

Debian और Ubuntu पर, सर्टिफिकेट को लोकल एंकर्स डायरेक्टरी में कॉपी करें और बंडल को फिर से बनाएं। फ़ाइल को .crt एक्सटेंशन रखना ज़रूरी है या अपडेट टूल इसे नज़रअंदाज़ कर देगा:

sudo cp certificate.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

RHEL, CentOS, AlmaLinux, Rocky, और Fedora पर, पथ अलग हैं:

sudo cp certificate.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust extract

Firefox अपवाद

Firefox ऑपरेटिंग सिस्टम का उपयोग करने के बजाय अपना ही ट्रस्ट स्टोर रखता है। Windows और macOS पर यह डिफ़ॉल्ट रूप से OS स्टोर में जोड़े गए roots को भी पढ़ता है, इसलिए ऊपर दिए गए स्टेप्स सामान्यतः इसे कवर करते हैं। Linux पर यह नहीं करता, इसलिए सर्टिफिकेट को सीधे Firefox में इम्पोर्ट करना होता है: Settings खोलें, फिर Privacy & Security, Certificates तक स्क्रॉल करें, View Certificates पर क्लिक करें, Authorities टैब खोलें, और Import का उपयोग करें।

इनमें से किसी भी बदलाव के बाद ब्राउज़र को रीस्टार्ट करें। ब्राउज़र सर्टिफिकेट निर्णयों को कैश करते हैं, और एक पुराना सेशन सामान्य कारण है कि सही इम्पोर्ट के बाद भी चेतावनी बनी रहती है।

सेल्फ-साइन्ड सर्टिफिकेट का उपयोग कब न करें

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

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