eMudhra Intermediate CA कॉम्प्रोमाइज: अपने एनवायरनमेंट में प्रभावित सर्टिफिकेट्स का पता कैसे लगाएं

आपके ब्राउज़र में दिखने वाला हर पैडलॉक भरोसे की एक श्रृंखला (chain of trust) पर निर्भर करता है, और वह श्रृंखला उतनी ही मजबूत होती है जितनी कि उसमें मौजूद सबसे कमजोर प्राइवेट की। इस महीने, ऐसी ही एक श्रृंखला की आठ कड़ियाँ अनुमान लगाने योग्य निकलीं।

आज 26 अक्टूबर, 2026 है। 17 अक्टूबर को, एक रिसर्चर ने रिपोर्ट किया कि एक सर्टिफिकेट अथॉरिटी (CA), eMudhra के आठ intermediate सर्टिफिकेट्स के पीछे की प्राइवेट कीज को रिकवर किया जा सकता है। प्रमुख ब्राउज़र और ऑपरेटिंग सिस्टम वेंडर्स द्वारा इन सर्टिफिकेट्स को रिवोक और ब्लॉक कर दिया गया है। इस समस्या को CVE-2026-111943 और CVE-2026-111944 के रूप में ट्रैक किया जा रहा है। इस सप्ताह सुरक्षा टीमों के लिए तत्काल कार्य कहना आसान और करना थकाऊ है: यह पता लगाना कि क्या इनमें से कोई भी सर्टिफिकेट आपके एनवायरनमेंट में कहीं दिखाई देता है, और क्या आपका कोई सॉफ़्टवेयर अभी भी उन पर भरोसा करता है।

सर्टिफिकेट चेन्स पर एक त्वरित रीफ्रेशर

जब आप HTTPS पर किसी वेबसाइट पर जाते हैं, तो सर्वर दिखाता है एक leaf certificate अपने स्वयं के नाम के लिए। वह सर्टिफिकेट हस्ताक्षरित होता है एक intermediate CAद्वारा, और intermediate हस्ताक्षरित होता है एक root CAद्वारा। आपका ब्राउज़र या ऑपरेटिंग सिस्टम उन roots की एक सूची के साथ आता है जिन पर वह भरोसा करता है, जिसे कहा जाता है एक trust store.

Root keys को ऑफ़लाइन रखा जाता है और कड़ी सुरक्षा में रखा जाता है। Intermediates दैनिक साइनिंग का काम करते हैं। पेंच यह है कि जिसके पास भी किसी intermediate की प्राइवेट की होती है, वह किसी भी नाम के लिए सर्टिफिकेट साइन कर सकता है, और जो क्लाइंट्स उस चेन पर भरोसा करते हैं वे आमतौर पर इसे स्वीकार कर लेंगे। यही कारण है कि एक लीक हुई intermediate key गंभीर होती है, भले ही अभी तक कोई दुर्भावनापूर्ण सर्टिफिकेट न देखा गया हो।

क्या हुआ, जैसा कि रिपोर्ट किया गया

सार्वजनिक प्रकटीकरण और वेंडर राइट-अप के अनुसार, यह घटनाक्रम इस प्रकार है:

• 30 अप्रैल, 2025 को एक की जनरेशन सेरेमनी के दौरान, eMudhra ने 24 सबऑर्डिनेट CAs के लिए कीज बनाईं।
• wrap/unwrap चरण में एक खामी के कारण कमजोर P-384 कीज का दूसरा सेट तैयार हो गया। P-384 एक एलिप्टिक कर्व है जिसे बहुत बड़ा की स्पेस प्रदान करना चाहिए।
• गलती से उन कमजोर कीज का उपयोग आठ intermediate सर्टिफिकेट्स के लिए किया गया। उनकी प्रभावी यादृच्छिकता (entropy) लगभग 3 से 8 बिट्स रिपोर्ट की गई थी, जिसका अर्थ है अधिकतम केवल कुछ सौ संभावित कीज। किसी कंप्यूटर के लिए उन्हें रिकवर करना बेहद आसान है।
• आठ में से छह TLS intermediates हैं और दो code-signing intermediates हैं।

प्रतिक्रिया, जैसा कि रिपोर्ट किया गया:

• Chrome, Mozilla और Apple ने छह TLS intermediates को ब्लॉक कर दिया। Microsoft ने दो code-signing intermediates को ब्लॉक कर दिया।
• Google ने Chrome Root Store से emSign ECC Root CA - G3 को हटा दिया, और Mozilla ने intermediates को साइन करने वाले root से ट्रस्ट हटा दिया।
• eMudhra ने आठों सर्टिफिकेट्स को रिवोक कर दिया और अपने G3 root के तहत जारी करना बंद कर दिया। इसका कहना है कि उसकी root प्राइवेट कीज और अन्य intermediates प्रभावित नहीं हैं, यह मुद्दा केवल उसके वैश्विक वेबसाइट-सुरक्षा व्यवसाय तक सीमित है और उसकी भारतीय DSC तथा eSign सेवाओं तक नहीं, और प्रभावित intermediates में से केवल एक का उपयोग प्रोडक्शन में किया गया था, जिनमें से किसी ने भी वेबसाइटों या अंतिम उपयोगकर्ताओं को सर्टिफिकेट जारी नहीं किए।

वेंडर के बयानों को उसका अपना पक्ष मानें। आपका काम इस घटना का आकलन करना नहीं बल्कि अपने स्वयं के जोखिम (exposure) की पुष्टि करना है।

किसे सबसे पहले जांच करनी चाहिए

यदि आप निम्न में आते हैं, तो आपको इसे अपनी प्राथमिकता सूची में सबसे ऊपर रखना चाहिए:

• इंटरनेट-फेसिंग वेबसाइट्स, APIs, VPNs या अन्य TLS सेवाएं चलाते हैं।
• eMudhra या emSign पदानुक्रमों (hierarchies) के माध्यम से सार्वजनिक रूप से विश्वसनीय सर्टिफिकेट खरीदते हैं।
• हस्ताक्षरित सॉफ़्टवेयर शिप करते हैं जो सार्वजनिक code-signing सर्टिफिकेट्स पर निर्भर करता है।
• Go में लिखे गए एप्लिकेशन बनाते या चलाते हैं।
• ऐसे लीगेसी सिस्टम्स, अनमैनेज्ड एंडपॉइंट्स, एप्लायंसेज या कस्टम trust stores की देखरेख करते हैं जिन्हें अपने आप distrust अपडेट प्राप्त नहीं होते हैं।

आठ प्रभावित intermediates

SHA-256 फ़िंगरप्रिंट और सीरियल नंबर किसी सर्टिफिकेट का मिलान करने के सबसे विश्वसनीय तरीके हैं। नामों की नकल की जा सकती है; फ़िंगरप्रिंट्स की नहीं।

सर्टिफिकेट	प्रकार	सीरियल नंबर	SHA-256 फ़िंगरप्रिंट
EM EV TLS CA - G3B (eMudhra BV)	TLS	c7c41efe92d825f05eae841a4a82c1	E7568FE6E12331F4FD7DE61DA4C7559D0F8EB192A218D4741A3BA75184333838
EM OV TLS CA - G3B (eMudhra BV)	TLS	6cada367fb1c100088120ea202d568	98B896625C0C230ADEEC3EB2CF6AAD5001ECF9156A68644E82374CE5833BC25B
EM DV TLS CA - G3B (eMudhra BV)	TLS	a4aee678f23362b4c0e460b772f214	42C4ACCD12C4F59597925E1A08A7A90102608543809308D50EC427E118BA1493
EM EV TLS CA - G3C (eMudhra Inc)	TLS	8009928a64107601af05fa2f19f109	432EC25F0D28DE9006D97BF752F17BBB2CD41F669933FCB072D9A1148D0261F3
EM OV TLS CA - G3C (eMudhra Inc)	TLS	296926c227a3a1526392b19482a504	CB6E15165AC802E9B3F993F16C25D41F4E81C21EBDE71AE1B012AC00BF9C7C3F
EM DV TLS CA - G3C (eMudhra Inc)	TLS	588b2e3c2bb8cda13e1a1209254321	0164D7CEAE5BB909C272AF151FF44B1177AE9B47D9424B94F1D9558C30934D19
EM OV CS CA - G3B (eMudhra BV)	Code signing	7818933f8f85b4619a2b35fba83d0a	9E39DE2881273ACC225A149C72BA3E0F51424963669AB633EE1DC7DF5DB067B4
EM OV CS CA - G3C (eMudhra Inc)	Code signing	544b7f922c31ae220a4a922916f6e6	4B2460A466F95FD40113BCDCCA2CEB29B3B093921DE45474DA7DF48874C630B1

