اختراق مفاتيح سلطة التصديق eMudhra: ما الذي يجب على الشركات فحصه وإصلاحه الآن

يوم السبت 17 أكتوبر 2026 أبلغ باحث أمني أن ثماني سلطات تصديق وسيطة تديرها eMudhra، وهي سلطة تصديق هندية، لها مفاتيح خاصة يستطيع أي شخص استنتاجها من الشهادات المتاحة للعموم. كان كل مفتاح منها عدداً أصغر من 256، وكان أحدها العدد 4. ست من الثماني كانت قادرة على إصدار شهادات TLS تثق بها Apple وGoogle وMicrosoft وMozilla؛ والاثنتان الأخريان كانتا قادرتين على توقيع برمجيات Windows.

حجب Chrome مفاتيح TLS الستة بعد ساعة وأربعين دقيقة من البلاغ، وحجبها Firefox في المساء نفسه. فبالنسبة لمن يتصفحون الويب، انتهى الخطر بحلول ليل السبت.

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

وفي الأسبوع نفسه بدأت GoDaddy إلغاء 404,607 شهادة لأن معلومات السياسة الواردة فيها لم تطابق وثائقها المنشورة. وكان على عملائها تنزيل الشهادات البديلة وتثبيتها بأنفسهم.

هذا الدليل موجّه إلى من عليهم الإجابة عن سؤال "هل نحن متأثرون؟": مسؤولي تقنية المعلومات والعمليات، والمديرين التقنيين، والمؤسسين الذين تقوم أعمالهم على موقع إلكتروني أو واجهة API أو منتج متصل. ويتناول ما حدث، كما ورد في سجلات الحادث التي نشرتها Mozilla وGoogle وeMudhra وGoDaddy ومورّدو البرمجيات؛ وما يجب فحصه اليوم؛ وما يجب تحديثه هذا الأسبوع؛ وما يجب إعداده كي يصبح الحادث التالي من هذا النوع أمراً روتينياً. كل ما هنا محدَّث حتى 22 أكتوبر 2026، والحادث ما زال مفتوحاً.

ما الذي حدث

أنشأت eMudhra الشهادات الوسيطة الثماني في مراسم توليد مفاتيح (key ceremony) يوم 30 أبريل 2025. وروايتها، كما نشرتها في تذكرة الحادث لدى Mozilla في 19 أكتوبر: اختبارٌ لخطوة تغليف المفاتيح وفك تغليفها، أُقرّ استثناءً من إجرائها المعتاد، كان فيه خلل أنشأ مجموعة ثانية ضعيفة من المفاتيح في وحدة أمان العتاد (HSM) إلى جانب المفاتيح المقصودة. كانت التسميات متشابهة، فاستُخدمت المفاتيح الضعيفة خطأً لإنشاء طلبات الشهادات، ووقّعها جذر eMudhra. وذهبت الطلبات نفسها إلى Sectigo، التي وقّعت الثماني كلها توقيعاً تبادلياً (cross-signing) من جذرها AAA Certificate Services في 14 مايو 2025. تقول eMudhra إنها "لم تؤكد بعد السبب الجذري الدقيق".

ووصفت Mozilla النتيجة: "المفاتيح الخاصة في P384 أعداد صحيحة تُختار عشوائياً بين 1 ورتبة الزمرة. والمفاتيح الثمانية المتأثرة كلها استخدمت أعداداً صحيحة أقل من 256." تلقّت Mozilla البلاغ الساعة 20:06 UTC واستعادت المفاتيح بنفسها الساعة 21:48، "دون أي معرفة بالطريقة التي استخدمها المُبلِّغ الأصلي". ويقول الباحث إنه عثر عليها بمكتبة paranoid_crypto مفتوحة المصدر من Google، "كما هي، دون أي تعديل". وكانت المفاتيح الضعيفة جزءاً من سلاسل موثوقة علناً طوال قرابة 18 شهراً.

الشهادات الثماني:

كل مفتاح موجود في شهادتين. إحداهما صادرة عن emSign Root TLS CA - G3 أو emSign Root CS CA - G3 لدى eMudhra، وهما تتسلسلان صعوداً إلى emSign ECC Root CA - G3؛ والأخرى هي الشهادة التبادلية التي أصدرتها Sectigo من AAA Certificate Services. والمسار الثاني مهم، لأن بعض مخازن الثقة (trust stores) التي لم تحتوِ قط على جذر من eMudhra ما زالت تثق بذلك الجذر القديم من Sectigo.

هل تعرّض أحد لهجوم؟

لم يُبلغ أحد عن إساءة استخدام، وبالنسبة للمتصفحات هناك سبب وجيه للاعتقاد بأنها لم تحدث. فـ Chrome، مثل برامج العميل الأخرى التي تفرض Certificate Transparency ‏(CT، أي شفافية الشهادات)، لا يقبل شهادة إلا إذا سُجّلت في سجلات CT العامة. وتقول Google إنه لم تُسجَّل أي شهادات TLS تتسلسل إلى هذه الشهادات الوسيطة الست قبل الحجب، ولذلك "لا يمكن أن تكون أي شهادات احتيالية صادرة عن هذه السلطات قد استُخدمت ضد برامج العميل التي تفرض CT".

خارج المتصفح تختلف الصورة. تقول صفحة الحادث لدى Mozilla: "كثير من برامج العميل خارج منظومة المتصفحات لا تفرض Certificate Transparency. ولا نعلم ما إذا كان مهاجمون قد استغلوا الخلل في توليد المفاتيح لاستهداف هذه البرامج." فُتحت تلك النافذة في ربيع 2025، ولا تُغلق أمام كل برنامج عميل إلا حين يُحدَّث. وتقول eMudhra إنها لا تعلم بأي دليل على أن المفاتيح استُعيدت قبل الإفصاح، وتقول Cloudflare إن مراجعتها لم تجد أي استغلال نشط على خدماتها.

والآن بعد أن أصبحت المفاتيح علنية، لم يعد تزوير شهادة يتطلب أي مهارة. وتسرد صفحة الحادث لدى Mozilla خوادم اختبار تقدّم شهادات صادرة بالمفاتيح المخترقة، كي يستطيع أي شخص اختبار برامج العميل لديه عليها (الأوامر أدناه).

ما الذي تتيحه شهادة مزوّرة: من يستطيع اعتراض حركة البيانات بين برمجياتك وخدمة تتصل بها (على شبكة مشتركة، أو عبر جهاز توجيه مخترق، أو رد DNS مسموم) يستطيع انتحال صفة تلك الخدمة، وقراءة ما ترسله برمجياتك، بما في ذلك مفاتيح API والبيانات الشخصية، وتغيير ما تتلقاه. أما البرمجيات الموقّعة بأحد مفتاحي توقيع الشيفرة، فكانت ستجتاز فحص التوقيع في Windows إلى أن يصل حجب Microsoft إلى الجهاز.

من المتأثر

هناك ثلاث مشكلات منفصلة، وقد تجتمع كلها في شركة واحدة.

1. برمجيات ما زالت تثق بالمفاتيح المخترقة

تكاد كل شركة تعاني هذه المشكلة: أي برنامج يُجري اتصالات HTTPS وما زال مخزن الثقة لديه يحتوي على emSign ECC Root CA - G3 أو AAA Certificate Services، ولم يتلقَّ حجباً للمفاتيح الثمانية. المواضع المعتادة:

• خوادم Linux وصور الحاويات المبنية قبل 20 أو 21 أكتوبر. فنظام Debian 12 غير المُرقَّع، مثلاً، يثق بالسلسلتين كلتيهما.
• بيئات تشغيل اللغات التي تأتي بقائمتها الخاصة: Node.js، وcertifi في Python، وملف cacerts في Java، وحزمة Composer في PHP، وwebpki-roots في Rust.
• أدوات سطر الأوامر في macOS. تقول صفحة الحادث لدى Mozilla إن أدوات curl وgit وpython3 وperl وruby وopenssl المدمجة تتحقق من الشهادات مقابل /etc/ssl/cert.pem دون التحقق من الإلغاء، وإن Apple لم تحدّث ذلك الملف.
• أجهزة Windows التي لا تتلقى تحديثات Microsoft التلقائية لقائمة الشهادات غير المسموح بها (disallowed certificate list)، وعادةً لأن نهج المجموعة (Group Policy) يعطّلها أو لأن الشبكة غير متصلة.
• الأجهزة المخصصة (appliances) والأجهزة الأخرى وبرمجيات الأطراف الثالثة التي تضم ملف CA خاصاً بها، مثل موازنات الأحمال وبوابات VPN وحزم SDK ووحدات التحكم المدمجة.

يجب فحص كل بيئة تشغيل على حدة. في اختبار أجريناه في 22 أكتوبر، قبِل جهاز Debian 12 غير مُرقَّع يعمل عليه Node.js 24.18 السلسلةَ التي تنتهي عند جذر eMudhra ورفض التي تنتهي عند جذر Sectigo، بينما قبِل Python على الجهاز نفسه السلسلتين كلتيهما.

2. شركات تتسلسل شهاداتها إلى الجذر المُزال

أزالت Mozilla وتوزيعات Linux الجذر emSign ECC Root CA - G3، وسيتبعها Chrome في 27 أكتوبر. والشهادات الصالحة تحت ذلك الجذر تتوقف عن العمل في كل برنامج عميل حين يُحدَّث. وتعليمات Google أن مشغّلي المواقع الذين لديهم مثل هذه الشهادات "يجب أن يحصلوا فوراً على شهادة TLS جديدة من هرمية PKI أخرى مُدرجة في Chrome Root Store وأن يثبّتوها".

أحصى Chrome في سجلات CT يوم 21 أكتوبر نحو 30,800 شهادة غير منتهية الصلاحية تحت هذا الجذر. منها 30,791 صدرت عن شهادتين وسيطتين لـ InCommon، خدمة الشهادات التي تديرها Internet2 للجامعات ومؤسسات البحث الأمريكية، والتي تصدر شهادات ECC عبر CERTInext، منصة eMudhra. و18 صدرت عن الشهادات الوسيطة الخاصة بـ eMudhra. وتقول eMudhra إن نحو 30,000 شهادة تحتاج إلى ترحيل، نحو 97% منها صادرة عبر ACME، وإنها تصدر شهادات بديلة من هرمية أخرى.

إن كان موقعك خلف Cloudflare في وضع Full (strict) وكان خادم الأصل (origin) يقدّم شهادة تحت هذا الجذر، فإن Cloudflare تقول إن سحب الثقة "سيتسبب في أعطال"، وتطلب من العملاء: "راجعوا شهادات الأصل المخصصة لديكم وإعدادات خوادمكم".

أما شهادات RSA الصادرة عن الجذر الآخر لدى eMudhra، أي emSign Root CA - G1، فلم تتأثر حتى الآن. تقول Mozilla إنها لن تزيل ذلك الجذر "في الوقت الحالي"؛ وChrome "يحقق عن كثب في استمرار إدراج شهادات CA المتبقية لدى eMudhra". إن كنت تعتمد على شهادات eMudhra أو CERTInext من أي نوع، فجهّز سلطة تصديق ثانية الآن.

3. عملاء GoDaddy

