eMudhra انٹرمیڈیٹ CA سمجھوتہ: اثر اور تدارک گائیڈ

ذرائع نے 22 اکتوبر 2026 کو بیجنگ وقت کی جانچ کی۔ سامعین: انفرادی صارفین، ویب سائٹ آپریٹرز، ڈویلپرز، اور سسٹم ایڈمنسٹریٹرز۔

سنگین کمزوریوں نے eMudhra/emSign انٹرمیڈیٹ CA نجی کلیدوں کے ایک گروپ کو قابل بازیافت بنا دیا۔ یہ ان کلائنٹس کو متاثر کرتا ہے جو ویب سائٹس، APIs اور سافٹ ویئر کی تصدیق کے لیے پبلک سرٹیفکیٹ سسٹم کا استعمال کرتے ہیں۔ عوامی اعتماد بڑے آپریٹنگ سسٹمز پر محیط ہے، لیکن سمجھوتہ شدہ کلیدوں کا سیٹ اور کلائنٹ کے ممکنہ اثرات مختلف دائرہ کار ہیں۔ 15

مرکزی متن متعلقہ ذرائع کو نمبر دینے کے لیے مربع بریکٹ کا استعمال کرتا ہے، اور تمام بیرونی حوالہ جات ضمیمہ میں درج ہیں۔ درج کردہ ورژن ورژن کی بیس لائن ہے جس کی تصدیق کی تاریخ کے مطابق اس واقعے کی درستگی کی تصدیق کی گئی ہے۔ تعیناتی کرتے وقت، اسی معاون برانچ میں اپ ڈیٹ شدہ مستحکم ورژن کو ترجیح دی جاتی ہے۔

TL;DR

Eight انٹرمیڈیٹ CA نجی کلیدوں سے سمجھوتہ ہونے کی تصدیق ہوگئی ہے۔ موجودہ رپورٹس یہ ثابت نہیں کرتی ہیں کہ روٹ پرائیویٹ کیز یا عام طور پر HTTPS کرپٹوگرافی کو توڑ دیا گیا ہے۔ اپ ڈیٹس زیادہ تر عوامی اعتماد کے ماحولیاتی نظام پر محیط ہیں۔ بقایا خطرہ اصل درخواست پر منحصر ہے۔15

1. انفرادی صارفین: براؤزرز، آپریٹنگ سسٹمز، اور حفاظتی اجزاء کو اپ ڈیٹ کریں۔ Android پر، Google Play سروسز کو بھی اپ ڈیٹ کریں۔ Firefox Android 158.0.2 یا بعد کا استعمال کریں۔ 12
2. Servers: تقسیم کے ca-certificates/NSS پیکجز کو اپ ڈیٹ کریں اور ایپلیکیشن بنڈل ٹرسٹ اسٹورز کو چیک کریں۔ صرف میزبان کو اپ ڈیٹ کرنا ناکافی ہے۔ 7810
3. ترقیاتی ماحول: Node 24 کو 24.22.1 سے اپ ڈیٹ کریں یا اس برانچ میں جیسا کہ قابل اطلاق ہو اس کی نئی ریلیز۔ Python ماحول میں، کم از کم pip 26.2.2، certifi 2026.10.19، اور uv 0.13.4 میں اپ ڈیٹ کریں۔ فکسڈ Go بائنریز حاصل کریں یا انہیں دوبارہ بنائیں؛ اس کے وینڈر کی ایڈوائزری کے مطابق Java کو اپ ڈیٹ کریں۔ 12–15
4. اپ ڈیٹس کو فعال کریں: متاثرہ خدمات کو دوبارہ شروع کریں اور کنٹینرز کو دوبارہ بنائیں اور دوبارہ تعینات کریں۔ Cloudflare Tunnel کے لیے، cloudflared کو 2026.10.2 یا بعد میں اپ ڈیٹ کریں۔ 7
5. ویب سائٹ کے سرٹیفکیٹس: کسی متاثرہ چین کو تبدیل کریں اگر اس میں منسوخ یا بلاک شدہ انٹرمیڈیٹ CA ہے، یا کسی غیر معتبر جڑ پر انحصار کرتا ہے۔ سرٹیفکیٹ دوبارہ جاری کرنا کلائنٹ ٹرسٹ اسٹورز کو اپ ڈیٹ کرنے کی جگہ نہیں لے گا۔ 158
6. تصدیق: ہر درخواست کے اصل TLS راستے کی جانچ کریں۔ ٹائم آؤٹ اور DNS ناکامیوں سے سرٹیفکیٹ مسترد ہونے میں فرق کریں۔ سرٹیفکیٹ کی تصدیق کو فعال رکھیں؛ -k استعمال نہ کریں یا غلطیوں کو دبانے کے لیے تصدیق کو چھوڑ دیں۔ 7

1 واقعے کے حقائق اور اسباب

تصدیق شدہ حقائق

Mozilla اور Google نے آٹھ eMudhra انٹرمیڈیٹ CA نجی کلیدوں میں نقائص کی تصدیق کی ہے۔ محقق نے نجی کلیدی کنٹرول کا ثبوت فراہم کیا؛ Mozilla نے آزادانہ طور پر چابیاں بازیافت کیں اور مسئلے کو دوبارہ پیش کیا۔ چھ انٹرمیڈیٹ CAs TLS اور دو سرو کوڈ پر دستخط کرتے ہیں۔ 25

خرابی پیدا شدہ کیز میں ہے: یہ انٹرمیڈیٹ CAs P-384 وکر کا استعمال کرتے ہیں، لیکن ان کی پرائیویٹ کیز 256 سے کم عدد کے ہوتے ہیں۔ یہ مطلوبہ بڑی رینج سے بے ترتیب طور پر چابیاں منتخب کرنے سے بہت دور ہے۔ ان کمزور کلیدوں کو بازیافت کرنا یہ ظاہر نہیں کرتا ہے کہ صحیح طریقے سے تیار کردہ P-384 کیز کو توڑا جا سکتا ہے۔ 2

یہاں “سرٹیفکیٹ کریک ہو گیا ہے” کو درست طریقے سے سمجھنا چاہیے کیونکہ “متعلقہ نجی کلید کو بازیافت کیا جا سکتا ہے”۔ سرٹیفکیٹ اور اس میں عوامی کلید فطری طور پر عوامی ہیں۔ جس چیز کو واقعی خفیہ رکھنے کی ضرورت ہے وہ نجی کلید ہے جو ایک درست دستخط پیدا کر سکتی ہے۔

کلیدی نسل کے عمل کے مسائل ابھی زیر تفتیش ہیں۔

eMudhra کی ابتدائی تفصیل اپریل 2025 میں ایک کلیدی جنریشن تقریب میں مسئلہ کا پتہ دیتی ہے۔ وضاحت میں کلیدی انکیپسولیشن اور ڈیکیپسولیشن مرحلہ شامل ہے: اصل مضبوط کلید کے علاوہ، کمزور کلیدوں کا ایک اور سیٹ ظاہر ہوتا ہے، اور کمزور کلیدوں کو بعد میں سرٹیفکیٹ کی درخواست اور جاری کرنے کے لیے استعمال کیا جاتا ہے۔ کمپنی نے اب بھی کہا کہ اصل وجہ کا حتمی طور پر تعین نہیں کیا گیا ہے۔ 6