उन्हें कैसे खोजें: चरण-दर-चरण जांच

जोखिम (exposure) के दो पहलू हैं। एक यह कि आपके सर्वर क्या प्रस्तुत करते हैं। दूसरा यह कि आपका सॉफ़्टवेयर अभी भी किस पर भरोसा करता है। नीचे दिए गए चरण दोनों को कवर करते हैं, पहले सामान्य ओपन-सोर्स टूल्स के साथ और फिर उन टीमों के लिए एक कमर्शियल स्कैनर के साथ जिनके पास पहले से यह मौजूद है।

चरण 1: TLS का उपयोग करने वाली हर चीज़ की एक सूची बनाएं

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

चरण 2: प्रत्येक सर्वर द्वारा प्रस्तुत की जाने वाली चेन की जांच करें

किसी भी एकल होस्ट के लिए, OpenSSL चेन में मौजूद प्रत्येक सर्टिफिकेट को उसके subject, issuer, serial और fingerprint के साथ प्रिंट कर सकता है। बदलें app.example.com को अपने स्वयं के होस्ट से:

HOST=app.example.com
echo | openssl s_client -connect "$HOST:443" -servername "$HOST" -showcerts 2>/dev/null \
  | awk '/-----BEGIN CERTIFICATE-----/{n++; f=1} f{print > ("chain-" n ".pem")} /-----END CERTIFICATE-----/{f=0}'

for f in chain-*.pem; do
  openssl x509 -in "$f" -noout -subject -issuer -serial -fingerprint -sha256
  echo
done

OpenSSL सीरियल्स को अपर केस में और फ़िंगरप्रिंट्स को कोलन के साथ प्रिंट करता है, इसलिए केस या कोलन की चिंता किए बिना तुलना करें। आठ की सूची के विरुद्ध एक त्वरित मिलान:

for f in chain-*.pem; do
  openssl x509 -in "$f" -noout -fingerprint -sha256 | cut -d= -f2 | tr -d ':'
done | grep -i -E 'E7568FE6|98B89662|42C4ACCD|432EC25F|CB6E1516|0164D7CE|9E39DE28|4B2460A4' \
  && echo "MATCH: affected intermediate found" || echo "No affected intermediate in this chain"

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

चरण 3: यदि आप वल्नेरेबिलिटी स्कैनर चलाते हैं तो बड़े पैमाने पर खोजें

यदि आपका संगठन पहले से ही Certificate View के साथ Qualys VMDR का उपयोग करता है, तो Qualys ने तैयार क्वेरीज़ प्रकाशित की हैं। Certificate View में, जारीकर्ता के नाम पर एक खोज सभी आठ को कवर करती है:

certificate:(issuer.name:[`EM EV TLS CA – G3B`, `EM OV TLS CA – G3B`, `EM DV TLS CA – G3B`, `EM EV TLS CA – G3C`, `EM OV TLS CA – G3C`, `EM DV TLS CA – G3C`, `EM OV CS CA – G3B`, `EM OV CS CA – G3C`])

एक व्यापक जांच प्रभावित intermediates पर नामित दो eMudhra संगठनों के तहत जारी किए गए प्रत्येक सर्टिफिकेट को सूचीबद्ध करती है:

certificate:(issuer.organization:`eMudhra BV` or issuer.organization:`eMudhra Inc`)

Qualys प्रभावित Go वर्जन्स के लिए QID 5019897 और QID 48395 भी सूचीबद्ध करता है, जो एक जानकारी एकत्र करने वाली जांच है जो आठ intermediates वाली चेन्स की गणना करती है। इन पर भरोसा करने से पहले सुनिश्चित करें कि आपके एजेंट्स के पास नवीनतम सिग्नेचर हैं। क्वेरी टोकन केस-सेंसिटिव होते हैं, इसलिए यदि किसी क्वेरी में त्रुटि आती है तो प्रोडक्ट हेल्प देखें। अन्य स्कैनर्स के अपने समकक्ष होंगे; तालिका में दिए गए फ़िंगरप्रिंट किसी भी टूल के साथ काम करते हैं।

चरण 4: ऐसे Go प्रोग्राम खोजें जो अभी भी अमान्य चेन्स पर भरोसा करते हैं

