حادثة eMudhra: كان تخمين ثمانية مفاتيح لسلطات التصديق في غاية السهولة — ما الذي يجب على حاملي شهادات TLS التحقق منه الآن؟

6 نوفمبر 2026  |  الشهادات  |  أمن المعلومات

في أكتوبر 2026، كُشف أن سلطة التصديق الهندية eMudhra أصدرت ثماني شهادات لسلطات تصديق وسيطة (Intermediate CAs) ذات مفاتيح خاصة عديمة القيمة الأمنية عمليًا. كانت المفاتيح الخاصة أعدادًا صحيحة أصغر من 256، وكان أحدها حرفيًا العدد 4. ومن يعرف مفتاحًا كهذا يستطيع توقيع شهادات لـأي نطاقات يشاء باسم سلطة التصديق. لذلك استجابت الجهات المطوّرة للمتصفحات خلال ساعات، فحظرت الشهادات الوسيطة وأزالت سلطة التصديق الجذرية المرتبطة بها، emSign ECC Root CA – G3، من قوائم الثقة لديها.

يوضح هذا المقال ما الذي حدث بالضبط، ولماذا يعني مفتاح بقيمة «4» انهيارًا أمنيًا كاملًا، ومن المتأثر ومن غير المتأثر، وما الذي ينبغي لمشغّلي المواقع وخوادم البريد وجدران الحماية التحقق منه الآن. ونلتزم فيه التزامًا صارمًا بما تثبته المصادر الأولية. فقد انتشرت في التغطيات الأولى وعلى شبكات التواصل الاجتماعي روايات غير دقيقة. وسنتناول ذلك بعد قليل.

موجز: ما الصحيح وما غير الصحيح

تسلسل الأحداث

• 17 أكتوبر 2026: أُبلغت Mozilla بالحادثة (ورد البلاغ الساعة 18:05 بالتوقيت العالمي المنسق وفقًا لـ Bugzilla). وبحلول الساعة 22:59 بالتوقيت العالمي المنسق، كان حظر الشهادات الوسيطة قد وُزِّع عبر OneCRL التابعة لـ Mozilla، أي بعد أقل من ثلاث ساعات من تلقي Mozilla البلاغ.
• 18 أكتوبر 2026: أبطلت eMudhra الشهادات الوسيطة الثماني.
• 19 أكتوبر 2026: أبطلت Sectigo الشهادات المتقاطعة التي استخدمتها للتوقيع على سلطات التصديق الوسيطة الثماني.
• 20 أكتوبر 2026: أصدرت Mozilla الإصدارات Firefox 158.0.1 وESR 115.43.1 وESR 153.5.1، إضافة إلى NSS 3.131.1. وبذلك أُزيل الجذر emSign ECC Root CA – G3. وبين 20 و21 أكتوبر، ظهرت أيضًا في سجلات شفافية الشهادات 107,107 شهادات وُقِّعت بستة من المفاتيح الضعيفة الثمانية (انظر أدناه).
• 22 أكتوبر 2026: أعلنت eMudhra عزمها الانسحاب من نشاط إصدار شهادات TLS العامة. ويستمر نشاط توقيع الشيفرة وS/MIME تحت جذور مستقلة.
• 27 أكتوبر 2026: أزال Chrome سلطة التصديق الجذرية أيضًا.
• 16 و30 نوفمبر 2026: الموعدان النهائيان للشهادات الأقدم من فئة G1 (لدى Chrome/Mozilla ثم Apple، على التوالي)، وهما مهمان، وفقًا لـ eMudhra، لانتقال مجموعة العملاء الأمريكيين المتأثرة.

لماذا يعني مفتاح خاص بقيمة «4» انهيارًا أمنيًا كاملًا

تؤكد سلطة التصديق (CA)، من خلال توقيعها الرقمي، أن الشهادة تخص نطاقًا معينًا. وتثق المتصفحات بهذا التوقيع ما دامت سلطة التصديق مدرجة في قائمة الثقة لديها. ويعتمد الأمان على أن سلطة التصديق وحدها تعرف المفتاح الخاص.