لہٰذا، جس چیز کا تعین کیا جا سکتا ہے وہ یہ ہے کہ یہ کلیدیں بہت کمزور ہیں اور ان سے سمجھوتہ کیا گیا ہے۔ ناکامی کو مزید بیان نہیں کیا جا سکتا کیونکہ HSM کا ایک مخصوص ہارڈ ویئر رینڈم نمبر سورس ناقص ثابت ہوا ہے، اور نہ ہی اسے RSA، ECC یا TLS کی عام کرپٹوگرافک پیش رفت کے طور پر بیان کیا جا سکتا ہے۔

روٹ سرٹیفکیٹ عدم اعتماد کا کیا مطلب ہے؟

براؤزر یا آپریٹنگ سسٹم متاثرہ انٹرمیڈیٹ CA کے سرٹیفکیٹ یا عوامی کلید کو براہ راست بلاک کر سکتا ہے، یا یہ ان کی طرف جانے والے روٹ ٹرسٹ کو ہٹا سکتا ہے۔ مؤخر الذکر اقدام اسی جڑ کے تحت کچھ جائز سرٹیفکیٹس کو بھی مسترد کردے گا۔

Google نے Chrome روٹ اسٹور کے صارفین کی حفاظت کے لیے emSign ECC Root CA - G3 کو ہٹانے کا شیڈول بنایا ہے جنہیں CRLSet سے اپ ڈیٹس موصول نہیں ہوتے ہیں۔ بیجنگ کے وقت 27 سے 28 اکتوبر تک اسی مدت کے دوران روٹ اسٹور کو ہٹانے کی توقع ہے۔ Google کا اصل وقت 27 اکتوبر کی صبح ہے، یو ایس پیسفک ڈے لائٹ ٹائم۔ یہ منصوبہ ہنگامی پبلک کلید بلاک کرنے سے الگ ہے جو پہلے تعینات کی گئی تھی۔ 1

جڑ پر اعتماد کرنا ایک ردعمل کا پیمانہ ہے۔ یہ خود ثابت نہیں کرتا کہ روٹ پرائیویٹ کلید سے سمجھوتہ کیا گیا تھا۔

2 کیوں ممکنہ اثر عوامی اعتماد کے ماحولیاتی نظام پر محیط ہے۔

سمجھوتہ شدہ کلیدیں اور متاثرہ اعتماد کے راستے

فیصلے کا اعتراض	اس واقعہ کی وسعت
پریشانی والی کلید کی نشاندہی کی گئی۔	eMudhra کے لیے 8 انٹرمیڈیٹ CA نجی کلیدیں
پلیٹ فارمز جن پر کارروائی کی ضرورت ہو سکتی ہے۔	پبلک روٹ اسٹور، براؤزر، آپریٹنگ سسٹم، لینگویج رن ٹائم، سافٹ ویئر پیکج اور کنٹینر ایکو سسٹم
ممکنہ طور پر نقالی شناخت TLS	کلائنٹس کے ذریعے ملاحظہ کی گئی ویب سائٹس یا خدمات جو اب بھی متعلقہ جعلی سرٹیفکیٹ چین کو قبول کرتی ہیں۔
کیا اس کا مطلب یہ ہے کہ تمام آلات سے سمجھوتہ کیا گیا ہے؟	نہیں؛ اعتماد کی شرائط، حملہ آور کے نیٹ ورک کا مقام، اور دیگر تصدیقی حکمت عملی استحصال کا تعین کرتی ہے۔
کیا اس کا مطلب یہ ہے کہ تمام قانونی سرٹیفکیٹ باطل ہیں؟	نہیں؛ متعلقہ باطل کا انحصار اس بات پر ہوتا ہے کہ کلائنٹ کو کن جڑوں یا سرٹیفکیٹ چینز پر اعتماد نہیں ہے۔

Red Hat استحصال کو واضح طور پر ان شرائط تک محدود کرتا ہے جہاں کلائنٹ اب بھی متعلقہ سلسلہ کو قبول کرتا ہے، حملہ آور کے پاس سمجھوتہ شدہ نجی کلید ہوتی ہے، اور وہ نیٹ ورک میں کنکشن کو روکنے کے قابل ہوتا ہے۔ خطرے کی کوریج کو ہونے والے حملوں کی تعداد کے ساتھ الجھن میں نہیں ڈالنا ہے۔ 10

دیگر CA استعمال کرنے والی ویب سائٹس بھی نقالی کی جا سکتی ہیں۔

فرض کریں کہ ایک ویب سائٹ اصل میں Let’s Encrypt سرٹیفکیٹ استعمال کرتی ہے، اور وزیٹر کا کلائنٹ ایک ہی وقت میں متعدد عوامی CA پر بھروسہ کرتا ہے۔ ایک حملہ آور اسی ڈومین نام کے لیے دوسرا سرٹیفکیٹ بنانے کے لیے سمجھوتہ شدہ انٹرمیڈیٹ CA استعمال کرنے کی کوشش کر سکتا ہے۔ کلائنٹس کو عام طور پر پیشگی ضرورت نہیں ہوتی ہے کہ ڈومین کا نام صرف Let’s Encrypt استعمال کر سکتا ہے۔ اگر جعلی سلسلہ اب بھی قبول کیا جاتا ہے، جو CA ویب سائٹ اصل میں استعمال کرتی ہے، اس طرح کے حملوں کو مسترد کرنے کے لیے کافی نہیں ہے۔ 8

یہ طریقہ کار وضاحت کرتا ہے: ایک اور CA سرٹیفکیٹ جو کہ اصل میں نارمل تھا کو تبدیل کرنے سے سمجھوتہ شدہ CA پر کلائنٹ کا اعتماد خود بخود ٹھیک نہیں ہوگا۔ جس چیز کو واقعی منقطع کرنے کی ضرورت ہے وہ ہے گاہکوں کے لیے جعلی شناختوں کو قبول کرنے کا راستہ۔

تینوں اثرات کو الگ الگ نمٹانے کی ضرورت ہے۔

شناخت کی نقالی کا خطرہ: کلائنٹس جنہوں نے متعلقہ سلسلہ کو بلاک نہیں کیا ہے وہ حملہ آور کی جعلی شناخت کو قبول کر سکتے ہیں، جس کی وجہ سے حساس درخواستیں جعلی سروسز کو بھیجی جا سکتی ہیں۔

جائز خدمات کی دستیابی کا خطرہ: روٹ ٹرسٹ کو ہٹانا بصورت دیگر جائز ویب سائٹس کے لیے سرٹیفکیٹ کی خرابیوں کا سبب بن سکتا ہے، جس کو کسی اور قبول شدہ سلسلہ میں منتقلی کی ضرورت پڑ سکتی ہے۔

تعیناتی کوریج کا خطرہ: آپریٹنگ سسٹم کو ٹھیک کیا جا سکتا ہے جبکہ ایپلیکیشن بنڈل ٹرسٹ اسٹور، ورچوئل ماحول، پرانی کنٹینر امیج، یا مرتب کردہ پروگرام پرانے توثیق کے رویے کو برقرار رکھتا ہے۔

یہ تینوں دائرہ کار ایک جیسے نہیں ہیں۔ Cloudflare کا جواب ریموٹ شناخت کی توثیق، مشترکہ ٹرسٹ اسٹورز، بیس امیجز، اور انفرادی ایپلیکیشنز کا احاطہ کرتا ہے، یہ واضح کرتا ہے کہ آخر الذکر دو کاموں کو الگ الگ کیوں سنبھالنا چاہیے۔ 7

3 متاثرہ CA اور سرٹیفکیٹ فراہم کرنے والے

فراہم کنندہ اور اثر کی قسم

