في 20 أكتوبر 2026 أصبح معروفًا للعموم أن المفاتيح الخاصة لثمانية مراجع تصديق وسيطة (CA) تديرها eMudhra، وهي جهة تصديق هندية، يمكن لأي شخص استعادتها. وقد حظرت المتصفحات هذه الشهادات في اليوم نفسه الذي أُبلغ فيه عن المشكلة. غير أن كثيرًا من تطبيقات Java ما زالت تثق بها حتى اليوم، وستظل تثق بها إلى أن يحدّث أحدٌ الـ JDK أو يعدّل مخزن الثقة الخاص به.

في 21 أكتوبر 2026 نشرت BellSoft نتائج اختبارات تُظهر أن كثيرًا من بيئات تشغيل Java ما زالت تقبل هذه الشهادات. يلخّص هذا المقال نتائجهم، التي تحققنا منها في اختباراتنا الخاصة، ويشرح لماذا تتأثر Java بينما لا تتأثر المتصفحات، وكيف تفحص أنظمتك، وما الذي ينبغي فعله.

ماذا حدث

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

في 17 أكتوبر 2026 أثبت أحد المُبلِّغين المشكلة بتوقيع الرسالة “We have a problem here” بكل مفتاح من المفاتيح الثمانية، وأرسل التوقيعات إلى برامج الشهادات الجذرية في المتصفحات. ونُشرت التفاصيل للعموم في 20 أكتوبر.

• ستة مراجع وسيطة تُصدر شهادات TLS: مراجع eMudhra DV وOV وEV الخاصة بـ TLS، من الجيلين G3B وG3C.
• مرجعان وسيطان يُصدران شهادات توقيع الشيفرة.
• كل مرجع وسيط موجود مرتين: مرة موقّعًا من جذر emSign التابع لـ eMudhra، ومرة بتوقيع تبادلي من الجذر AAA Certificate Services التابع لـ Sectigo. وفي مخزن الثقة الخاص بـ JDK تنتهي السلاسل عند أحد جذرين: emSign ECC Root CA - G3 (عبر توقيع تبادلي) أو AAA Certificate Services.

تحظر Firefox وChrome الشهادات الوسيطة منذ 17 أكتوبر، وApple منذ 19 أكتوبر، وMicrosoft منذ 20 أكتوبر. وألغت eMudhra الشهادات الثماني جميعها يومي 18 و19 أكتوبر بالسبب CA_COMPROMISE. كما أصدرت توزيعات Linux حزمًا محدّثة لشهادات مراجع التصديق.

ما حجم التأثير

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

• قراءة حركة البيانات بين تطبيق Java والخدمات التي يستدعيها وتعديلها، بما في ذلك كلمات المرور ومفاتيح API والرموز المميزة (tokens)؛
• انتحال صفة مستودعات الحزم أو خوادم التحديث أو واجهات API الخاصة بالشركاء؛
• توقيع شيفرة تبدو صادرة عن ناشر موثوق، عبر المرجعين الوسيطين الخاصين بتوقيع الشيفرة.

لم تظهر هذه الشهادات الوسيطة قط في سجلات Certificate Transparency (CT)، لذا لم يكن ممكنًا مهاجمة المتصفحات التي تفرض CT من خلالها. أما ما إذا كانت المفاتيح قد استُخدمت ضد عملاء يتجاوزون CT فليس معروفًا بعد. وJava من بين هؤلاء العملاء.

لماذا ما زالت Java تثق بهذه الشهادات

نشرت Mozilla وGoogle وApple وMicrosoft الحظر عبر قنواتها الخاصة، مثل OneCRL وCRLite وCRLSets. ولا يقرأ تطبيق TLS الافتراضي في JDK أيًّا منها. وهناك ثلاثة إعدادات افتراضية تُبقي Java مكشوفة:

• مخزن ثقة خاص بها. ما لم يضبط التطبيق javax.net.ssl.trustStore، تثق Java بالجذور الموجودة في $JAVA_HOME/lib/security/jssecacerts إن وُجد هذا الملف، وإلا ففي $JAVA_HOME/lib/security/cacerts. ولا يتلقى ملف cacerts المرفق من المورّد قوائم الحظر الخاصة بالمتصفحات ولا تحديثات شهادات مراجع التصديق في نظام التشغيل. ولا يتغير إلا إذا عدّله مسؤول النظام أو استبدله تحديث للـ JDK.
• لا تحقق من الإلغاء. لا تتحقق Java من إلغاء الشهادات ما لم تفعّل ذلك (قيمة com.sun.net.ssl.checkRevocation هي false افتراضيًا)، لذا فإن إلغاء مرجع التصديق للشهادات غير مرئي في الإعداد الافتراضي.
• لا Certificate Transparency. لا يفرض JDK آلية CT، لذا فالحماية التي شملت مستخدمي المتصفحات لا تنطبق هنا.

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

بيئة التشغيل المختبَرة	مضيفات الاختبار الموثوق بها
Liberica JDK 21.0.10	12 من 12
Liberica JDK 8u504 (صورة حاوية)	12 من 12
Liberica JDK 21.0.12.1 (صورة حاوية)	12 من 12
Eclipse Temurin 25.0.4.1	6 من 12 (جذر eMudhra فقط)
Eclipse Temurin 21.0.12.1 (صورة حاوية، اختبارنا)	6 من 12 (جذر eMudhra فقط)
Arch Linux OpenJDK 27 (مخزن شهادات النظام)	6 من 12 (جذر eMudhra فقط)

الفرق يكمن في جذر Sectigo. فقد كانت Mozilla قد أزالت AAA Certificate Services من قبل، ومخازن الثقة في Temurin وArch Linux مبنية على قائمة Mozilla، لذا يبقى مسار eMudhra وحده مفتوحًا. أما مخزن الثقة في Liberica JDK فما زال يحتوي على ذلك الجذر، لذا يبقى المساران مفتوحين.

ما الأنظمة التي يجب فحصها

• إصدارات JDK المستقلة المستخرجة من أرشيف المورّد أو المثبّتة بأداة التثبيت الخاصة به. وهذه تستخدم ملف cacerts الخاص بها.
• صور الحاويات التي تتضمن JDK. في الصور التي اختبرتها BellSoft، لم يؤدِّ تحديث حزمة ca-certificates في نظام التشغيل إلى تغيير ملف cacerts الخاص بالـ JDK. ولم يُجدِ سحب صورة أساس أحدث أيضًا: فصورة Liberica المختبَرة بتاريخ 21 أكتوبر ظلت تثق بمضيفات الاختبار الاثني عشر جميعها.
• التطبيقات التي لها مخزن ثقة خاص بها، سواء ضُبط عبر javax.net.ssl.trustStore أو في إعدادات خادم التطبيقات أو داخل التطبيق نفسه. تحقق مما إذا كانت تحتوي على الجذرين.
• حزم OpenJDK المقدَّمة من التوزيعات. تحقق مما يشير إليه cacerts. فإذا كان مرتبطًا بمخزن شهادات النظام (في Arch Linux هو رابط رمزي إلى /etc/ca-certificates/extracted/java-cacerts.jks)، فإن تحديث حزمة ca-certificates في التوزيعة يعالج المشكلة. وتسرد صفحة الإفصاح إصدارات الحزم المُصلحة.

كيف تفحص الـ JDK لديك

ابحث أولًا عن الجذرين في مخزن الثقة. تختلف الأسماء المستعارة (aliases) بين المورّدين (يستخدم Liberica JDK الاسم emsigneccrootcag3 [jdk]، ويستخدم Temurin الاسم cn_emsign_ecc_root_ca__g3,...)، لذا ابحث باسم صاحب الشهادة (subject). توجد عدة جذور أخرى من emSign، لكن emSign ECC Root CA - G3 وحده هو المتأثر. على JDK 9 وما بعده:

keytool -list -v -cacerts -storepass changeit | grep -E '^Alias name:|^Owner:' | grep -B1 -E '^Owner: CN=(emSign ECC Root CA - G3|AAA Certificate Services),'

لا يحتوي keytool في Java 8 على الخيار -cacerts، ويوجد مخزن الثقة فيه تحت jre/:

keytool -list -v -keystore "$JAVA_HOME/jre/lib/security/cacerts" -storepass changeit | grep -E '^Alias name:|^Owner:' | grep -B1 -E '^Owner: CN=(emSign ECC Root CA - G3|AAA Certificate Services),'

تطبع كل نتيجة مطابقة الاسم المستعار يليه صاحب الشهادة. دوّن الأسماء المستعارة: ستحتاج إليها في المعالجة.

بعد ذلك اختبر اتصالات حقيقية. يتصل هذا البرنامج الصغير بمضيفات الاختبار الاثني عشر جميعها، ويعمل على Java 8 وكل إصدار لاحق:

import java.net.URI;
import javax.net.ssl.HttpsURLConnection;
import javax.net.ssl.SSLHandshakeException;
public class Check {
    public static void main(String[] args) {
        for (String level : new String[]{"dv", "ov", "ev"})
            for (String gen : new String[]{"g3b", "g3c"})
                for (String via : new String[]{"", "-aaa"}) {
                    String host = level + "-" + gen + via + "-emudhra.we-have-a-problem.com";
                    try {
                        HttpsURLConnection c = (HttpsURLConnection) URI.create("https://" + host).toURL().openConnection();
                        c.setConnectTimeout(10000);
                        c.setReadTimeout(10000);
                        c.connect();
                        c.disconnect();
                        System.out.println("TRUSTED       " + host);
                    } catch (SSLHandshakeException e) {
                        System.out.println("TLS_REJECTED  " + host);
                    } catch (Exception e) {
                        System.out.println("ERROR         " + host + " (" + e + ")");
                    }
                }
    }
}

على JDK 11 أو ما بعده، شغّله بالأمر java Check.java. أما على Java 8، أو حيث لا يوجد إلا JRE مثبتًا، فاترجمه أولًا بالأمر javac Check.java (على جهاز به JDK إن لزم الأمر)، ثم شغّل java Check. يعني السطر TRUSTED أن هذا الـ JDK يقبل مرجعًا وسيطًا مخترقًا. ويعني ERROR أنه تعذّر الوصول إلى المضيف، وهذا لا يثبت شيئًا في أي من الاتجاهين. شغّل الفحص بالـ JDK نفسه وإعدادات مخزن الثقة نفسها التي يستخدمها تطبيقك، بما في ذلك داخل حاوياتك.

كيف تعالج المشكلة

1. احذف الجذرين (يُوصى به إلى أن يُطرح JDK مُصلح)

هذان هما الجذران نفساهما اللذان توصي صفحة الإفصاح مستخدمي Linux وmacOS بسحب الثقة منهما. شغّل الأوامر بصلاحيات المستخدم المالك للـ JDK، مستخدمًا الأسماء المستعارة التي وجدتها في الفحص. على سبيل المثال، على Liberica JDK:

keytool -delete -cacerts -storepass changeit -alias "comodoaaaca [jdk]"
keytool -delete -cacerts -storepass changeit -alias "emsigneccrootcag3 [jdk]"

على Java 8، استبدل -cacerts بـ -keystore "$JAVA_HOME/jre/lib/security/cacerts". وإذا كان مخزن الثقة لديك يحتوي على جذر واحد فقط من الجذرين، كما هي الحال في Temurin، فاحذف ذلك الجذر وحده.