في الشهادات التي تستخدم المنحنيات الإهليلجية (ECDSA)، يكون المفتاح الخاص عددًا كبيرًا جدًا d. أما المفتاح العام فهو نقطة Q = d · G على المنحنى (G هي نقطة الأساس المحددة). واستخراج العدد d من Q يكاد يكون مستحيلًا عمليًا إذا كان العدد مختارًا عشوائيًا بطول 384 بت. لكن إذا كان d صغيرًا، مثل 4، فيكفي حساب 1·G, 2·G, 3·G, 4·G … تباعًا ومقارنة النتائج بالنقطة العامة. يستغرق ذلك ثواني ولا يتطلب أي معرفة متخصصة.

المفتاح العام موجود في كل شهادة، ويمكن لأي شخص الاطلاع عليه. وبذلك يستطيع أي شخص يجري هذه الحسابات إنشاء شهادات تبدو صالحة باسم سلطة التصديق لأي نطاق يشاء، ما دام المتصفح لا يزال يثق بتلك السلطة. ولهذا تحديدًا بادرت Mozilla وغيرها إلى الحظر فورًا.

نزّلنا الشهادات الوسيطة الثماني المذكورة في Bugzilla من سجلات الشفافية العامة (crt.sh) باستخدام بصمة SHA-256، وقارنّا لكل منها k · G بالنقطة العامة، لقيم k من 1 إلى 1000. تستخدم الشهادات الثماني جميعها مفتاح P-384، وقد وجدنا قيمة مطابقة لكل واحدة منها:

تتطابق القيم مع المعلومات الواردة في Bugzilla وفي التغطيات الإعلامية (ومنها The Register، التي ذكرت أن أحد المفاتيح كان «حرفيًا 4»). لم نوقّع أي شيء ولم نصدر أي شهادة باستخدام هذه القيم؛ فهذه الحسابات تقتصر على فحص شهادات متاحة للعامة.

السبب وفقًا لـ eMudhra

وفقًا لرواية eMudhra في Bugzilla، نشأت المفاتيح الضعيفة خلال مراسم إنشاء مفاتيح في 30 أبريل 2025. وأُجري خلالها اختبار تغليف المفاتيح وفك تغليفها (Wrap/Unwrap)، ضمن انحراف معتمد عن الإجراءات المعتادة. وتقول الشركة إن خطأ في الشيفرة أدى إلى إنشاء زوج مفاتيح ثانٍ ضعيف داخل الجهاز. ثم استُخدم هذا الزوج بالخطأ لإنشاء طلب الشهادة بسبب تشابه تسميات المفاتيح. وبعد ذلك أُصدرت الشهادات وأُدرجت في قوائم الثقة، وظلت فيها أكثر من عام حتى انكشف الخطأ علنًا.

بحسب The Register، اكتشف الباحث الأمني Scott Helme المفتاح «4». ولا توضح المصادر الأولية التي راجعناها الطريقة التي كُشف بها الخطأ؛ لكن بإمكان أي شخص فحص القيم الصغيرة للمفاتيح باستخدام الشهادات العامة.

من المتأثر ومن غير المتأثر؟

تتكون السلسلة من ثلاثة مستويات: سلطة التصديق الجذرية، وسلطة التصديق الوسيطة، والشهادة النهائية للموقع أو الخادم. وقد تأثر المستوى الأوسط. ويترتب على ذلك ما يلي:

• مفاتيح حاملي الشهادات (المفتاح الخاص بخادمكم) لم تتأثر وفقًا لجميع المصادر المتاحة لنا. ولا يلزم استبدالها بدعوى أنها أصبحت «معروفة».
• الشهادات التي تعتمد على الشهادة الجذرية المُزالة لم تعد مقبولة لدى المتصفحات. ويجب استبدالها لأن سلسلة الثقة لم تعد قائمة، وليس بسبب ضعف مفتاح الخادم. وبحسب تحليل برنامج الشهادات الجذرية في Chrome (حتى 21.10.2026)، يشمل ذلك نحو 30.800 شهادة لا تزال سارية. وقد أصدرت سلطات التصديق التابعة لـInternet2/InCommon عددًا قدره 30.791 منها، وهو اتحاد أمريكي يخدم أساسًا الجامعات والمؤسسات البحثية. وتتحدث eMudhra عن اتحاد واحد من العملاء في الولايات المتحدة.
• جميع عملاء eMudhra الآخرين غير متأثرين، بحسب الشركة. وتستمر خدمات التوقيعات الرقمية وeSign وemSigner وCertiNext وSecurePass وPrivaTrust وemCA في العمل على بنية تحتية منفصلة.