فراہم کنندہ یا نظام	اس واقعہ میں کردار	حدود جن کی تمیز کی ضرورت ہے۔
eMudhra／emSign	انٹرمیڈیٹ CA نجی کلید سے براہ راست سمجھوتہ کیا گیا ہے۔	آپ تمام eMudhra روٹس اور تمام سرٹیفکیٹس کو کریکڈ کے طور پر نہیں لکھ سکتے
Sectigo متعلقہ کراس دستخطی سلسلہ	A کراس سرٹیفکیٹ متاثرہ عوامی کلیدوں کے اسی بیچ کے لیے جاری کیا گیا تھا، جو ایک اور اعتماد کا راستہ بناتا ہے۔	متعلقہ کراس سرٹیفکیٹ یا عوامی کلید کو مسدود کرنے کی ضرورت ہے۔ Sectigo روٹ پرائیویٹ کلید کا سمجھوتہ ہونا ثابت نہیں ہوا ہے۔
Internet2/InCommon کے لیے متعلقہ سرٹیفکیٹ لیولز	کچھ جائز سرٹیفکیٹس emSign ECC جڑ کو ہٹانے کے لیے انحصار کرتے ہیں، جس میں منتقلی شامل ہے۔	یہ جڑ کے عدم اعتماد کا ایک ضمنی اثر ہے اور اسے ان 8 کمزور کلیدوں کے درمیان شمار نہیں کیا جا سکتا CA
Let’s Encrypt، DigiCert، Google Trust Services، GlobalSign، وغیرہ۔	اس رپورٹ میں اس پارٹی کے طور پر درج نہیں ہے جس کی نجی کلید سے سمجھوتہ کیا گیا تھا۔	جائز سرٹیفکیٹ یکساں طور پر باطل نہیں ہوتے ہیں۔ کمزور کلائنٹس اب بھی جعلی سرٹیفکیٹ قبول کر سکتے ہیں جو وہ ویب سائٹس کی نقالی کرتے ہیں۔
CDN، کلاؤڈ پلیٹ فارم، سرٹیفکیٹ ڈیلر	اصل اور API سے جڑتے وقت ممکنہ طور پر متعلقہ سرٹیفکیٹ فراہم کریں یا عوامی ٹرسٹ اسٹور کا استعمال کریں	اصل سرٹیفکیٹ چین اور تصدیق کنندہ کو چیک کرنے کے لیے، صرف پلیٹ فارم یا پروڈکٹ کا نام نہ دیکھیں

Mozilla کا نوٹس سمجھوتہ شدہ کلیدوں اور Sectigo کراس دستخطوں کو دستاویز کرتا ہے۔ Google کی عوامی واقعہ کی بحث جائز Internet2/InCommon درجہ بندی کی منتقلی سے خطاب کرتی ہے۔ 25 Cloudflare ایڈریس سروس اور کلائنٹ کے اعتماد کو ٹھیک کرتا ہے۔ وہ Cloudflare کی اپنی CA نجی کلیدوں کے سمجھوتے کی نشاندہی نہیں کرتے ہیں۔ 7

TLS سرٹیفکیٹ چین اور کراس دستخط

مندرجہ ذیل رشتہ اس بار صرف TLS متعلقہ راستوں کی وضاحت کرتا ہے۔ اس میں کوڈ پر دستخط کرنے والے راستے شامل نہیں ہیں، اور نہ ہی اس کا مطلب یہ ہے کہ یہ راستے اب بھی تمام پلیٹ فارمز پر قابل بھروسہ ہیں۔ 17

emSign Root TLS CA - G3 متاثرہ TLS انٹرمیڈیٹس کا ایک براہ راست جاری کنندہ ہے اور خود کچھ اسٹورز میں ٹرسٹ اینکر ہوسکتا ہے۔ emSign ECC Root CA - G3 ایک اور کراس سائننگ پرت فراہم کرتا ہے۔ Sectigo کا AAA Certificate Services اسی انٹرمیڈیٹ CA پبلک کیز کا ایک اضافی راستہ بناتا ہے۔ 17

لہذا، مرمت کرتے وقت دو مختلف گرانولریٹیز ہیں:

• عین درمیانی CA یا عوامی کلید کو مسدود کریں: یہ ایک ہی جڑ کے تحت دیگر جائز درجہ بندیوں کو محفوظ رکھ سکتا ہے، جہاں توثیق کنندہ اس طریقہ کار کی حمایت کرتا ہے۔
• جڑ سے بھروسہ ہٹائیں: یہ کلائنٹس کو انٹرمیڈیٹ CA بلاک کرنے کی صلاحیتوں کے بغیر تحفظ دے سکتا ہے، لیکن مطابقت کو متاثر کر سکتا ہے۔ دوسرے تمام راستے جنہیں کلائنٹ قبول کرتا ہے ان کا بھی احاطہ کیا جانا چاہیے۔ 5

“تمام Sectigo/eMudhra جڑوں کو حذف کریں” کو ایک اندھا دھند عام اقدام کے طور پر نہیں لیا جانا چاہئے، اور نہ ہی اس سے ملتے جلتے نام کے سرٹیفکیٹ کو حذف کرنے کا مطلب یہ ہے کہ تمام راستے بند ہیں۔

4 آپریٹنگ سسٹم اور براؤزر کوریج

مرکزی پلیٹ فارم

پلیٹ فارم	معروف مزاج	اسکوپ جسے استعمال کرتے وقت چیک کیا جانا چاہیے۔
Windows اور Windows Server	Microsoft تقسیم خودکار سرٹیفکیٹ ٹرسٹ لسٹ اپ ڈیٹ کے ذریعے بلاک کر دی گئی	آیا آلہ کو اپ ڈیٹ موصول ہوا ہے؛ اسٹینڈ اسٹون CA bundle ضروری نہیں کہ Windows کا تصدیقی راستہ استعمال کرے۔
macOS, iOS, iPadOS, وغیرہ Apple پلیٹ فارم	واقعہ کے کوآرڈینیٹر نے تصدیق کی کہ Apple نے متعلقہ ناکہ بندی کی ہے	ہر پرانے ورژن اور فریق ثالث ایپ کو ایک جیسی کوریج ملنے کی ضمانت نہیں ہے۔
Android	Google Google Play سروس کے ذریعے مساوی بلاکس تقسیم کرتا ہے۔	ROM Google Play سروس کے بغیر مینوفیکچرر کے اعلان کے مطابق تصدیق کی جانی چاہیے۔ اضافی تصدیق کے لیے بلٹ ان تصدیق کنندہ کا استعمال کریں۔
Ubuntu	سسٹم سرٹیفکیٹ بنڈل کی اصلاحات فراہم کی گئی ہیں، بشمول متعدد موجودہ اور پرانے ورژن کی شاخیں	ESM کا پرانا ورژن شرائط، کنٹینر کے اندرونی سرٹیفکیٹ پیکج اور ایپلیکیشن بلٹ ان لائبریری کو سپورٹ کرتا ہے
Debian اور Devuan	Debian ریکارڈ شدہ ca-certificates طے شدہ	آپ کو استعمال شدہ اصل برانچ اور انسٹال کردہ پیکیج کو چیک کرنا چاہیے، اور آپ کسی دوسری برانچ کا ورژن نمبر کاپی نہیں کر سکتے۔
RHEL اور مشتقات	آفیشل لسٹ RHEL 6, 7, 8, 9, 10 ہے اور اس میں متعلقہ پروڈکٹس اور تصاویر شامل ہیں جو متاثر ہو سکتی ہیں۔	اس چیک کے مطابق، اعلان میں ابھی تک اصلاحات اور غلطیوں کی مکمل فہرست درج نہیں کی گئی ہے۔ “اپ ڈیٹ نہیں ملا” کو غیر متاثر نہیں سمجھا جا سکتا
Fedora، Arch، Gentoo، Alpine، وغیرہ۔	ایونٹ مینٹینر نے متعلقہ مرمت کا ریکارڈ مرتب کیا ہے۔	آزادانہ طور پر ریلیز، ورژن برانچ اور امیج سے تصدیق شدہ
FreeBSD	باضابطہ طور پر تمام معاون ورژنز کی فہرست دیتا ہے اور سسٹم ٹرسٹ اسٹور کی مرمت فراہم کرتا ہے۔	اپ ڈیٹ کے بعد، اعلان کے مطابق متعلقہ ڈیمون عمل کو دوبارہ شروع کریں؛ آزاد ایپلیکیشن ٹرسٹ اسٹور کو الگ سے چیک کریں۔