لا علاقة لحالة GoDaddy بـ eMudhra، لكنها وقعت في الأسبوع نفسه وأصابت مواقع أكثر بكثير. في 15 أكتوبر أفادت GoDaddy في بلاغ إلى Mozilla بأن الشهادات الصادرة عن هرميتي GoDaddy وStarfield تحمل معلومات سياسة الشهادات (معرّفات OID للسياسات وروابط CPS) لا تطابق الملفات التعريفية (profiles) الواردة في وثيقة CP/CPS الخاصة بها، وهي الوثيقة التي تحدد فيها سلطة التصديق ما تصدره. وهذا ليس ثغرة أمنية في الشهادات. لكنه، بموجب Baseline Requirements، أي القواعد التي تتبعها كل سلطة تصديق عامة، يظل سبباً لإلغائها خلال خمسة أيام.

تأثرت 404,607 شهادة، منها 396,055 من نوع التحقق من النطاق (DV). وقد ألغت GoDaddy منها 170,566 شهادة بحلول الموعد النهائي في 18 أكتوبر الساعة 23:45 UTC، و227,422 بحلول صباح اليوم التالي؛ ويقول إشعارها للعملاء إن البقية أُلغيت في 21 أكتوبر. تعيد GoDaddy إصدار الشهادات، لكن تثبيتها مسؤولية العميل: "قد يرى زوار موقعك تحذيرات أمنية، وقد يتعذر الوصول إلى موقعك حتى تُثبَّت شهادة جديدة."

ما يجب فحصه اليوم

1. ماذا ترسل خوادمك؟ لكل اسم مضيف عام، اعرض جهات الإصدار في السلسلة التي يقدّمها:

h=www.example.com
openssl s_client -connect "$h:443" -servername "$h" -showcerts </dev/null 2>/dev/null | grep -E '^ +i:'

إن ظهر سطر يذكر eMudhra، أو emSign، أو إحدى السلطات EM ... G3B أو G3C، أو InCommon Intermediate CA - DVG3C أو OVG3C أو EVG3C، فيجب استبدال الشهادة قبل 27 أكتوبر. أما ظهور AAA Certificate Services وحده فأمر طبيعي، لأن كثيراً من سلاسل Sectigo العادية ما زالت تتضمنه. ولخدمات البريد والدليل أضف -starttls smtp (أو imap أو ldap) والمنفذ الصحيح. وأدرج المضيفات الداخلية وموازنات الأحمال وخوادم الأصل التي تقع خلف شبكة CDN.

2. ما الذي صدر لنطاقاتك؟ تسرد CT كل شهادة أصدرتها سلطة تصديق عامة لأسماء نطاقاتك، بما فيها شهادات لا يتذكر أحد في الشركة أنه طلبها:

curl -s 'https://crt.sh/?q=%25.example.com&output=json&exclude=expired' | jq -r '.[].issuer_name' | sort | uniq -c

ويُظهر الناتج أيضاً سلطات التصديق التي تستخدمها شركتك فعلاً، وهي بداية الجرد الموصوف لاحقاً.

3. هل تثق برامج العميل لديك بالمفاتيح المخترقة؟ تقدّم خوادم الاختبار لدى Mozilla شهادات صادرة بالمفاتيح المخترقة، ولذلك فإن خطأ الشهادة هو النتيجة الجيدة. اختبر العائلتين: المضيف الأول يتسلسل إلى جذر eMudhra، والثاني إلى جذر Sectigo، وقد يفشل مخزن الثقة في أحد الاختبارين وينجح في الآخر.

curl -sS -o /dev/null https://dv-g3b-emudhra.we-have-a-problem.com/ && echo "TRUSTED: update this system"
curl -sS -o /dev/null https://dv-g3b-aaa-emudhra.we-have-a-problem.com/ && echo "TRUSTED: update this system"

أداة curl لا تجيب إلا عن نفسها. نفّذ الطلب نفسه عبر مكدّس TLS الخاص بكل تطبيق، في البيئة التي يعمل فيها التطبيق:

node -e "require('https').get('https://dv-g3b-emudhra.we-have-a-problem.com/', () => console.log('TRUSTED')).on('error', e => console.log('rejected:', e.code))"
python3 -c "import urllib.request; urllib.request.urlopen('https://dv-g3b-emudhra.we-have-a-problem.com/'); print('TRUSTED')"
python3 -c "import requests; requests.get('https://dv-g3b-emudhra.we-have-a-problem.com/'); print('TRUSTED')"