لذلك، فإن احتمال استخدام العملاء في ألمانيا والنمسا وسويسرا لشهادة تعتمد على هذه الشهادة الجذرية ضئيل. لكن لا يمكنكم التأكد إلا بالفحص. ولا يستغرق ذلك سوى بضع دقائق؛ راجعوا قائمة التحقق.

الشهادات البالغ عددها 107,107 في سجلات الشفافية

بحسب Bugzilla، ظهرت بعد الإلغاء، بين 20 و21 أكتوبر 2026، 107.107 شهادة في سجلات شفافية الشهادات، وُقّعت باستخدام ستة من المفاتيح الثمانية الضعيفة. ومن بينها شهادات لإثبات المفهوم ثبت وجودها، تحمل مثلًا الاسم google.com. ويعتمد معظمها على شهادات التصديق المتبادل الصادرة عن Sectigo، والتي أُلغيت منذ ذلك الحين.

يوضح ذلك أمرين: أولًا، كان بإمكان أي شخص لديه معرفة أساسية بالتشفير استغلال الخلل فورًا. وثانيًا، تتضح قيمة سجلات الشفافية التي تتيح للجميع الاطلاع على مثل هذه الشهادات الصادرة. ولا توضح المصادر المتاحة لنا ما إذا كان أي منها قد استُخدم لأغراض ضارة خارج نطاق الاختبارات، ولا ندّعي حدوث ذلك.

الإجراءات التي اتخذتها الجهات المطوّرة للمتصفحات وسلطات التصديق

بحسب ما صرحت به Mozilla في النقاش على dev-security-policy، فإنها لا ترجّح تأثر سلطات تصديق أخرى.

قائمة التحقق: ما الذي ينبغي فحصه الآن

1. تحديد الجهة التي أصدرت شهاداتكم. على أي جهاز يتوفر عليه OpenSSL:

   openssl s_client -connect ihre-domain.example:443 -servername ihre-domain.example </dev/null 2>/dev/null | openssl x509 -noout -issuer -dates

   إذا ظهر في خانة المُصدر اسم eMudhra أو emSign (مثل «EM DV TLS CA – G3B» أو «G3C»)، فافحصوا السلسلة كاملةً والشهادة الجذرية باستخدام -showcerts. وإذا كانت السلسلة تعتمد على emSign ECC Root CA – G3، فيلزم استبدال الشهادة.
2. مراجعة جميع الخدمات، وليس الموقع الإلكتروني وحده. يشمل ذلك خوادم البريد (SMTPS وIMAPS)، وبوابات VPN، وواجهات إدارة جدران الحماية، وموازنات الأحمال، والخدمات الداخلية، والأجهزة والمعدات المتخصصة التي تستخدم شهادات خاصة بها.
3. الاطلاع على الشهادات العامة الصادرة لنطاقكم. عبر crt.sh (بالبحث عن %.ihre-domain.example) يمكنكم الاطلاع على جميع الشهادات الصادرة لنطاقكم، بما فيها تلك التي لا تعلمون بوجودها. وهذه فرصة جيدة لاكتشاف الشهادات التي صدرت دون رغبتكم.
4. استبدال الشهادات المتأثرة. احصلوا على شهادات من سلطة تصديق أخرى معروفة، أو عبر ACME (مثل Let’s Encrypt). وأنشئوا مفتاحًا جديدًا للخادم عند الاستبدال. لا تفرض هذه الحادثة ذلك، لكنه إجراء سليم عند الانتقال إلى سلطة تصديق أخرى.
5. Trust-Stores eigener Geräte prüfen. Wer die eMudhra-Root in eigenen Geräten, Java-Keystores, Containern oder Zertifikats-Bundles fest eingetragen hat, sollte sie dort entfernen. Browser aktualisieren das selbst, solche Bestände nicht.
6. تحديث Firefox. تتضمن الإصدارات بدءًا من 158.0.1 أو ESR 115.43.1 / 153.5.1 إجراءات الحظر. تحقّقوا من وصول التحديثات إلى أجهزة العمل المُدارة مركزيًا.
7. الأتمتة. إذا كنتم تديرون الشهادات يدويًا، فانتقلوا إلى التجديد التلقائي (ACME). عندها يصبح تغيير سلطة التصديق مجرد تعديل في الإعدادات بدلًا من إجراء طارئ.