Windows، Apple اور ریلیز کے خلاصے کے لیے، 4 دیکھیں؛ Android کے لیے، 1 دیکھیں؛ Ubuntu، Debian، RHEL، اور FreeBSD کے لیے جاری کنندہ کے ریکارڈز بالترتیب 8–11 میں دکھائے گئے ہیں۔

وہ سسٹم جو اب تعاون یافتہ نہیں ہیں، آف لائن ڈیوائسز، NAS، راؤٹرز، اور دیگر ایمبیڈڈ ماحول کو اس بات کی تصدیق کرنے کی ضرورت ہے کہ آیا وہ اب بھی متعلقہ چین پر بھروسہ کرتے ہیں اور آیا ان کے پاس منسوخی یا سافٹ ویئر اپ ڈیٹس حاصل کرنے کے لیے چینلز موجود ہیں۔ پلیٹ فارم کا نام بذات خود اصل تصدیقی رویے کو جانچنے کا متبادل نہیں ہے۔

براؤزر کا تحفظ آپریٹنگ سسٹم کے تحفظ سے مختلف ہے۔

Chrome ہنگامی بلاکس کی تقسیم کے لیے CRLSet استعمال کرتا ہے۔ Firefox میکانزم استعمال کرتا ہے جیسے OneCRL۔ Firefox کو بلاکنگ انفارمیشن کے ساتھ بھی جاری کیا گیا ہے تاکہ ان کنفیگریشنز کو اضافی تحفظ فراہم کیا جا سکے جو ریموٹ سیٹنگز کو صحیح طریقے سے وصول نہیں کرتی ہیں۔ 13

Firefox Android کی کچھ کنفیگریشنز نے سٹارٹ اپ پر اپ ڈیٹ کردہ فہرست کو درست طریقے سے لاگو نہیں کیا تھا، جسے Mozilla نے 158.0.2. کے ذریعے طے کرنے کا کہا ہے، لہذا، ابتدائی 158.0.1 کی حیثیت کو تمام Android Firefox کنفیگریشنز کو شامل کرنے کے لیے بڑھایا نہیں جا سکتا۔ 2

Apple اور Windows کی سسٹم کی تصدیق کے لیے اقدامات کیے گئے ہیں، لیکن اس کا یہ مطلب نہیں ہے کہ ایک ہی مشین پر موجود تمام کمانڈ لائن پروگرام سسٹم کی تصدیق سے گزریں گے۔ ایونٹ مینٹینر نے خاص طور پر یاد دلایا کہ کچھ macOS بلٹ ان ٹولز آزاد سرٹیفکیٹ فائلز استعمال کرتے ہیں۔ چیک کرتے وقت اصل TLS بیک اینڈ اور CA ماخذ کو ریکارڈ کیا جانا چاہیے۔ 4

سرٹیفکیٹ کی شفافیت کے لیے حفاظتی حدود

Google نے تصدیق کی کہ اس سے پہلے کہ اس نے بلاک کو لاگو کیا، چھ TLS انٹرمیڈیٹ CA نے TLS سرٹیفکیٹ جاری نہیں کیا جو CT لاگ میں داخل ہوا تھا۔ لہذا، Chrome کلائنٹس جو CT کو نافذ کرتے ہیں انہیں اضافی تحفظ حاصل ہے۔ یہ حقیقت اس امکان کو مسترد نہیں کرتی ہے کہ CT پر عمل نہ کرنے والے دوسرے کلائنٹس نے غیر دستاویزی سرٹیفکیٹ قبول کر لیے ہیں۔ 15

“یہ پتہ چلتا ہے کہ یہ قابل اعتماد جڑ سے منسلک کیا جا سکتا ہے”، “ممکنہ استحصال کے حالات موجود ہیں” اور “ایک حملہ ہوا ہے” تین مختلف فیصلے ہیں اور ایک دوسرے سے تبدیل نہیں ہونا چاہئے.

5 ترقیاتی ماحول اور رن ٹائم مرمت کی بنیاد

مندرجہ ذیل تصدیق شدہ اصلاحات کی ایک بنیادی لائن ہے اور ان ریلیز کو طویل مدتی پن کرنے کی ضرورت نہیں ہے۔ ڈسٹروس پرانے ورژن نمبروں کو بیک پیچ کو منتقل کر کے ٹھیک کر سکتے ہیں، اور ان کی سیکیورٹی ایڈوائزری کا بھی جائزہ لیا جانا چاہیے۔

اجزاء	تصدیق شدہ ورژن یا اپ ڈیٹ کا طریقہ	تعیناتی کے تحفظات
Node.js 24	24.22.1 یا اسی برانچ کے مستحکم ورژن کو اپ ڈیٹ کریں۔	روٹ ریپوزٹری اپ ڈیٹس اور بلاک شدہ پبلک کیچینز کو مسترد کرنے پر مشتمل ہے۔ Node راستہ چیک کریں جو اصل میں سروس کے ذریعہ استعمال کیا جاتا ہے اور دوبارہ شروع کریں۔
Python certifi	2026.10.19 یا جدید تر ورژن	ہر ایک حقیقی چلنے والے ماحول کو چیک کریں؛ آپ عالمی Python کے تحت صرف ایک پیکیج کو اپ ڈیٹ نہیں کر سکتے
pip	26.2.2 یا جدید تر ورژن	پرانے ورچوئل ماحول میں pip کو الگ سے اپ ڈیٹ کریں اور نیا ماحول بننے کے بعد ورژن کا جائزہ لیں۔
uv	0.13.4 یا جدید تر ورژن	ٹول کی ایک کاپی اپ ڈیٹ کریں جیسا کہ یہ اصل میں انسٹال ہوا تھا۔
Go	1.27.3 یا 1.26.10، متعلقہ برانچ کا اپ ڈیٹ ورژن بھی دستیاب ہے	ٹول چین کو اپ ڈیٹ کرنے کے بعد متعلقہ پروگراموں کو دوبارہ بنائیں اور ان کو تعینات کریں، یا وینڈر کی مرمت کی بائنری حاصل کریں۔
Oracle JDK	متعلقہ معاون ورژن لائنوں کے لیے Critical پیچ	مختلف JDK پبلشرز اپنے اپنے اعلانات پر عمل کرتے ہیں۔ کوئی واحد ورژن نمبر نہیں ہے جو تمام Java ریلیز پر لاگو ہوتا ہے۔
Cloudflare Tunnel	cloudflared 2026.10.2 یا جدید تر ورژن	چلنے والی خدمات کو اپ ڈیٹ کریں؛ کنٹینر کی تعیناتی کے لیے تصویر کو تبدیل کرنے اور دوبارہ تعینات کرنے کی ضرورت ہوتی ہے۔
Cloudflare One／WARP	پلیٹ فارم یا اپ ڈیٹ شدہ مستحکم ورژن کے مطابق مقررہ کلائنٹ ورژن	کلائنٹ سائیڈ اور سرور سائیڈ اقدامات کی الگ الگ تصدیق کی جاتی ہے۔ مخصوص پلیٹ فارم ورژنز کے لیے، ضمیمہ 7 دیکھیں

