सर्टिफिकेट्स और कीज़: इंटरनेट के गुप्त हैंडशेक

एक वाक्य में

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

यह कौन सी समस्या हल करता है

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

यह शुरुआती वेब की दोहरी समस्या थी: प्राइवेसी (privacy) और पहचान (identity)। आप एक निजी बातचीत कैसे कर सकते हैं जब कोई भी सुन सकता है? और आप कैसे भरोसा कर सकते हैं कि जिस वेबसाइट से आप बात कर रहे हैं वह वाकई your-bank.com है, न कि कोई चालाक धोखेबाज़?

इसी समस्या को हल करने के लिए SSL/TLS (HTTPS में "S" और आपके ब्राउज़र में पैडलॉक आइकन के पीछे की तकनीक) बनाया गया था। और यह पूरी प्रणाली क्रिप्टोग्राफ़िक कीज़ और डिजिटल सर्टिफिकेट्स की अवधारणाओं पर टिकी हुई है। वे विश्वास स्थापित करने और इंटरनेट जैसे स्वाभाविक रूप से असुरक्षित नेटवर्क पर संचार के लिए एक सुरक्षित, एन्क्रिप्टेड चैनल बनाने का एक मानकीकृत, गणितीय रूप से सत्यापन योग्य तरीका प्रदान करते हैं।

यह अंदर से कैसे काम करता है

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

पब्लिक-की क्रिप्टोग्राफी: एसिमेट्रिकल लॉकबॉक्स

कल्पना कीजिए कि आपके पास दो चाबियों वाला एक विशेष लॉकबॉक्स है।

एक पब्लिक की (public key), जिसे आप कॉपी करके किसी को भी दे सकते हैं। यह की बॉक्स को सिर्फ लॉक कर सकती है।
एक प्राइवेट की (private key), जिसे आप गुप्त रखते हैं। यह गणितीय रूप से पब्लिक की से संबंधित है, और यह बॉक्स को अनलॉक करने वाली एकमात्र की है।

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

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

किरदारों की कास्ट

TLS हैंडशेक कुछ प्रमुख किरदारों और प्रॉप्स के साथ एक नाटक है:

प्राइवेट की (Private Key): यह आपका सबसे सुरक्षित रहस्य है। यह एक बड़ा, रैंडमली जेनरेट किया गया डेटा ब्लॉक है जिसे कभी भी, किसी के साथ भी शेयर नहीं करना चाहिए। यह अपनी संबंधित पब्लिक की से एन्क्रिप्ट किए गए डेटा को डिक्रिप्ट कर सकता है और डिजिटल हस्ताक्षर बना सकता है।
पब्लिक की (Public Key): प्राइवेट की से निकली, यह वह हिस्सा है जिसे आप स्वतंत्र रूप से शेयर कर सकते हैं। यह आपके सर्टिफिकेट के अंदर एम्बेडेड होती है। यह डेटा को एन्क्रिप्ट कर सकती है जिसे केवल प्राइवेट की ही डिक्रिप्ट कर सकती है।
सर्टिफिकेट साइनिंग रिक्वेस्ट (CSR): यह एक औपचारिक आवेदन है जिसे आप एक भरोसेमंद अथॉरिटी को भेजते हैं। यह टेक्स्ट का एक ब्लॉक है जिसमें आपकी पब्लिक की और आपके बारे में पहचान की जानकारी (जैसे आपका डोमेन नाम, www.example.com, और आपका संगठन) होती है। आप अपनी प्राइवेट की बनाने के बाद एक CSR जेनरेट करते हैं।
सर्टिफिकेट अथॉरिटी (CA): एक CA एक भरोसेमंद थर्ड-पार्टी है, जैसे एक डिजिटल नोटरी (जैसे, Let's Encrypt, DigiCert, GlobalSign)। आपके ब्राउज़र और ऑपरेटिंग सिस्टम में उन CAs की एक अंतर्निहित सूची होती है जिन पर वे भरोसा करते हैं। CA का काम आपके CSR में दी गई जानकारी को सत्यापित करना है (यह साबित करना कि आप वास्तव में डोमेन के मालिक हैं, उदाहरण के लिए) और फिर आपकी सर्टिफिकेट को डिजिटल रूप से साइन करने के लिए अपनी खुद की प्राइवेट की का उपयोग करना है।
सर्टिफिकेट (.crt या .cer फ़ाइल): यह अंतिम, हस्ताक्षरित दस्तावेज़ है। यह आपकी पहचान (आपका डोमेन) को आपकी पब्लिक की से जोड़ता है। जब कोई ब्राउज़र आपके सर्वर से कनेक्ट होता है, तो आपका सर्वर यह सर्टिफिकेट प्रस्तुत करता है। ब्राउज़र CA के हस्ताक्षर को CA की पब्लिक की (जिस पर वह पहले से ही भरोसा करता है) का उपयोग करके जांचता है। यदि हस्ताक्षर वैध है, तो ब्राउज़र जानता है कि वह भरोसा कर सकता है कि आपकी पब्लिक की वास्तव में आपकी ही है। अब वह उस पब्लिक की का उपयोग एक एन्क्रिप्टेड बातचीत शुरू करने के लिए कर सकता है।

फॉर्मेट्स, फॉर्मेट्स हर जगह

डेवलपर्स के लिए सबसे बड़ी उलझन अक्सर फ़ाइल फॉर्मेट्स और एक्रोनिम्स की चक्करघिन्नी होती है। वे ज्यादातर एक ही अंतर्निहित डेटा को लिखने के विभिन्न तरीकों का वर्णन करते हैं।

फॉर्मेट	यह क्या है	कैसा दिखता है
DER	सर्टिफिकेट या की डेटा के लिए एक बाइनरी (binary) एन्कोडिंग फॉर्मेट। कॉम्पैक्ट और मशीन-पठनीय, लेकिन मानव-अनुकूल नहीं।	बाइनरी गिबरिश का एक ब्लॉक। टेक्स्ट एडिटर में नहीं खोला जा सकता।
PEM	सबसे आम फॉर्मेट। यह सिर्फ Base64 में एन्कोड किया गया DER डेटा है, जिसे प्लेन-टेक्स्ट हेडर के साथ लपेटा गया है।	`-----BEGIN CERTIFICATE-----` `MIIE...` `-----END CERTIFICATE-----`
PKCS#1 / PKCS#8	प्राइवेट कीज़ के फॉर्मेट के लिए स्टैंडर्ड्स। PKCS#8 आधुनिक, ज़्यादा वर्सटाइल स्टैंडर्ड है। आपको अक्सर किसी पुराने सॉफ्टवेयर को संतुष्ट करने के लिए कीज़ को एक से दूसरे में बदलने की आवश्यकता होती है।	PEM ब्लॉक हेडर में `-----BEGIN RSA PRIVATE KEY-----` (PKCS#1) या `-----BEGIN PRIVATE KEY-----` (PKCS#8) लिखा होगा।
PKCS#12 (PFX)	एक आर्काइव (archive) फॉर्मेट। यह एक सिंगल, पासवर्ड-सुरक्षित फ़ाइल है जो सब कुछ बंडल कर सकती है: प्राइवेट की, पब्लिक सर्टिफिकेट, और इंटरमीडिएट CA सर्टिफिकेट्स। एक `.pfx` या `.p12` फ़ाइल एक पोर्टेबल पहचान है।	एक सिंगल बाइनरी फ़ाइल। इसे खोलने के लिए आपको एक पासवर्ड और एक टूल की आवश्यकता होगी।

DER को रॉ डेटा समझें, और PEM को उस डेटा के लिए एक टेक्स्ट-फ्रेंडली लिफाफा। PKCS#12 एक सुरक्षित ब्रीफकेस की तरह है जिसमें की, सर्टिफिकेट, और बाकी के पहचान पत्र एक साथ रखे जाते हैं।

असल दुनिया की कहानियाँ

सर्वर माइग्रेशन की हड़बड़ी

एक ऑप्स टीम अपनी मुख्य वेबसाइट को एक नए क्लाउड प्रदाता पर माइग्रेट करने के भारी दबाव वाले काम के बीच में थी। अंतिम चरण HTTPS को सक्षम करना था। एक जूनियर इंजीनियर, जिसे यह काम सौंपा गया था, ने पुराने सर्वर पर SSL सर्टिफिकेट फ़ाइल—एक my_site.crt फ़ाइल—ढूंढ निकाली और dutifully नए सर्वर को इसका उपयोग करने के लिए कॉन्फ़िगर किया। साइट शुरू नहीं हुई, और "private key not found" एरर आने लगा। सब घबरा गए। सर्टिफिकेट अपनी प्राइवेट की के बिना बेकार है, और किसी को नहीं पता था कि की कहाँ है। एक उन्मत्त खोज के बाद, एक अन्य इंजीनियर को एक पुराने आर्काइव में my_site_backup.pfx नामक एक फ़ाइल मिली। यह एक PKCS#12 बंडल था। अपने पासवर्ड मैनेजर से एक पासवर्ड का उपयोग करके, वे उस एक फ़ाइल से प्राइवेट की, सर्वर सर्टिफिकेट, और आवश्यक इंटरमीडिएट सर्टिफिकेट्स निकालने में सक्षम हुए। उन्होंने तीनों को नए सर्वर पर इंस्टॉल किया, और पैडलॉक आइकन दिखाई देने लगा।

सीख: एक सर्टिफिकेट आपकी पहचान का सिर्फ पब्लिक आधा हिस्सा है। प्राइवेट की दूसरा, आवश्यक आधा हिस्सा है। एक PKCS#12 (.pfx) बंडल एक वरदान है क्योंकि यह सभी आवश्यक हिस्सों को एक सुरक्षित, पोर्टेबल पैकेज में एक साथ रखता है।

रहस्यमयी API रिजेक्शन

एक मोबाइल ऐप टीम ने एक अपडेट जारी किया और अचानक, उपयोगकर्ताओं के एक छोटे लेकिन महत्वपूर्ण समूह ने रिपोर्ट किया कि वे लॉग इन नहीं कर पा रहे हैं। बैकएंड लॉग्स में इन उपयोगकर्ताओं के लिए "TLS handshake failed" एरर दिख रहे थे, लेकिन दूसरों के लिए नहीं। API क्लाइंट-साइड सर्टिफिकेट ऑथेंटिकेशन द्वारा सुरक्षित था, जहाँ प्रत्येक क्लाइंट (मोबाइल ऐप) को सर्वर को अपनी पहचान साबित करने के लिए अपना अनूठा सर्टिफिकेट प्रस्तुत करना होता है। घंटों की डीबगिंग के बाद, उन्हें समस्या का पता चला: उन उपयोगकर्ताओं के लिए ऐप में डाले गए सर्टिफिकेट्स की समय सीमा समाप्त हो गई थी। सर्वर उन्हें सही ढंग से रिजेक्ट कर रहा था। टीम को जल्दी से प्रभावित उपयोगकर्ताओं के लिए नई कीज़ और CSRs जेनरेट करने पड़े, उन्हें अपने आंतरिक CA से साइन करवाना पड़ा, और जल्दी से एक नया ऐप अपडेट स्टोर पर भेजना पड़ा।

सीख: सर्टिफिकेट्स अमर नहीं होते। उनकी एक समाप्ति तिथि एक कारण से होती है—यह उस क्षति को सीमित करती है यदि कोई की कभी कॉम्प्रोमाइज हो जाए। सर्टिफिकेट जीवनचक्र प्रबंधन (समाप्ति को ट्रैक करना, नवीनीकरण करना और तैनात करना) एक महत्वपूर्ण, निरंतर चलने वाला परिचालन कार्य है।

"इट वर्क्स ऑन माय मशीन" वाला SSL दुःस्वप्न

एक फ्रंटएंड डेवलपर एक नया फीचर बना रहा था जिसके लिए एक नए माइक्रोसर्विस से डेटा लाने की आवश्यकता थी। इसे स्थानीय रूप से टेस्ट करने के लिए, उन्हें माइक्रोसर्विस को HTTPS के साथ चलाना था। उन्होंने जल्दी से एक "सेल्फ-साइन्ड" सर्टिफिकेट जेनरेट किया—एक ऐसा सर्टिफिकेट जो किसी भरोसेमंद CA द्वारा साइन नहीं किया गया था, बल्कि अपनी ही प्राइवेट की द्वारा साइन किया गया था। ब्राउज़र ने एक बड़ी डरावनी वार्निंग स्क्रीन दिखाई, लेकिन उन्होंने "Proceed anyway" पर क्लिक कर दिया, और उनकी मशीन पर सब कुछ ठीक काम करने लगा। आश्वस्त होकर, उन्होंने कोड मर्ज कर दिया। हालाँकि, जब यह स्टेजिंग पर गया, तो हर API कॉल विफल हो गई। ऑटोमेटेड टेस्ट एनवायरनमेंट, एक इंसान के विपरीत, सुरक्षा चेतावनी पर "proceed" पर क्लिक नहीं कर सकता था। उसने एक अविश्वसनीय सर्टिफिकेट देखा और तुरंत कनेक्शन समाप्त कर दिया।

सीख: वेब पर विश्वास स्व-घोषित नहीं होता है; यह एक तीसरे पक्ष द्वारा प्रदान किया जाता है जिस पर बाकी सभी भरोसा करने के लिए सहमत होते हैं। एक सेल्फ-साइन्ड सर्टिफिकेट स्थानीय विकास के लिए उपयोगी है, लेकिन किसी भी साझा वातावरण के लिए, आपको एक ऐसे CA द्वारा साइन किए गए सर्टिफिकेट की आवश्यकता होती है जिस पर आपके सिस्टम (और ब्राउज़र) डिफ़ॉल्ट रूप से भरोसा करते हैं।

आम गलतियाँ और जाल

अपनी प्राइवेट की को सोर्स कंट्रोल में चेक-इन करना। यह एक विनाशकारी गलती है। आपकी प्राइवेट की परम रहस्य है। एक बार जब यह Git हिस्ट्री में आ जाती है, तो आपको इसे कॉम्प्रोमाइज हुआ मानना चाहिए, सर्टिफिकेट को तुरंत रद्द करना चाहिए, और एक नई की जोड़ी जेनरेट करनी चाहिए।
सर्टिफिकेट को एक्सपायर होने देना। यह शायद HTTPS से संबंधित आउटेज का नंबर 1 कारण है। अधिकांश CA रिमाइंडर ईमेल भेजते हैं, लेकिन अपनी खुद की निगरानी और कैलेंडर अलर्ट रखना महत्वपूर्ण है। एक एक्सपायर हुआ सर्टिफिकेट आपकी साइट को उपयोगकर्ताओं के लिए दुर्गम बना देगा।
सर्वर पर गलत सर्टिफिकेट का उपयोग करना। आपके पास www.example.com के लिए एक सर्टिफिकेट है लेकिन आप इसे api.example.com से सर्व करते हैं। इससे "होस्टनेम मिसमैच" एरर होगा और कनेक्शन टूट जाएगा। वाइल्डकार्ड सर्टिफिकेट (*.example.com) इसमें मदद कर सकते हैं।
इंटरमीडिएट सर्टिफिकेट्स को भूल जाना। CA आमतौर पर आपके सर्टिफिकेट को अपनी रूट की से साइन नहीं करते हैं; वे एक "इंटरमीडिएट" की का उपयोग करते हैं। आपको अक्सर न केवल अपना सर्टिफिकेट, बल्कि CA के इंटरमीडिएट सर्टिफिकेट(्स) को भी सर्व करने की आवश्यकता होती है, जिससे आपके ब्राउज़र द्वारा भरोसेमंद रूट CA तक "ट्रस्ट की चेन" बनती है।
फॉर्मेट्स में भ्रमित होना। एक सर्वर को PKCS#1 की देने की कोशिश करना जब वह PKCS#8 की उम्मीद करता है, या जहाँ PEM फ़ाइल की आवश्यकता होती है, वहाँ DER फ़ाइल का उपयोग करने की कोशिश करना। फॉर्मेट्स को पहचानने और उनके बीच कनवर्ट करने का तरीका जानना एक प्रमुख ट्रबलशूटिंग स्किल है।

यह आपके रडार पर क्यों होना चाहिए

अगर आप वेब सर्वर पर काम करते हैं, एक एप्लिकेशन डिप्लॉय करते हैं, एक API बनाते हैं, या सिर्फ एक फ्रंटएंड कनेक्शन समस्या को डीबग करते हैं, तो आपका सामना सर्टिफिकेट्स से होगा। आधुनिक वेब में, अनएन्क्रिप्टेड HTTP एक तरह से खत्म हो चुका है। HTTPS के ट्रस्ट और एन्क्रिप्शन मॉडल को समझना अब वैकल्पिक नहीं है—यह एक डेवलपर के टूलकिट का एक मूलभूत हिस्सा है। जब पैडलॉक टूट जाता है या कनेक्शन विफल हो जाता है, तो एक की, एक CSR, और एक सर्टिफिकेट के बीच का अंतर जानना—और वे सभी एक साथ कैसे फिट होते हैं—यह पाँच मिनट के फिक्स और पाँच घंटे के आउटेज के बीच का अंतर तय कर सकता है।

और गहराई में जाएं

RFC 5280: Internet X.509 Public Key Infrastructure Certificate: यह डिजिटल सर्टिफिकेट के अंदर क्या होता है, उसके लिए मुख्य तकनीकी स्पेसिफिकेशन है। यह घना है, लेकिन यह सत्य का स्रोत है।
Wikipedia: Public key certificate: X.509 सर्टिफिकेट्स की अवधारणाओं और भूमिका का एक शानदार हाई-लेवल ओवरव्यू।
Mozilla: Server-Side TLS: फ़ायरफ़ॉक्स के निर्माताओं की ओर से आपके सर्वर पर TLS/SSL को कॉन्फ़िगर करने के लिए एक उत्कृष्ट और व्यावहारिक गाइड, जिसमें अनुशंसित सिफरसुइट्स और सर्वोत्तम प्रथाएं शामिल हैं।
Let's Encrypt: How It Works: सबसे लोकप्रिय मुफ्त CA कैसे सर्टिफिकेट्स को वैलिडेट करने और जारी करने की प्रक्रिया को ऑटोमेट करता है, इसकी स्पष्ट व्याख्या।
SSL.com: Demystifying PKCS: विभिन्न PKCS मानकों (PKCS#1, #7, #8, #12, आदि) और प्रत्येक किस लिए है, इसका एक पठनीय विश्लेषण।