الدروس المستفادة

• اختيار سلطة التصديق قرار يتعلق بالمخاطر. والعوامل الحاسمة هي الشفافية وجودة الإجراءات والعضوية في برامج الشهادات الجذرية. ولا يدل السعر على أي من ذلك. تكشف الحادثة عن خلل إجرائي خلال مراسم توليد المفاتيح، وهو خلل يمكن أن يقع لدى أي سلطة تصديق.
• شفافية الشهادات تؤدي دورها. أتاحت السجلات المتاحة للجمهور تحديد نطاق الحادثة بسرعة ورصد الشهادات البالغ عددها 107.107.
• المرونة في إدارة التشفير تؤتي ثمارها. من يجدّد شهاداته تلقائيًا ويستطيع تغيير سلطة التصديق دون تعديل عشرات الأنظمة يدويًا، يمكنه معالجة مثل هذه الحوادث بيوم عمل بدلًا من أسبوع.
• راقبوا نطاقاتكم. تكشف مراقبة سجلات الشفافية (مثلًا عبر crt.sh أو خدمات ترسل تنبيهات بالبريد الإلكتروني) عن إصدار أي جهة شهادات لنطاقكم.
• طبقات حماية متعددة. شهادات TLS ليست سوى طبقة واحدة. وتساعد أيضًا سجلات CAA في DNS (التي تحدد سلطات التصديق المسموح لها بإصدار شهادات لنطاقكم)، والمصادقة الثنائية عند تسجيل الدخول. للمزيد، راجعوا مقالنا تأمين Odoo 19: جدار الحماية والمصادقة الثنائية & Web RBL.

الأسئلة الشائعة

ما الذي حدث لدى eMudhra بالضبط؟

كانت المفاتيح الخاصة لثماني شهادات وسيطة تابعة لسلطة التصديق eMudhra أعدادًا صحيحة أقل من 256 (أحدها كان العدد 4). وبذلك، كان بإمكان أي شخص حساب المفتاح الخاص انطلاقًا من الشهادة العامة وتوقيع شهادات تبدو سليمة. أُلغيت شهادات سلطات التصديق الوسيطة، وأُزيلت الشهادة الجذرية emSign ECC Root CA – G3 من Firefox (20.10.2026) وChrome (27.10.2026).

هل سلّمت eMudhra المفتاح الخاص «4» إلى العملاء؟

لا. كانت المفاتيح الضعيفة تخص الشهادات الوسيطة لسلطة التصديق نفسها. ولم تكن مفاتيح للعملاء، ولم تُسلَّم إليهم. ولا يغيّر من هذه الحقيقة تداول ادعاءات مخالفة على شبكات التواصل الاجتماعي.

هل يجب عليّ، بصفتي عميلًا لدى eMudhra، استبدال شهادتي فورًا؟

فقط إذا كانت شهادة TLS الخاصة بكم تعتمد على الشهادة الجذرية emSign ECC Root CA – G3. وبحسب eMudhra، يشمل ذلك اتحادًا واحدًا من العملاء في الولايات المتحدة لديه نحو 30.800 شهادة. وتقول الشركة إن بقية العملاء لا يحتاجون إلى اتخاذ أي إجراء. تحقّقوا من مُصدر شهادتكم قبل التصرف.

كيف أعرف ما إذا كانت شهادتي متأثرة؟