سطرا Python ليسا تكراراً: تستخدم urllib مخزن نظام التشغيل، وتستخدم requests حزمة certifi. كرر كل سطر مع المضيف dv-g3b-aaa-emudhra. أما في Java، فأجرِ أي اتصال HTTPS بخوادم الاختبار من آلة JVM المعنية، واعرض ما إذا كان مخزنها يحتوي على أي من الجذرين (Java 9 أو أحدث؛ وعلى Java 8 استخدم -keystore $JAVA_HOME/jre/lib/security/cacerts):

keytool -list -v -cacerts -storepass changeit | grep -E 'Owner: .*(emSign ECC Root CA - G3|AAA Certificate Services)'

وجود الجذر في المخزن لا يثبت وحده التعرض للخطر، لأن Go وNode.js وDeno وrustls-webpki في Rust تحجب الآن المفاتيح الثمانية أياً كان ما يقوله المخزن. خوادم الاختبار هي التي تحسم الأمر.

4. أساطيل أجهزة Windows. لم تنشر Microsoft شيئاً عن الحادث، لكن قائمة الشهادات غير المسموح بها التي ينزّلها Windows تلقائياً تحجب المفاتيح الثمانية كلها منذ 20 أكتوبر. الاستثناءات هي الأجهزة التي يعطّل فيها نهج المجموعة التحديثات التلقائية لشهادات الجذر، والشبكات التي لا مسار لها إلى Windows Update؛ وهذه تحتاج إلى إيصال القائمة إليها بطريقة أخرى. يعرض الأمر certutil -verifyCTL Disallowed النسخة المخزنة مؤقتاً على الجهاز. وتقدّم صفحة الحادث لدى Mozilla سكربتاً للأجهزة الفردية وتقول إنه "غير موصى به للأجهزة التي تديرها المؤسسات".

5. شهادات GoDaddy. تحقق من الشهادة التي يقدّمها كل خادم فعلاً:

echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null | openssl x509 -noout -issuer -serial -startdate

إن كانت جهة الإصدار GoDaddy أو Starfield، فقارن الرقم التسلسلي بالشهادات في حسابك لدى GoDaddy. وحيث تعرض GoDaddy عبارة "Install your new certificate" (ثبّت شهادتك الجديدة)، فإن الخادم ما زال يحمل الشهادة الملغاة.

قاعدة واحدة في كل ما سبق: لا تتخلص من خطأ بتعطيل التحقق من الشهادات. وبعبارة Cloudflare: "من المهم ألا تُحَلّ هذه الأخطاء بتعطيل التحقق." فبرنامج العميل الذي لا يتحقق يثق بكل شهادة مزوّرة، لا بهذه وحدها.

ما يجب تحديثه هذا الأسبوع

هناك نوعان من الإصلاح. إزالة الجذرين تغلق كل المسارات أمام برنامج العميل الذي يستخدم ذلك المخزن، لكنها تعطّل أيضاً الشهادات الصالحة تحتهما. أما حجب المفاتيح الثمانية بتجزئة مفتاحها العام، كما تفعل Go وNode.js وDeno وElectron وrustls-webpki وComposer وWindows، فيسد الثغرة ولا يعطّل شيئاً آخر. وحيث توفر منصتك الخيار الثاني، ففضّله.

حيث يقول الجدول "بعد"، فالمعنى أن شيئاً لم يكن قد نُشر حتى 22 أكتوبر. تحقق مجدداً قبل أن تبني خطتك على ذلك.

أربعة أمور تفاجئ الفرق عادةً:

• صور الحاويات تحتفظ بالقائمة القديمة. الصورة المبنية قبل 20 أو 21 أكتوبر تثق بالمفاتيح إلى أن يُعاد بناؤها على صورة أساس محدَّثة، وسحب الوسم (tag) نفسه لا يفيد إلا بعد إعادة بناء صورة الأساس. أعد البناء، وأعد النشر، واسأل المورّدين الذين تشغّل صورهم.
• العمليات تحتفظ بما حمّلته. يقرأ البرنامج مخزن الثقة لديه عند بدء تشغيله، لذا أعد تشغيل الخدمات طويلة التشغيل بعد التحديث. ويضيف Node.js أن جلسات TLS المستأنفة من قبل الترقية لا يُعاد التحقق منها.
• التطبيقات تحمل ملفات CA خاصة بها. كثيراً ما تأتي حزم SDK والتطبيقات بملف cacert.pem أو ca-bundle.crt خاص بها. ابحث عنها في المستودعات والصور، مثلاً بالأمر find / -xdev \( -name 'cacert*.pem' -o -name 'ca-bundle*.crt' \) 2>/dev/null، وتوقّع أن تجد أكثر من واحد: فأداة pip، مثلاً، تحمل نسختها الخاصة من certifi.
• الأجهزة تنتظر مورّدها. اسأل كل مورّد كتابياً عن مخزن الثقة الذي يستخدمه المنتج وموعد صدور التحديث. وإلى أن يصدر، يثق الجهاز بالشهادات المزوّرة لكل خدمة يتصل بها، لذا قيّد ما يمكنه الوصول إليه.

إن أزلت AAA Certificate Services يدوياً، كما تفعل Debian وUbuntu ESM وFedora والحل الالتفافي من Red Hat، فاختبر بعدها الاتصالات بالخدمات التي تستخدم شهادات Sectigo: فبعض الخوادم الأقدم ما زالت ترسل سلسلة تنتهي عند ذلك الجذر.

ما يجب إعداده قبل الحادث التالي

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

لم تكن أي من هذه الحالات الخمس إخفاقاً أمنياً. ففي كل منها خالفت شهادةٌ الوثيقةَ الخاصة بسلطة التصديق نفسها، ومع ذلك تشترط Baseline Requirements (القسم 4.9.1.1) الإلغاء خلال خمسة أيام. وحين يُخترق مفتاح، أو يتعذر الاعتماد على التحقق من النطاق، تكون المهلة 24 ساعة. ولا يستطيع أحد تمديدها لك. ففي إلغاء DigiCert لـ 83,267 شهادة عام 2024، كتب Chrome Root Program أنه "لا يملك صلاحية منح استثناءات"؛ وحصل أحد العملاء على أمر قضائي بوقف إلغاء شهاداته، ثم أُبطل الأمر بعد أربعة أيام.

وطريقة سير الاستبدال تقول الكثير. ففي يوليو استخدمت HARICA معيار ACME Renewal Information (ARI) لتطلب من برامج عميل ACME لدى عملائها التجديد مبكراً، وأعادت إصدار شهادات أخرى بنفسها؛ وفي الأكبر من حالتي الإلغاء لديها، كانت 87% من الأسماء المتأثرة قد استُبدلت عند حلول الموعد النهائي. أما GoDaddy، التي ينزّل عملاؤها كل شهادة بديلة ويثبّتونها بأنفسهم، فكانت قد ألغت 42% من شهاداتها المتأثرة بحلول موعدها النهائي.

ودورة التجديد تقصر على أي حال:

• بموجب الاقتراع SC-081 في CA/Browser Forum، تقتصر صلاحية شهادات TLS العامة على 200 يوم منذ 15 مارس 2026. وينخفض الحد إلى 100 يوم في 15 مارس 2027، وإلى 47 يوماً في 15 مارس 2029، حين لا يمكن إعادة استخدام التحقق من النطاق إلا لمدة 10 أيام.
• تنقل Let's Encrypt إعدادها الافتراضي إلى شهادات مدتها 64 يوماً في 10 فبراير 2027، وإلى 45 يوماً بعد ذلك بعام.
• شهادات TLS العامة تفقد مصادقة العميل. فقد توقفت Let's Encrypt عن تضمينها في شهاداتها في 8 يوليو 2026، ويشترط Chrome Root Program أن تكون الشهادات الصادرة اعتباراً من 15 مارس 2027 لمصادقة الخادم فقط. إن كنت تستخدم شهادات عامة كشهادات عميل في TLS المتبادل (mutual TLS)، وهو أمر شائع في تكاملات API بين الشركات (B2B)، فإن تلك الاتصالات تحتاج إلى سلطة تصديق خاصة.