کے لیے اصل ہدایات Node , Python , Go , Oracle اور Cloudflare میں بالترتیب دستیاب ہیں۔ 13 , 12 , 14 , 15 , 7 .

Python آزاد سرٹیفکیٹ ڈیٹا بیس کا مسئلہ

Python حکام نے نشاندہی کی کہ پرانا pip سسٹم ٹرسٹ اور بلٹ ان certifi کا مجموعہ استعمال کرے گا۔ سسٹم سرٹیفکیٹ اسٹور میں صرف ترمیم کرنا یا pip میں CA فائل شامل کرنا اس کے پہلے سے موجود پرانے اعتماد کو قابل اعتماد طریقے سے خارج نہیں کر سکتا۔ لہذا، PIP_CERT، REQUESTS_CA_BUNDLE یا --cert کو پرانے pip کے لیے یونیورسل مرمت کے متبادل کے طور پر استعمال نہیں کیا جا سکتا۔ 12

اپ ڈیٹ کرنے کے بعد موجودہ ورچوئل ماحول کو چیک کریں۔ نئے تخلیق شدہ ماحول میں نصب شدہ pip ورژن کو بھی چیک کریں تاکہ بوٹسٹریپ کے پرانے اجزاء کمزور ٹولز کو دوبارہ متعارف نہ کرائیں۔ ابتدائی اپ گریڈ کے لیے، دوسرے پیکجز کو اپ ڈیٹ کرنے سے پہلے Python کی ایڈوائزری میں ڈاؤن لوڈ ذرائع اور SHA-256 تصدیقی مراحل کی پیروی کریں۔ 12

Go اور دوسرے مرتب کردہ پروگرام

Go کی درستگی نے crypto/x509 کی توثیق کی منطق کو تبدیل کر دیا۔ 14 تعیناتی کے طریقہ کار کے نقطہ نظر سے، ڈیولپمنٹ مشین پر کمپائلر کو اپ ڈیٹ کرنے سے پہلے سے تعینات بائنری کو دوبارہ نہیں لکھا جائے گا۔ نئی کوڈ لیئر بلاکنگ حاصل کرنے کے لیے، ایپلیکیشن کو دوبارہ بنایا جانا چاہیے اور اسے تبدیل کیا جانا چاہیے، یا وینڈر کی طرف سے فراہم کردہ اپ ڈیٹ شدہ ورژن استعمال کیا جانا چاہیے۔ آیا کوئی پرانا پروگرام سسٹم روٹ اپ ڈیٹس سے بھی فائدہ اٹھا سکتا ہے اس کا انحصار اصل تصدیقی راستے پر ہے جسے وہ استعمال کرتا ہے۔

کنٹینرز اور پیک شدہ ایپلی کیشنز

سسٹم سرٹیفکیٹ پیکج، ایپلیکیشن پر انحصار اور کنٹینر میں رن ٹائم کا تعین عام طور پر تصویری مواد سے ہوتا ہے۔ میزبان اپ ڈیٹ تصویری مواد کی تازہ کاری کے برابر نہیں ہے۔ بنیادی تصویر اور انحصار کو اپ ڈیٹ کرنے کی ضرورت ہے، اور اصل چلنے والی مثال کو دوبارہ بنانے، تعینات کرنے اور جانچنے کی ضرورت ہے۔ پیکڈ ایپلی کیشنز اور ڈیسک ٹاپ پروگرام جو اپنے رن ٹائم کے ساتھ آتے ہیں انہیں بھی وینڈر ریلیز چینلز کے مطابق اپ ڈیٹ کیا جانا چاہیے۔ 710

6 مرمت کے نفاذ کی ہدایات

پہلے معائنہ آبجیکٹ کا تعین کریں۔

ان خدمات کے لیے درج ذیل معلومات کو ریکارڈ کرنے کی سفارش کی جاتی ہے جنہیں محفوظ کرنے کی ضرورت ہے، اور پھر متعلقہ مرمت کا راستہ منتخب کریں۔ یہ ایک تعیناتی چیک لسٹ ہے اور اس کے لیے ضروری نہیں ہے کہ تمام اجزاء ہر سسٹم پر موجود ہوں۔

پروجیکٹ	جو ریکارڈ کرنے کی ضرورت ہے۔
ایپلی کیشنز اور استعمال	براؤزر، ادائیگی API کلائنٹ، ای میل بھیجنے کی خدمت، ڈاؤن لوڈ ٹول، ریورس پراکسی، وغیرہ۔
آپریٹنگ پوزیشن	میزبان، کنٹینر، ورچوئل مشین، ڈیسک ٹاپ ایپلیکیشن یا موبائل ڈیوائس
عمل درآمد کی تصدیق کریں۔	آپریٹنگ سسٹم کی توثیق کرنے والا، OpenSSL، Node، Python لائبریری، Java یا ایپلیکیشن حسب ضرورت عمل درآمد
قابل اعتماد ذریعہ	سسٹم CA پیکیج، certifi، JDK ٹرسٹ اسٹور، بلٹ ان CA bundle یا انٹرپرائز کنفیگریشن
مرمت کی حیثیت	انسٹال شدہ ورژن، پیچ کا ذریعہ، چاہے دوبارہ شروع کیا جائے یا دوبارہ تعینات کیا جائے۔
قبولیت کے نتائج	آیا متاثرہ سلسلہ کو مسترد کر دیا گیا ہے، کیا عام کاروباری کنکشن کامیاب ہے، اور چیک کا وقت

Cloudflare کے لیے ڈویلپر گائیڈ خاص طور پر یہ بتاتا ہے کہ SDK دوسرے اجزاء کو توثیق دے سکتا ہے۔ صرف اعلیٰ سطح کے SDK کو اپ ڈیٹ کرنے سے ضروری نہیں کہ حقیقی اعتماد کی پالیسی تبدیل ہو جائے۔ 7

آپریٹنگ سسٹمز اور براؤزر

Windows: خودکار سرٹیفکیٹ ٹرسٹ لسٹ اپ ڈیٹس کو فعال اور تصدیق کریں۔ قائم کردہ انتظامی پالیسیوں کے ذریعے اپ ڈیٹس تقسیم کریں۔ آف لائن آلات یا خودکار اپ ڈیٹس والے آلات کو مناسب انتظامی عمل کے ذریعے لاگو بلاک کی ضرورت ہوتی ہے۔ ایسے پروگراموں کو چیک کریں جو Windows سسٹم کی توثیق کو الگ سے استعمال نہیں کرتے ہیں۔ 4

Apple پلیٹ فارم: مکمل نظام، حفاظتی جزو اور ایپلیکیشن اپ ڈیٹس۔ macOS پر ڈویلپمنٹ ٹولز کے لیے، اس کا TLS بیک اینڈ، سرٹیفکیٹ فائلز اور انسٹالیشن کے ذرائع بھی چیک کریں۔ یہ فیصلہ نہیں کیا جا سکتا کہ پوری مشین کی مرمت صرف اس لیے کی گئی ہے کیونکہ Safari نے ٹیسٹ چین کو مسترد کر دیا ہے۔ 4