من خلال المُصدر وسلسلة الشهادات: اعرضوا الشهادة في المتصفح أو استخدموا أمر OpenSSL الوارد في قائمة التحقق. تشير أسماء مثل «EM DV TLS CA – G3B» أو «EM OV TLS CA – G3C» أو «emSign ECC Root CA – G3» إلى السلسلة المتأثرة.

هل يجب استبدال المفتاح الخاص لخادمي؟

Nicht wegen dieses Vorfalls. Der Server-Schlüssel ist nach den Quellen nicht betroffen. Beim notwendigen Austausch des Zertifikats empfiehlt sich trotzdem ein neuer Schlüssel.

هل يستطيع المهاجمون إنشاء شهادات مزوّرة لنطاقي؟

Mit den acht Schlüsseln konnte man technisch Zertifikate für beliebige Domains unterschreiben. Das war nur so lange wirksam, wie Browser der Kette vertrauten. Nach den Sperren von Mozilla und Chrome ist das für aktuelle Browser nicht mehr möglich. Bei Geräten, die nicht aktualisiert werden oder die Root fest eingetragen haben, kann das Risiko länger bestehen. Monitoren Sie deshalb die Zertifikate für Ihre Domain.

هل تأثرت شهادات Let’s Encrypt أو سلطات التصديق الأخرى؟

لا، وفقًا للمصادر المنشورة. ولا ترجّح Mozilla تأثر سلطات تصديق أخرى.

ماذا يعني انسحاب eMudhra من نشاط شهادات TLS؟

لم تعد eMudhra تصدر شهادات TLS عامة جديدة. وتستمر خدمات توقيع البرمجيات وS/MIME والتوقيعات الرقمية وeSign. ومن كان يحصل على شهادات TLS من eMudhra يحتاج إلى مزوّد جديد.

هل تأثر Odoo؟

لم يتأثر Odoo نفسه. لكن، كما هو الحال مع أي تطبيق ويب، ينبغي أن تكون شهادة TLS لنطاق Odoo الخاص بكم صادرة عن سلطة تصديق موثوقة. تحقّقوا من المُصدر، خصوصًا إذا لم تكن الشهادات تُجدَّد تلقائيًا.

المصادر

تاريخ الاطلاع: 6 نوفمبر 2026:

• Mozilla Bugzilla، البلاغ 2083449 (تقرير الحادثة، والتسلسل الزمني، وبصمات الشهادات): bugzilla.mozilla.org/show_bug.cgi?id=2083449
• مدونة Mozilla الأمنية، 20.10.2026: حماية مستخدمي Firefox بعد انكشاف المفاتيح الخاصة لشهادات eMudhra الوسيطة
• eMudhra، بيان: emudhra.com/en/post/certificate-security-incident
• The Register, 20.10.2026: انكشاف المفاتيح الخاصة لسلطة التصديق الهندية eMudhra، وكان أحدها العدد 4
• Mozilla dev-security-policy: سلسلة النقاش حول الحادثة
• البحث في سجلات شفافية الشهادات: crt.sh

حدّدنا قيم المفاتيح الثمانية بإعادة حسابها بأنفسنا اعتمادًا على شهادات متاحة للجمهور. أما التصريحات المتعلقة بالسبب، وعدم إصدار شهادات نهائية، وعدد العملاء المتأثرين، فمصدرها eMudhra أو Bugzilla، ولم نتحقق منها بشكل مستقل.

الدعم من Biricon IT Services

إذا لم تكونوا متأكدين من الجهة التي أصدرت شهادات TLS الخاصة بكم، فيسعدنا مساعدتكم في جرد جميع الشهادات على خوادم الويب والبريد وجدران الحماية والأجهزة المتخصصة، والانتقال إلى سلطة تصديق أخرى، واعتماد التجديد التلقائي (ACME)، ومراقبة نطاقاتكم. وبصفتنا مزوّد خدمات تقنية معلومات، نتولى إدارة الخوادم وجدران الحماية وتطبيقات الويب للشركات الصغيرة والمتوسطة.

تواصلوا معنا الآن

آخر تحديث: 6 نوفمبر 2026. قد تتغير الأوضاع؛ والمرجع المعتمد هو منشورات Mozilla وGoogle وApple وeMudhra.