عند 100 يوم، ثم عند 47، لا يعود تثبيت الشهادات يدوياً خياراً واقعياً. والشركة التي تؤتمت عملها وفق هذا الجدول تكون مستعدة أيضاً للإلغاء الجماعي التالي. وهذا ما يتطلبه ذلك:

1. اعرف ما لديك، في الاتجاهين. قائمة أولى بكل شهادة تقدّمها، مع اسم المضيف وجهة الإصدار وتاريخ الانتهاء وطريقة التجديد والمسؤول عنها. وقائمة ثانية بكل مخزن ثقة تعتمد عليه برمجياتك: حزمة نظام التشغيل، وكل حزمة شهادات خاصة بلغة برمجة، وكل ملف CA داخل تطبيق أو جهاز. بحث CT أعلاه يبدأ القائمة الأولى؛ وقائمة مكوّنات البرمجيات (SBOM) أو جرد التبعيات يبدأ الثانية.
2. أتمت الإصدار والتثبيت. استخدم ACME حيثما أمكن تشغيله، مع ARI ‏(RFC 9773) لكي تستطيع سلطة التصديق أن تطلب من برامج العميل لديك التجديد مبكراً. وحيث لا يستطيع جهاز تشغيل ACME، استخدم الأتمتة التي يوفرها المورّد، أو أنهِ اتصال TLS أمامه على شيء يستطيع ذلك.
3. أبقِ سلطة تصديق ثانية جاهزة. حساب ACME يعمل لدى سلطة ثانية، ومُختبَر، وسجلات CAA في DNS تسمح بالاثنتين. وحين تُسحب الثقة من إحدى السلطات أو تلغي الشهادات بالجملة، يصبح التحويل مجرد تغيير في الإعدادات.
4. راقب CT لنطاقاتك. احصل على تنبيه عن كل شهادة جديدة لأسماء نطاقاتك، فتعلم بأي إصدار غير متوقع في يوم حدوثه.
5. عامل مخازن الثقة كتبعيات. حدّثها ضمن الترقيع المعتاد، وأعد بناء الصور وفق جدول زمني بدلاً من إعادة بنائها فقط عند تغيّر الشيفرة.
6. اكتب دليل التشغيل (runbook) على أساس المؤقتين. 24 ساعة وخمسة أيام: من يقرر، ومن لديه صلاحية الوصول إلى كل نظام، وأي الأنظمة تحتاج خطوات يدوية، وكيف يُتواصل مع كل مورّد. تدرّب عليه مرة في السنة باستبدال الشهادة على خدمة تحتمل الخطأ. فسلطات التصديق العامة ملزمة منذ 2025 بالاحتفاظ بخطة للإلغاء الجماعي خاصة بها واختبارها؛ وعملاؤها يحتاجون إلى النصف الآخر.

إن كنت تصنع منتجات يشغّلها آخرون

إن كان منتجك يحتوي على مخزن ثقة (جهاز، أو تطبيق مثبّت، أو حزمة SDK)، فعملاؤك لا يصبحون محميين إلا حين يصلهم تحديثك. أصدره، وأخبر العملاء بالإصدارات المُصلَحة. ونصيحة Mozilla لمشغّلي مخازن الثقة: احجب الشهادات الوسيطة الثماني إن كانت برمجياتك تستطيع ذلك، وإلا "فادرس ما إذا كان سحب الثقة من الجذور التي وقّعت هذه الشهادات الوسيطة مناسباً".