Android: Google Play سروسز کو ان آلات پر اپ ڈیٹ کریں۔ Google بتاتا ہے کہ کسی ڈیوائس کو دوبارہ شروع کرنے سے فوری اپ ڈیٹ ہو سکتا ہے۔ ان سروسز کے بغیر آلات کے لیے، وینڈر یا ROM ایڈوائزری پر عمل کریں۔ Google کی کوریج کا بیان خود بخود ہر Android ڈیوائس پر لاگو نہیں ہوتا ہے۔ 1

Ubuntu/Debian: تعاون یافتہ ریپوزٹریز سے سرٹیفکیٹ پیکجز کو اپ ڈیٹ کریں اور انسٹال شدہ ڈسٹری بیوشن کے لیے ایڈوائزری کو چیک کریں۔ مثال کے طور پر، APT پر مبنی نظام استعمال کر سکتا ہے:

sudo apt update
sudo apt install --only-upgrade ca-certificates
dpkg-query -W -f='${Package} ${Version}\n' ca-certificates

Ubuntu 22.04، 24.04، 26.04، اور 26.10 کے لیے متعلقہ اپ ڈیٹس معیاری معاونت ہیں۔ پہلے کے ورژنز کو ESM سپورٹ اور گودام کی حیثیت کی جانچ کرنی چاہیے۔ کمانڈ کامیابی سے ختم ہونے کے بعد، آپ کو ابھی بھی بلیٹن میں فکس پیک ورژن کا موازنہ کرنا چاہیے۔ 89

RHEL اور متعلقہ پروڈکٹس: پروڈکٹ چینل کے ذریعہ سرٹیفکیٹ پیکج اور سیکیورٹی کی خرابی کو چیک کریں۔ ورژن چیکنگ کا استعمال کرتے ہوئے کیا جا سکتا ہے:

rpm -q ca-certificates

وینڈر پیچ حاصل کرنے کے لیے تعاون یافتہ DNF/YUM اپ ڈیٹ کا طریقہ کار استعمال کریں۔ اگر چینل نے ابھی تک کوئی درستگی فراہم نہیں کی ہے، تو “کوئی اپڈیٹ ایبل پیکیج” کو محفوظ نہ سمجھیں۔ جب روٹ ٹرسٹ کو عارضی طور پر ہٹانا ضروری ہو تو مینوفیکچرر کی طرف سے واضح طور پر درج کردہ اقدامات کو اپنائیں اور جائز کاروباری سرٹیفکیٹس کی مطابقت کا جائزہ لیں۔ 10

FreeBSD: متعلقہ سسٹم برانچ کو اپ ڈیٹ کریں جیسا کہ آفیشل ایڈوائزری کی ہدایت ہے، پھر متاثرہ OpenSSL ٹرسٹ کنفیگریشن کا استعمال کرتے ہوئے ڈیمونز کو دوبارہ شروع کریں یا سسٹم کو ری بوٹ کریں۔ 11

ایپلی کیشنز اور تصاویر

متعلقہ رن ٹائم اور سرٹیفکیٹ انحصاری اپ ڈیٹس کو مکمل کرنے کے بعد، قابل عمل فائل پاتھ کو چیک کریں جہاں سروس درحقیقت چل رہی ہے اس سے بچنے کے لیے کہ ٹرمینل نئے ورژن میں تبدیل ہو گیا ہے اور ڈیمون اب بھی پرانی انسٹالیشن ڈائرکٹری استعمال کرتا ہے۔ کثیر ماحول Python، سروس کنٹینرز اور ایپلی کیشنز کے لیے جو ان کے اپنے رن ٹائم کے ساتھ آتے ہیں، انہیں الگ سے چیک کیا جانا چاہیے۔

ان اجزاء کے لیے جنہیں دوبارہ تعمیر کرنے کی ضرورت ہے، بلڈ ورژن، انحصاری ورژن، اور تعیناتی امیج آئی ڈی کو محفوظ کریں۔ قبولیت آبجیکٹ اصل چلانے کی مثال ہے اور صرف بلڈ مشین یا امیج رجسٹری میں نئے ٹیگ کو چیک نہیں کر سکتا۔ 71214

ویب سائٹ سرٹیفکیٹ کی منتقلی

اگر کسی ویب سائٹ کی زنجیر میں منسوخ شدہ یا بلاک شدہ انٹرمیڈیٹ CA ہے، یا بالآخر ایک غیر بھروسہ مند جڑ پر انحصار کرتا ہے، تو ایک اور سلسلہ حاصل کریں جسے کلائنٹس اب بھی قبول کرتے ہیں۔ مکمل سرور سرٹیفکیٹ چین انسٹال کریں اور ہر داخلے کو چیک کریں، بشمول لوڈ بیلنسرز، ریورس پراکسی، CDN اینڈ پوائنٹس، اور براہ راست قابل رسائی اصل۔ 15

آیا نقل مکانی درکار ہے اصل سلسلہ پر مبنی ہے۔ صرف سرٹیفکیٹ سیلز برانڈ کے ذریعے فلٹر کرنے سے ری سیل یا کراس سائننگ تعلقات چھوٹ سکتے ہیں۔ صرف باقاعدہ میعاد ختم ہونے کی تجدید کا انتظار کرنا ضروری نہیں ہے کہ روٹ اسٹور کے اپ ڈیٹ ہونے سے پہلے منتقلی مکمل ہوجائے۔

CA کی طرف سے جاری کردہ دیگر عام ویب سائٹ سرٹیفکیٹس کے لیے جو متاثرہ جڑ پر بھروسہ نہیں کرتے، اس واقعے کی وجہ سے ان پر دوبارہ دستخط کرنے کی ضرورت نہیں ہے۔ ایک ہی وقت میں، ویب سائٹ سرور کو اب بھی بیرونی خدمات کو کال کرتے وقت کلائنٹ کی طرف سے مرمت کی جانچ کرنی چاہیے۔

7 توثیق کریں کہ درستگی اصل میں اثر کرتی ہے۔

ورژن کی جانچ اور رویے کی جانچ الگ الگ کی جاتی ہے۔

ورژن کی جانچ اس بات کی تصدیق کے لیے کی جاتی ہے کہ پیچ یا فکسڈ اجزاء تعینات کیے گئے ہیں۔ رویے کی جانچ کا استعمال اس بات کی تصدیق کے لیے کیا جاتا ہے کہ ایپلیکیشن درحقیقت متوقع تصدیقی راستے کو استعمال کرتی ہے۔ دونوں چیک مختلف مسائل کو حل کرتے ہیں، اور ان میں سے کسی کو بھی “اپ ڈیٹ کمانڈ کامیابی کے ساتھ انجام دیا گیا” سے تبدیل نہیں کیا جا سکتا۔

ایونٹ مینٹینر ٹیسٹ سائٹ اور سرٹیفکیٹ چین مواد فراہم کرتا ہے، اور داخلہ ضمیمہ 4 میں مرکوز ہے۔ اس کی تصدیق ٹارگٹ ایپلیکیشن کے اصل آپریٹنگ ماحول میں کی جانی چاہیے، عام سرٹیفکیٹ کی تصدیق کی ترتیب کو برقرار رکھتے ہوئے۔ 47