यह वह हिस्सा है जिसे लोग अक्सर छोड़ देते हैं। आपके सर्वर सुरक्षित हो सकते हैं, लेकिन आपके अपने एप्लिकेशन अभी भी जाली सर्टिफिकेट स्वीकार कर सकते हैं। एडवाइजरी के अनुसार, Go 1.27.3 और 1.26.10 उन चेन्स को ब्लॉक करते हैं जिनमें आठ कीज में से कोई भी शामिल हो (CVE-2026-111943)। Go प्रोग्राम अपना स्वयं का सर्टिफिकेट वेरिफिकेशन कोड रखते हैं, इसलिए पुराने Go के साथ बनाया गया प्रोग्राम तब तक पुराना व्यवहार बनाए रखता है जब तक कि उसे दोबारा न बनाया जाए।

बिल्ड मशीनों पर टूलचेन की जांच करें:

go version

जांचें कि आपके द्वारा पहले से चलाए जा रहे बाइनरी को किस Go वर्जन ने बनाया है:

go version /usr/local/bin/your-service

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

चरण 5: बदलें, अपडेट करें और निगरानी जारी रखें

• पहले बदलें। कोई भी लीफ सर्टिफिकेट जिसकी चेन में इन आठ में से कोई एक शामिल है, उसे किसी अन्य विश्वसनीय CA द्वारा फिर से जारी किया जाना चाहिए और सही चेन के साथ फिर से डिप्लॉय किया जाना चाहिए।
• अपडेट करें। OS सुरक्षा अपडेट लागू करें और Go रनटाइम्स को फिक्स्ड रिलीज़ पर ले जाएं।
• पुष्टि करें कि रिवोकेशन जांच काम कर रही है। रिवोकेशन केवल उन क्लाइंट्स की मदद करता है जो वास्तव में इसकी जांच करते हैं। कस्टम trust stores, एप्लायंसेज और पुराने Java या एम्बेडेड सिस्टम्स में intermediates को हटाने या मैन्युअल रूप से स्पष्ट रूप से अविश्वास (distrusted) करने की आवश्यकता हो सकती है।
• निगरानी जारी रखें। अपनी खोजों को एक शेड्यूल्ड जॉब या डैशबोर्ड के रूप में सहेजें और हर स्कैन के बाद उन्हें तब तक दोबारा चलाएं जब तक कि परिणाम पूरी तरह सुरक्षित न रहें।

निष्कर्ष

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

फायदे

• प्रभावित सर्टिफिकेट्स सटीक फ़िंगरप्रिंट्स के साथ एक संक्षिप्त, निश्चित सूची हैं, इसलिए मिलान बिल्कुल सटीक है।
• प्रमुख ब्राउज़रों और ऑपरेटिंग सिस्टम्स ने उन्हें पहले ही ब्लॉक कर दिया है, जो अधिकांश रोज़मर्रा के उपयोगकर्ताओं को अपने आप सुरक्षित करता है।
• मुफ़्त टूल्स जैसे OpenSSL और go version बुनियादी जांच के लिए पर्याप्त हैं।
• मौजूदा स्कैनर्स इस खोज को एक पुनरावृत्ति योग्य डैशबोर्ड में बदल सकते हैं।
• यह अभ्यास भविष्य की घटनाओं के लिए आपकी सर्टिफिकेट इन्वेंटरी को बेहतर बनाता है।

कमियां

• कस्टम या फ़्रोज़न trust stores वाले सिस्टम्स को मैन्युअल काम के बिना वेंडर ब्लॉकलिस्ट से लाभ नहीं मिलता है।
• Go बाइनरीज़ को फिर से बनाना होगा; केवल टूलचेन को अपडेट करने से पहले से डिप्लॉय किए गए प्रोग्राम ठीक नहीं होते हैं।
• नेटवर्क स्कैन उन होस्ट्स को छोड़ देते हैं जिन तक वे नहीं पहुंच सकते, इसलिए एजेंट कवरेज या मैन्युअल जांच की आवश्यकता होती है।
• उन क्लाइंट्स पर रिवोकेशन अविश्वसनीय है जो इसकी जांच नहीं करते हैं।
• एप्लायंसेज और थर्ड-पार्टी होस्टेड साइट्स पर सर्टिफिकेट्स को बदलने में समय और वेंडर की मदद लग सकती है।