يسري قانون المرونة السيبرانية هنا من جهتين. فالتزام الإبلاغ فيه، الساري منذ 11 سبتمبر 2026، يشمل الثغرات المستغلّة فعلياً، ولم يُبلَّغ عن أي استغلال في هذه الحالة. ومتطلباته الأساسية، التي تُطبَّق اعتباراً من 11 ديسمبر 2027، تشمل إمكانية معالجة الثغرات عبر التحديثات الأمنية؛ والمنتج الذي لا يمكن تحديث قائمة الثقة فيه لن يستوفيها. والعملاء الخاضعون لـ NIS2 سيسألون مورّديهم عن مدى سرعة تعاملهم مع هذا الأمر، ومن المفيد أن يكون الجواب مكتوباً.

ما الذي ما زال مفتوحاً

• الجذر المتبقي لدى eMudhra. طرح Chrome اثني عشر سؤالاً على eMudhra في 21 أكتوبر، ولم يعلن أي قرار بشأن emSign Root CA - G1. ولن تزيله Mozilla "في الوقت الحالي".
• مسار الترحيل لدى eMudhra. أبلغت Mozilla بأنها ستنقل العملاء إلى هرمية G1 ‏(RSA) لديها؛ بينما تتحدث صفحة الحالة لديها عن "هرمية CA بديلة، تُدار بشكل مستقل، وموثوقة علناً". وقد سأل Chrome عن أيهما المقصود.
• Microsoft وApple. لم تنشر أي منهما بياناً، ولم تُزل أياً من الجذرين من مخزنها.
• إصلاحات معلّقة. لم تكن Red Hat وAmazon Linux وTemurin وCorretto قد أصدرت شيئاً حتى 22 أكتوبر؛ وإصلاح Bun دُمج لكنه لم يُصدر.
• السبب الجذري. لم تؤكده eMudhra، وقالت إنها ستعيد التحقق من كل مراسم توليد مفاتيح أجرتها.
• Sectigo. في قضية منفصلة، مفتوحة منذ 5 سبتمبر، رفضت Sectigo إلغاء شهادات لم يطابق استخدام المفتاح الموسّع (extended key usage) فيها جملةً في وثيقة CPS الخاصة بها، محتجةً بأن الجملة ملتبسة. وفي 18 أكتوبر أحصت نحو 72 مليوناً منها ما زالت نشطة. ودعا بعض المشاركين في النقاش العام إلى سحب الثقة منها؛ ولم يعلن أي برنامج جذور (root program) قراراً. وعلى الشركات التي لديها شهادات من Sectigo متابعة القضية.

أين تحصل على مساعدة

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

• فحص التعرّض. نحدد أين تُجري أنظمتك اتصالات TLS أو تقبلها، وأي مخزن ثقة يستخدمه كل منها، وأي الشهادات تقدّمها، بما في ذلك الحاويات وخدمات Java والتكاملات مع البنوك ومزودي الدفع والخدمات اللوجستية، والأجهزة.
• الإصلاحات. تحديثات، وصور مُعاد بناؤها، ومفاتيح محجوبة أو شهادات مستبدلة، تُنفَّذ عبر عملية إدارة التغيير لديك ويُتحقق منها مقابل خوادم الاختبار لدى Mozilla.
• أتمتة لعام 2027. ACME مع ARI على الخوادم وموازنات الأحمال والأجهزة المخصصة، وسلطة تصديق ثانية، وسجلات CAA، ومراقبة CT، ودليل تشغيل، جاهزة لشهادات الـ 100 يوم اعتباراً من 15 مارس 2027.
• الأنظمة التي لا يريد أحد لمسها. تطبيقات Java القديمة والأجهزة المخصصة وبرامج العميل المدمجة ذات مخازن الثقة الخاصة بها هي بالضبط ما وُجدت لأجله خدمة صيانة الأنظمة القديمة والشيفرة لدينا.

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