نتائج چیک کریں۔	ایسے نتائج جو اخذ کیے جا سکتے ہیں۔
واضح طور پر مسترد کریں کیونکہ متاثرہ سلسلہ قابل بھروسہ نہیں ہے۔	اس بات کی نشاندہی کرتا ہے کہ جس تصدیقی راستے کی جانچ کی جا رہی ہے اس نے سلسلہ کو مسترد کر دیا ہے۔
متاثرہ زنجیر کو عام طور پر قبول کریں۔	اشارہ کرتا ہے کہ اس راستے کی مرمت جاری رکھنے یا کنفیگریشن کو چیک کرنے کی ضرورت ہے۔
DNS خرابی، کنکشن کا وقت ختم، پراکسی مسترد یا سروس ناقابل رسائی	اس کی بنیاد پر یہ نتیجہ اخذ نہیں کیا جا سکتا کہ سرٹیفکیٹ کے خطرے کو ختم کر دیا گیا ہے۔
براؤزر مسترد کرتا ہے، لیکن ایپ کال کو چیک نہیں کیا جاتا ہے۔	یہ صرف براؤزر کی تصدیق کر سکتا ہے، بیک گراؤنڈ پروگرام نہیں۔
A سلسلہ مسترد کر دیا گیا۔	اب بھی اس بات پر غور کرنے کی ضرورت ہے کہ آیا کلائنٹ دوسرے کراس سائننگ پاتھ کو قبول کرتا ہے۔

ٹیسٹ میں تمام درخواستوں کی ناکامیوں کو غلط سمجھنے سے بچنے کے لیے عام کاروباری رابطوں کا بھی احاطہ کرنا چاہیے کیونکہ کاروباری ناکامیوں کے بعد کامیاب مرمت بہت زیادہ اعتماد کو ہٹانے کی وجہ سے ہوتی ہے۔

تکمیل کی تجویز کردہ شرائط

• اپ ڈیٹ کا ذریعہ اور متاثرہ اجزاء کا ورژن دستاویزی ہے۔
• متعلقہ چلنے والی مثال کو دوبارہ شروع، دوبارہ تعمیر، یا دوبارہ تعینات کیا گیا ہے۔
• اصل درخواست متاثرہ سلسلہ کو مسترد کرتی ہے، اور عام کاروبار کے لیے TLS تصدیق کام کرتی رہتی ہے۔
• کنکشن کو بحال کرنے کے لیے سرٹیفکیٹ کی تصدیق کو عارضی طور پر بند کرنے کی کوئی ترتیب نہیں ہے۔
• اگر ویب سائٹ کے سرٹیفکیٹ کی منتقلی شامل ہے تو، تمام بیرونی داخلی راستوں کو تبدیل اور تصدیق کر دی گئی ہے۔

مندرجہ بالا تکمیل کی شرائط اس تصرف کے لیے آپریشن اور دیکھ بھال کی قبولیت کے لیے تجاویز ہیں۔ یہ ثابت کرنے کے مترادف نہیں ہے کہ آلات میں کوئی اور حفاظتی مسئلہ نہیں ہے۔

8 تاریخی HTTPS ٹریفک اور خطرے کی حدود

تین قسم کی چابیاں مختلف استعمال کرتی ہیں۔

کلید	بنیادی مقصد
CA نجی کلید	سرٹیفکیٹ میں شناخت اور عوامی کلید کی پابندی پر دستخط کریں۔
ویب سائٹ کی نجی کلید	تصدیق شدہ TLS ہینڈ شیک میں سرور کی شناخت ثابت کریں
سیشن کی کلید	کنکشن پر اصل میں منتقل ہونے والے ڈیٹا کی حفاظت کریں۔

CA نجی کلید حاصل کرنا ویب سائٹ کی نجی کلید یا تمام سیشن کیز حاصل کرنے کے مترادف نہیں ہے۔ A عارضی کلیدی تبادلے کا استعمال کرتے ہوئے فارورڈ سیکریسی کے ساتھ نارمل کنکشن تاریخی سیشنز کو خود بخود ظاہر نہیں کرے گا کیونکہ طویل مدتی دستخطی کلید بعد میں سمجھوتہ کر لی گئی ہے۔ TLS 1.3 کے متعلقہ حفاظتی اوصاف کے لیے، RFC 8446 دیکھیں۔ 16

اس بار اصل خطرہ توثیق کے مرحلے کے دوران ہوتا ہے: اگر کلائنٹ جعلی سرور کے سرٹیفکیٹ کو قبول کرتا ہے، تو یہ حملہ آور کے ساتھ رابطہ قائم کر سکتا ہے جو ابھی بھی خفیہ ہے۔ TLS 1.3 کو بھی بھروسہ مند تصدیق کی ضرورت ہے۔ صرف پروٹوکول ورژن کو اپ گریڈ کرنا CA کو بلاک کرنے کا متبادل نہیں ہے۔

فیصلے جو اس وقت کیے جا سکتے ہیں اور نہیں کیے جا سکتے

تصدیق شدہ: مخصوص انٹرمیڈیٹ CA نجی کلیدوں سے سمجھوتہ کیا گیا ہے۔ متاثرہ عوامی اعتماد کے راستوں کی رسائی وسیع ہے۔ بڑے پلیٹ فارمز اور کئی سافٹ ویئر ایکو سسٹمز نے کارروائی کی ہے۔ 145

اس واقعے سے قائم نہیں ہوا: کہ تمام صارفین کو درمیانی حملوں کا سامنا کرنا پڑا ہے، کہ دیگر CA نجی کلیدوں سے سمجھوتہ کیا گیا ہے، کہ تمام تاریخی HTTPS ٹریفک کو ڈیکرپٹ کیا جا سکتا ہے، یا یہ کہ ہر ایک ایپلیکیشن کو اپ ڈیٹ کرنے والے براؤزر کی حفاظت کرتا ہے۔

کسی مخصوص سروس کے بارے میں حتمی فیصلہ اس کے سرٹیفکیٹ چین، تصدیقی پالیسی، اصل چلنے والے اجزاء اور اپ ڈیٹ کی حیثیت پر مبنی ہونا چاہیے، نہ صرف یہ کہ آیا ایڈریس بار HTTPS پڑھتا ہے۔

ضمیمہ A متاثرہ انٹرمیڈیٹ CA نام

درج ذیل نام اثاثوں کی جانچ میں مدد کرتے ہیں۔ نام سرٹیفکیٹ فنگر پرنٹس یا عوامی کلید شناخت کنندگان کی جگہ نہیں لیتے ہیں۔ خودکار مماثلت میں واقعہ کے دیکھ بھال کرنے والوں یا دکانداروں کے ذریعہ شائع کردہ عین مطابق شناخت کاروں کا استعمال کرنا چاہئے، بشمول کراس دستخط شدہ سرٹیفکیٹس۔ 5

درمیانی CA	مقصد	وابستہ تنظیمیں۔
EM EV TLS CA - G3B	TLS	eMudhra BV
EM OV TLS CA - G3B	TLS	eMudhra BV
EM DV TLS CA - G3B	TLS	eMudhra BV
EM EV TLS CA - G3C	TLS	eMudhra Inc
EM OV TLS CA - G3C	TLS	eMudhra Inc
EM DV TLS CA - G3C	TLS	eMudhra Inc
EM OV CS CA - G3B	کوڈ پر دستخط	eMudhra BV
EM OV CS CA - G3C	کوڈ پر دستخط	eMudhra Inc