إذا لم تتمكن من تعديل تثبيت الـ JDK، فعدّل نسخة منه ووجّه JVM إليها:

cp "$JAVA_HOME/lib/security/cacerts" ./trimmed-cacerts
keytool -delete -keystore ./trimmed-cacerts -storepass changeit -alias "comodoaaaca [jdk]"
keytool -delete -keystore ./trimmed-cacerts -storepass changeit -alias "emsigneccrootcag3 [jdk]"
java -Djavax.net.ssl.trustStore=./trimmed-cacerts -Djavax.net.ssl.trustStorePassword=changeit -jar app.jar

في اختباراتنا، أدّت كلتا الطريقتين إلى رفض Liberica JDK 8 و21 لمضيفات الاختبار الاثني عشر جميعها، بينما ظلت المواقع العادية مثل sectigo.com وgithub.com تتصل بنجاح.

بالنسبة لصور الحاويات، احذف الجذرين أثناء البناء حتى تكون كل صورة جديدة مُعالَجة:

FROM bellsoft/liberica-runtime-container:jdk-21-musl
RUN keytool -delete -cacerts -storepass changeit -alias "comodoaaaca [jdk]" \
 && keytool -delete -cacerts -storepass changeit -alias "emsigneccrootcag3 [jdk]"

تحتاج صور distroless والصور التي لا تعمل بصلاحيات root إلى تغييرين: فهي لا تحتوي على shell، لذا استخدم صيغة exec للأمر RUN بأمر واحد في كل سطر، وهي تعمل بمستخدم غير مميز، لذا انتقل إلى USER root لإجراء التعديل ثم عُد بعده إلى المستخدم المعتاد للصورة.

2. فعّل التحقق من الإلغاء (اختياري)

ألغت eMudhra الشهادات الوسيطة الثماني جميعها، لذا فإن JVM الذي يتحقق من الإلغاء يرفضها دون أي تغيير في مخزن الثقة. فعّل نقاط توزيع CRL وOCSP:

echo 'ocsp.enable=true' > revocation.security
java -Dcom.sun.net.ssl.checkRevocation=true \
     -Dcom.sun.security.enableCRLDP=true \
     -Djava.security.properties=revocation.security \
     -jar app.jar

في اختباراتنا، أدى ذلك إلى رفض مضيفات الاختبار الاثني عشر جميعها على Liberica JDK 8 و21 وعلى Temurin 21. لكنه يغيّر طريقة التحقق من صحة كل شهادة. إذ يُجري JVM استعلامات OCSP أو CRL أثناء التحقق من المسار، وقد تفشل عملية المصافحة (handshake) عندما يتعذر تحديد حالة الإلغاء. وقبل تفعيله على نطاق شامل، اختبر ما إذا كان يمكن الوصول إلى خوادم الاستجابة من خوادمك، ومقدار زمن التأخير الذي تضيفه، وكيف يكون السلوك عند الإخفاق. استخدمه إن كنت تعمل أصلًا مع التحقق من الإلغاء، أو إلى جانب حذف الجذرين.

3. حدّث الـ JDK عند توفر إصدارات مُصلحة

أعلنت BellSoft أنها تُعدّ تحديثات لـ Liberica JDK تزيل هذين الجذرين. تابع النشرات الأمنية الصادرة عن مورّد JDK الخاص بك. وعند طرح التحديث، اقرأ ملاحظات الإصدار للتأكد من أنه يشمل شهادات eMudhra، ثم ثبّته، وأعد بناء صور الحاويات، وشغّل الفحص مجددًا. فرقم الإصدار الأحدث وحده ليس دليلًا.

بعد المعالجة: راجع مدى انكشافك

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

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

لمزيد من القراءة

• eMudhra Intermediate CA Compromise: صفحة الإفصاح، وتتضمن مضيفات الاختبار وإصدارات الحزم المُصلحة
• BellSoft: Distrusting compromised eMudhra intermediates in Java