सावधानी

यह लेख शिक्षा और सामान्य मार्गदर्शन के लिए है। होस्ट नाम जैसे app.example.com और पाथ जैसे /usr/local/bin/your-service प्लेसहोल्डर्स हैं जिन्हें आपको अपने स्वयं के अनुसार बदलना होगा। घटना का विवरण ऊपर दी गई तिथि के अनुसार सार्वजनिक रिपोर्टों और वेंडर बयानों से संक्षेपित किया गया है और इसमें बदलाव हो सकता है; अपने ब्राउज़र, ऑपरेटिंग सिस्टम, Go और स्कैनर वेंडर्स की नवीनतम एडवाइजरी देखें, और किसी भी मिलान पर कार्रवाई करने से पहले एक आधिकारिक स्रोत के विरुद्ध प्रत्येक फ़िंगरप्रिंट को सत्यापित करें।

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

• eMudhra intermediate CA कॉम्प्रोमाइज क्या है? — आठ eMudhra intermediate सर्टिफिकेट्स कमजोर P-384 कीज के साथ बनाए गए थे जिनकी प्राइवेट कीज को रिकवर किया जा सकता था, इसलिए अक्टूबर 2026 में प्रमुख वेंडर्स द्वारा उन्हें रिवोक और ब्लॉक कर दिया गया।
• कौन से CVEs इस मुद्दे को ट्रैक करते हैं? — इसे CVE-2026-111943 और CVE-2026-111944 के रूप में ट्रैक किया गया है; प्रभावित चेन्स को ब्लॉक करने वाला Go फिक्स CVE-2026-111943 के तहत सूचीबद्ध है।
• क्या भारतीय DSC और eSign सर्टिफिकेट्स प्रभावित हैं? — eMudhra का कहना है कि यह मुद्दा केवल उसके वैश्विक वेबसाइट-सुरक्षा व्यवसाय तक सीमित है और उसकी भारतीय DSC और eSign सेवाओं को प्रभावित नहीं करता है।
• मैं कैसे जांचूं कि क्या मेरी वेबसाइट प्रभावित intermediate का उपयोग करती है? — इसके साथ चेन प्राप्त करें openssl s_client -showcerts, प्रत्येक सर्टिफिकेट का SHA-256 फ़िंगरप्रिंट प्रिंट करें, और ऊपर सूचीबद्ध आठ फ़िंगरप्रिंट्स के साथ इसकी तुलना करें।
• Go एप्लिकेशन्स को विशेष ध्यान देने की आवश्यकता क्यों है? — Go प्रोग्राम अपनी स्वयं की सर्टिफिकेट जांच करते हैं, इसलिए प्रभावित चेन्स को अस्वीकार करने के लिए उन्हें Go 1.27.3 या 1.26.10 (या बाद के फिक्स्ड रिलीज़) के साथ दोबारा बनाया जाना चाहिए।
• क्या सुरक्षित रहने के लिए रिवोकेशन ही काफी है? — हमेशा नहीं, क्योंकि कुछ क्लाइंट्स कभी भी रिवोकेशन की जांच नहीं करते हैं; कस्टम trust stores और पुराने सिस्टम्स में सर्टिफिकेट्स को मैन्युअल रूप से हटाने या अविश्वास (distrusted) करने की आवश्यकता हो सकती है।
• यदि मुझे कोई प्रभावित सर्टिफिकेट मिलता है तो मुझे क्या करना चाहिए? — किसी अन्य विश्वसनीय CA से लीफ सर्टिफिकेट को फिर से जारी करवाएं, इसे सही चेन के साथ डिप्लॉय करें, और पुष्टि करने के लिए फिर से स्कैन करें कि पुरानी चेन हट गई है।
• क्या मैं इसके लिए वल्नेरेबिलिटी स्कैनर का उपयोग कर सकता हूँ? — हाँ; Qualys Certificate View जैसे टूल्स जारीकर्ता और सीरियल खोज प्रदान करते हैं, और कोई भी स्कैनर जो सर्टिफिकेट फ़िंगरप्रिंट्स रिकॉर्ड करता है, यहाँ सूचीबद्ध आठों का मिलान कर सकता है।

टैग्स

#eMudhra #CertificateAuthority #TLS #PKI #CVE2026111943 #CyberSecurity #GoLang #VulnerabilityManagement #CodeSigning #Qualys