TLS بالکل وہی تصدیق کنندہ اور منسوخی کا طریقہ کار نہیں ہے جیسا کہ کوڈ پر دستخط کرنا ہے۔ اس مضمون کا مرکز HTTPS/TLS ہے۔ کوڈ پر دستخط کرنے والے ماحول کو اس تصدیقی مقصد کے لیے Microsoft, JDK یا متعلقہ سافٹ ویئر فروشوں کو اپنانا چاہیے، اور براؤزر کے ٹیسٹ کے نتائج کو کوڈ پر دستخط کرنے کی قبولیت کے طور پر شمار نہیں کیا جانا چاہیے۔ 515

ضمیمہ B حوالہ لنک

مندرجہ ذیل ذرائع کی 22 اکتوبر 2026 کو تصدیق کی گئی۔ رولنگ اعلان کو اپ ڈیٹ کیا جانا جاری رہ سکتا ہے، اور متن میں موجود اسٹیٹس اور ورژن کو اس دستاویز کی تاریخ کی بنیاد پر سمجھنا چاہیے۔

واقعہ کے حقائق اور پلیٹ فارم ہینڈلنگ

[1] Google Chrome اور Android سرکاری اعلان نجی کلیدی خامیوں، SPKI بلاک کرنے، Google Play سروس کی تقسیم، CT تحفظ، اور Chrome روٹ ریپوزٹری کو ہٹانے کے منصوبوں کی وضاحت کرتا ہے۔ Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates

[2] Mozilla Bugzilla 2083449 ایونٹ کا ریکارڈ اصل رپورٹس، آزاد تصدیق، جنریشن پروسیس کی تحقیقات، Firefox Android کے لیے بعد میں اصلاحات، اور قانونی سرٹیفکیٹ کی منتقلی کے مباحث پر مشتمل ہے۔ تبصرے 5، 11، 29 اور 30 پر توجہ دیں۔ eMudhra Private key compromise of Intermediate Certificates

[3] Mozilla Firefox سیکیورٹی نوٹس OneCRL ہنگامی تقسیم اور اس کے بعد Firefox/NSS ڈسپوزل کی تفصیل۔ Protecting Firefox users following the compromise of eMudhra intermediate certificates

[4] ایونٹ کوآرڈینیٹر Dennis Jackson بحالی کا خلاصہ اور پتہ لگانے کا پورٹل پلیٹ فارم اور سافٹ ویئر کی مرمت کی حیثیت، ٹیسٹ کے داخلے، عوامی سرٹیفکیٹ چین کے مواد، اور ماحول جیسے Windows/macOS پر اضافی ہدایات فراہم کرتا ہے۔ ٹیسٹ کے نتائج صرف جانچے گئے اصل تصدیقی راستوں کی نمائندگی کرتے ہیں۔ eMudhra Intermediate CA Compromise

[5] Mozilla تقسیم اور ٹرسٹ اسٹور مینٹینرز کے لیے نوٹس 6 TLS اور 2 کوڈ پر دستخط کرنے والے انٹرمیڈیٹس CA، Sectigo کراس سائننگ، منسوخی، اور روٹ ٹرسٹ پروسیسنگ کی حدود کی وضاحت کرتا ہے، اور درست سرٹیفکیٹ اور عوامی کلید کی شناخت کی فہرست دیتا ہے۔ oss-security eMudhra Intermediates Compromise

[6] eMudhra آفیشل ایونٹ کا بیان مینوفیکچرر کی کلیدی جنریشن کے عمل کی ابتدائی وضاحت فراہم کریں۔ اصل وجہ اب بھی مکمل تحقیقات کے اختتام سے مشروط ہوگی۔ eMudhra Statement on Recent Certificate Security Incident

[7] Cloudflare سرکاری واقعہ اور مرمت کی ہدایات WARP، Cloudflare Tunnel، اصل سائٹ کی توثیق، رن ٹائم انحصار، تصویری اپ ڈیٹس اور تصدیق کے طریقوں کا احاطہ کرتا ہے۔ 8 eMudhra certificates are compromised Here is what you need to know

آپریٹنگ سسٹم اور تقسیم

[8] Ubuntu سرکاری مرمت کا اعلان ہر ورژن کے لیے ca-certificates فکس پیکجز، سپورٹ چینلز اور ٹارگٹڈ اپ ڈیٹ کے مراحل کی فہرست دیتا ہے۔ eMudhra CA compromise fixes available

[9] Debian سرکاری مسئلہ اور مرمت کا ریکارڈ دیکھ بھال کرنے والے کے درست ریکارڈ اور متعلقہ ریلیز پیکج کو معیار کے طور پر لیا جانا چاہیے، اور مسئلے کی بحث میں ابتدائی عارضی تجاویز کو حتمی حل نہیں سمجھا جانا چاہیے۔ Debian bug 1151413 eMudhra Intermediate CA key compromise

[10] Red Hat آفیشل سیفٹی بلیٹن RHSB 2026 012 RHEL 6 سے لے کر 10 تک، متعلقہ مصنوعات اور کنٹینر کے اثرات کی فہرست، اور ریلیز اور عبوری تصرف کے اندراجات کو درست کرتا ہے۔ Certificate compromise eMudhra

[11] FreeBSD آفیشل سیکیورٹی بلیٹن متاثرہ نظام کی شاخیں، مرمت کے ورژن اور سروس دوبارہ شروع کرنے کی ضروریات فراہم کریں۔ FreeBSD SA 26 73 caroot

رن ٹائم اور پروٹوکول

[12] Python سرکاری تقریب کی تفصیل pip، certifi، uv، وغیرہ کے لیے مرمت کی بنیاد فراہم کرتا ہے، پرانے pip آزاد ٹرسٹ اسٹور کے مسئلے کی وضاحت کرتا ہے، اور SHA-256 تصدیق کے ساتھ ابتدائی اپ گریڈ کا طریقہ فراہم کرتا ہے۔ Information for Python users regarding eMudhra emSign CA certificate security incident

[13] Node.js 24.22.1 سرکاری ریلیز NSS روٹ اسٹور اپ ڈیٹس پر مشتمل ہے اور بلاک شدہ عوامی کلیدی سرٹیفکیٹ چینز پر مشتمل تبدیلیوں کو مسترد کرتا ہے۔ Node.js 24.22.1 security release

[14] Go سرکاری سیکیورٹی ریلیز تفصیل crypto/x509 سرٹیفکیٹ چین فلٹرنگ اپ ڈیٹ برائے Go 1.27.3/1.26.10. Go 1.27.3 and Go 1.26.10 are released

[15] Oracle JDK سرکاری تصرف کی ہدایات JDK اہم پیچ اور متعلقہ کنفیگریشن اقدامات کی وضاحت کریں جب اسے فوری طور پر اپ گریڈ نہیں کیا جا سکتا ہے۔ Distrusting eMudhra Intermediate Certificates in Oracle JDK

[16] TLS 1.3 پروٹوکول معیاری RFC 8446 شناخت کی تصدیق، عارضی کلیدی تبادلے اور آگے کی رازداری سے متعلق ہدایات کے لیے ضمیمہ E.1 دیکھیں۔ The Transport Layer Security Protocol Version 1.3

[17] واقعہ سے متعلق روٹ سرٹیفکیٹ اور جاری کرنے کا رشتہ ڈیٹا براہ راست جاری کنندہ اور کراس سائن کرنے والے تعلقات کو سمجھنے کے لیے استعمال کیا جاتا ہے۔ روٹ اسٹور کی شمولیت کی حیثیت کلائنٹ کی تازہ ترین منسوخی یا بلاک کرنے کی حیثیت کو تبدیل نہیں کرسکتی ہے۔ Root certificate relationships JSON