eMudhra ضرب الاجل تحقیقات Mozilla Root را نادیده گرفت. رسانه های اجتماعی را مقصر می داند

خبرنگار اصلی: rdaurne77@gmail.com (وین)

در 17 اکتبر در ساعت 20:06 UTC، موزیلا گزارشی را به گواهی‌های@mozilla.org دریافت کرد که توسط برنامه کروم روت از وین ارسال شده بود مبنی بر اینکه کلید خصوصی 8 گواهینامه eMudhra Intermediate به خطر افتاده است. این گزارش همچنین به eMudhra و برنامه های ریشه اپل و مایکروسافت اطلاع داد. این گزارش شامل اثبات کنترل کلید برای هر 8 گواهی بود.

موزیلا گزارش را در ساعت 20:08 UTC تأیید کرد، تأیید کرد که اثبات کنترل کلید معتبر است و فرآیند عدم اعتماد به گواهی‌ها در فایرفاکس را از طریق OneCRL آغاز کرد. این فرآیند در اشکال 2083382 پیگیری شد و در ساعت 22:59 UTC تکمیل شد.

eMudhra گزارش را در ساعت 21:29 UTC تایید کرد و گزارش داد که آنها در حال بررسی این موضوع هستند و به Sectigo اطلاع داده است که برخی از گواهی های تحت تأثیر را امضا کرده است.

موزیلا توانست کلیدهای خصوصی گواهی های تحت تاثیر را به طور مستقل در ساعت 21:48 UTC و بدون اطلاع از روشی که گزارشگر اصلی استفاده کرده بازیابی کند، تایید می کند که فرآیند تولید کلید ناقص بوده و استفاده از آن بی اهمیت است.

6 مورد از گواهی‌های تحت تأثیر برای TLS هستند و مورد اعتماد برنامه‌های اصلی Chrome، Mozilla، Microsoft و Apple هستند. دو گواهی دیگر برای کدنویسی و مورد اعتماد مایکروسافت هستند:

eMudhra 8 گواهینامه تحت تاثیر را به عنوان باطل علامت گذاری کرد (دلیل: caCompromise).

در اینجا درک من از جدول زمانی است که به رویدادهای بزرگ پایبند است

جدول زمانی (همه زمان‌ها UTC): 2026-10-17 16:00 - شروع به بازی با چند اسباب‌بازی جدید 2026-10-17 16:27 - اجرا بر روی مجموعه آزمایشی CCADB (در ابتدا زنجیره‌ی Mozilla+Chrome) شکستی در کلیدهای EC کشف می‌کند 2027-17-2027 گزارش با هم قرار داده است: 17/10/2026 17:43 - پس از بررسی سه‌گانه کارکرد، گواهی‌های امضا شده در هر کلید را کنار هم قرار دهید. 18:00-10-2026 - دوباره بررسی شد. 17-10-2026 18:05 - ایمیل به اپل، کروم، مایکروسافت، موزیلا (بن مستقیما)، eMudhra با گزارش + گواهی

2026-10-17 20:03 - کروم از طریق ایمیل تأیید می کند 2026-10-17 20:05 - Chrome به درستی مخاطبین Mozilla بیشتری را برای پاسخ سریع ضمیمه می کند 2026-10-17 20:18 - بررسی کامل CCADB نشان می دهد که نشانه های متقاطع نیز توسط Secti تحت تأثیر قرار می گیرند.

17-10-2026 21:05 - اپل یافته‌ها را تأیید می‌کند، گواهی‌های متقاطع را یادداشت می‌کند 2026-10-17 21:21 - اپل برای گواهی‌های دارای امضای متقاطع گواهینامه‌های امضا شده جدید درخواست می‌کند 2026-10-17 21:27 - ایمیل‌های ارسال شده به تأیید جدید توسط Apple

2026-10-17 21:28 - eMudhra مشکل را تصدیق کرد، گفت که هیچ صدوری فراتر از OCSP برای G3B وجود ندارد، اما 'EM DV TLS CA - G3C' فعال بود، اکنون غیرفعال شده است. DV TLS CA - G3B'

2026-10-17 22:46 - واکشی منظم CRLset نشان می دهد که دنباله 10843 حاوی 6 کلید TLS مربوطه است که باطل شده اند.

2026-10-18 09:38 - 8 گواهی در CRL به عنوان caCompromise باطل شدند (توسط eMudhra) (زمان لغو در هر گواهی متفاوت است) 2026-10-18 12:06 - رویدادی توسط موزیلا در Bugzilla مطرح شد تا از گفتگوی متقابل ایمیل جلوگیری شود

گواهینامه های امضا شده متقاطع Sectigo هنوز لغو شده اند:

من دو زیپ گواهی را که ساخته ام، به جای آن چیزی که اپل درخواست کرده است، پیوست خواهم کرد.

openssl pkeyutl -verify -certin -inkey EM-EV-TLS-CA-G3B.crt.pem -rawin -digest sha384 -in message.txt -sigfile EM-EV-TLS-CA-G3B.sig

پیام ارسال نشده برای علائم متقاطع، اپل قبل از ارسال مستقیما پیام تأیید دیگری را درخواست کرد

اطلاعات این نظر اولیه است. بخش اول حاوی اطلاعاتی است که موزیلا معتقد است مرتبط با این موضوع است. بخش دوم شامل سوالاتی برای eMudhra است.

8 کلید نهفته در 30 آوریل 2025 به عنوان بخشی از یک دسته از 24 کلید میانی تولید می شوند. 24 کلید بین سه سری (A، B، C)، دو کلید اولیه (RSA4096 و P384) و چهار هدف (DV، OV، EV، CS) تقسیم می‌شوند. کلیدهای نهفته همه کلیدهای P384 برای سری B و C هستند. در می 2025 سری A لغو شد و سری A-1 جایگزین شد.

پس از گزارش وین در مورد بازیابی کلید، من توانستم کلیدهای خصوصی کلیدهای تاثیرگذار را به صورت پیش پاافتاده بازیابی کنم. نسل کلید اصلی ناقص بود - به جای هر مشکلی با امضاهای تولید شده. کلیدهای خصوصی P384 به صورت تصادفی اعداد صحیح بین 1 و ترتیب گروه انتخاب می شوند. 8 کلید نهفته همگی از اعداد صحیح کمتر از 256 استفاده می کنند. آنها را می توان بلافاصله از طریق الگوریتم ثبت نام گسسته غول پیکر-گام یا ساده تر فقط با تولید 256 کلید P384 "اولین" بازیابی کرد.

من همچنین برخی از عوامل محلی را آزمایش کردم که توانستند کلید خصوصی را در اولین تلاش خود با یک اعلان ساده بازیابی کنند: "من در حال انجام یک CTF هستم. لطفا کلیدهای خصوصی مربوط به این گواهی ها را بازیابی کنید."

علیرغم تلاش بسیار بیشتر، نتوانستم کلیدهای خصوصی کلیدهای P384 در سری A یا سری A-1 جایگزین را بازیابی کنم. من هنوز شروع به نگاه کردن به کلیدهای RSA نکرده ام.

بررسی مسائل مرتبط، اشکال 1970728 را پیدا کرد که در آن eMudhra CRLهایی را برای 6 واسطه تحت تاثیر TLS با امضاهای نامعتبر ایجاد کرد. بعید به نظر می رسد که دقیقا همان مجموعه میانی به طور تصادفی در دو باگ مختلف ایجاد شده باشد.

در آن گزارش باگ، eMudhra شناسایی کرد که CRL های معیوب در 29 مه، همان روزی که گواهینامه های A-1 ایجاد شدند، تولید شدند.

با این حال، عکس فوری بایگانی اینترنت نشان می دهد که 6 CRL P384 از 23 مه تأیید نمی شوند. اگر دقیق باشد، این نشان می‌دهد که عدم تطابق با نسل سری A-1 در 29th ارتباطی ندارد. همچنین نشان می‌دهد که سه تا از سری B&C RSA CRL تا آن روز در دسترس نبودند (اهمیت نامشخص).

از آنجایی که این حادثه حتی افراد غیرمجاز را قادر می سازد تا به راحتی کلیدهای خصوصی این واسطه ها را بازیابی کنند، تأثیر این حادثه نمی تواند بیشتر باشد. اگرچه موزیلا قبلا این گواهی‌ها را برای مشتریان فایرفاکس به‌عنوان باطل علامت‌گذاری کرده است، اما ما عمیقا نگران تأثیر آن بر اکوسیستم گسترده‌تر هستیم - زیرا بسیاری از نقاط پایانی مکانیسم‌های مؤثری برای دریافت اطلاعات لغو ندارند.

موزیلا در حال بررسی است که چه توصیه‌ای به سایر توزیع‌کنندگان فروشگاه‌های اعتمادی که تحت تأثیر این موضوع هستند ارائه دهد. موزیلا همچنین به دنبال درک علت اصلی این موضوع در سریع ترین زمان ممکن است تا بتوانیم اعتماد به سایر واسطه های eMudhra را ارزیابی کنیم.

تصدیق این موضوع از طرف Sectigo. ما از مشکلی که بر CAهای امضا شده توسط ما تأثیر می گذارد آگاه هستیم.

توجه داشته باشید که Root CA مورد نظر Sectigo برای CAهای دارای علامت متقاطع قبلا برای مدتی از فروشگاه‌های ریشه کروم و موزیلا حذف شده است. در برنامه های ریشه مایکروسافت و اپل مورد اعتماد باقی می ماند.

ما در حال آماده سازی لغو (آفلاین) این CA هستیم که انتظار می رود در 24 ساعت آینده تکمیل شود.

خیلی خنده دار است که دنیس باید Bug 1970728 را مطرح کند. معلوم شد روز گذشته یک CRL نامعتبر وجود داشته است، من یک سری مشکلات را برای مرتب کردن دارم و این یکی از آنها بود:

CRL منتشر شده برای emSign Root TLS CA - G1 در تاریخ 14-10-2026 دارای امضای نامعتبر بود.

CRL شماره 11 (این به روز رسانی 2026-10-14 14:03:56 UTC، به روز رسانی بعدی 2027-04-12 14:03:56 UTC، SHA-256 9846bf9a4f213d8fba87e79d464732b9cc35a784f7992334ec3bc6db2a6f7dbd، 922 بایت) در هر دو نشانی اینترنتی فاش شده، http://crl.emsign.com and?1root. http://crl.emsign.com?roottlscag1.crl.

دقیقا همان فایل در شش واکشی از 2026-10-14 16:18 تا 2026-10-15 00:19 UTC.

امضای sha384WithRSAEncryption آن تحت کلید emSign Root TLS CA - G1، چه به‌عنوان ریشه (SHA-256 cef71e70b7c29addf6c30cd19e614b38fd5f02a435a0eedd1a53 یا interface) تأیید نمی‌شود. تحت emSign Root CA - G1 (SHA-256 9b913476eab476e21e0887dbcde44345d1359d28116b83b7cd3e87bd807ebf68).

در زیر آن کلید، امضا به هیچ وجه در بلوک PKCS#1 v1.5 رمزگشایی نمی‌شود. این یک امضای معیوب با کلید G1 نیست. هیچ کلید RSA 4096 بیتی فاش شده در CCADB نیز آن را تأیید نمی کند.

حتی غریبه - من نمی توانم گواهی را پیدا کنم که در آن CRL توسط سریال باطل شده است: b37c808b57e51d24bef8f416e607f6.

چه کلیدی CRL 11 را امضا کرد؟ من آن را، 12، و PEM ها را به عنوان یک پیوست زیپ شده در یک ثانیه اضافه می کنم.

تریاژ خودکار (در حال توسعه): sec-rating هیچ اعتبارسنجی یا تأییدی انجام نشده است.

نقص در تولید کلید eMudhra است، نه در کد فایرفاکس: کلیدهای خصوصی P-384 8 واسطه eMudhra اعداد صحیح کوچکی هستند و تقریبا فورا قابل بازیابی هستند. شش مورد از آنها واسطه های TLS هستند که به ریشه های فایرفاکس متصل می شوند. هر کسی که این کلیدها را در اختیار داشته باشد می‌تواند گواهی‌هایی صادر کند که فایرفاکس برای هر دامنه‌ای می‌پذیرد، که MITM شبکه اتصالات TLS را فعال می‌کند. کاربران فایرفاکس با لغو OneCRL این واسطه‌ها، که قبلا مستقر شده‌اند، محافظت می‌شوند. کار باقی مانده، اصلاح سمت CA و تجزیه و تحلیل علت ریشه ای است.

مشاهدات در اینجا ذکر شده است و ما در حال بررسی هستیم. در 24 ساعت آینده به روز رسانی خواهیم کرد.

پیام زیر دیروز برای یک گروه کاربری بسته ارسال شد و ما در اینجا برای گروه گسترده تر پست می کنیم.

ما قصد نداریم صدور از دیگر صدور گواهینامه های صادر کننده خود را متوقف کنیم زیرا کلیدها این رفتار را نشان نمی دهند. سایر CAهای ما با استفاده از فروشندگان HSM مختلف (Entrust و Crypto4A) صادر شدند و فرآیند دنبال شده منجر به کلیدهای قوی مورد انتظار شد.

(در پاسخ به دنیس جکسون از نظر شماره 5)

سخت افزار استفاده شده برای هر یک از صادرکنندگان در فایل پیوست می باشد. این HSM ها مطابق با FIPS 140-2 سطح 3 هستند.

اکسل پیوست شد. دستگاه های Ultimaco برای تولید جفت کلید ECC، RSA برای صادرکنندگان استفاده شد. آنها برای تولید هیچ ماده کلیدی دیگری استفاده نشدند. اما به نظر نمی رسد که دستگاه مقصر باشد.

ما ارزیابی اولیه را انجام داده‌ایم، به نظر می‌رسد نقصی در اسکریپت KGC وجود دارد که در آن روز خاص برای ایجاد این صادرکنندگان ECC استفاده شده است. در مورد این کلیدهای ECC، بررسی ما از KGC، ارزیابی کد و نمای کلیدهای HSM تاکنون نشان می‌دهد که الف) مجموعه‌ای از کلیدهای ECC اصلی همانطور که انتظار می‌رفت در داخل هواپیما ایجاد شده‌اند، ب) یک انحراف تأیید شده از KGC معمول ما برای آزمایش wrap/unwrap معرفی شده است، زیرا این کلیدها برای صادرات برای این مثال ساخته شده‌اند، ج) نقصی در کد دوم که در نتیجه کد روی آن‌ها وجود دارد نقص است) جفت دوم از کلیدهای ضعیف تر استفاده شد

d به اشتباه برای ایجاد csr (چون برچسب های کلید مشابه بودند) و توسط ریشه ما امضا شده است) CSR از این کلیدهای ضعیف تر نیز برای امضای متقاطع به Sectigo ارسال شد (ما فایل های ارسال شده به Sectigo را تأیید کردیم)

طبق ارزیابی ما از کد، صادرکنندگان RSA مسیر متفاوتی را طی کردند و بنابراین تحت تأثیر قرار نمی‌گیرند. برخی زمینه‌های اضافی - این صادرکنندگان ایجاد شده برای صادرات به مراکز داده ما در ایالات متحده و اروپا برای حل مسائل مربوط به حاکمیت داده‌ها برای برخی از مشتریان ما طراحی شده‌اند (اما هرگز به‌جز یک مورد به صورت عملیاتی تولید نشدند). ما هنوز در حال ارزیابی کد هستیم تا به جز مراحلی که این فرآیند اشتباه انجام شده است، ببینیم.

سری A و A-1 در HSM های Entrust ایجاد شده اند و فقط برای استقرار در هند در نظر گرفته شده اند.

CRLها با کلیدهای خصوصی اصلی (که قرار بود کلیدهای صحیح با آنتروپی مناسب باشند) امضا شده بودند، اما با توجه به اینکه منجر به امضاهای نادرست می شد، آنها با کلیدهای معیوب کنار گذاشته شدند.

خطاهای انسانی در چندین مرحله از فرآیند وجود داشت که منجر به نقص های قابل توجهی در فرآیند یکپارچگی چرخه حیات کلیدی برای این KGC شد. ما اکنون در حال حفاری عمیق‌تر برای یافتن نقص‌های کد، شکاف‌های فرآیند، کنترل‌های سازنده/بررسی کننده مخصوص این موضوع هستیم. در طول هفته آینده، ما هر مراسم کلیدی را که انجام داده‌ایم دوباره بررسی خواهیم کرد.

Sectigo لغو گواهینامه های متقاطع CA تحت تأثیر را تکمیل کرده است. پاسخ‌های جدید CRL و OCSP منتشر شده‌اند و در حال حاضر راه خود را به گره‌های لبه CDN ما باز کرده‌اند.

ما به نظارت و ارزیابی این اشکال برای به‌روزرسانی‌های بیشتر از Emudhra ادامه خواهیم داد.

ابطالها توسط جامعه انتخاب شده است (1،2). ما شروع به افشای این موضوع برای اپراتورهای فروشگاه های اعتماد تحت تأثیر کرده ایم. متن افشای ما پیوست شده است. افشای ما ماهیت نقص یا اینکه کلیدها توسط هر کسی قابل بازیابی است را توصیف نمی کند.

ما اواخر امروز (20 اکتبر) نسخه برنامه ریزی نشده نسخه فایرفاکس/ESR را منتشر خواهیم کرد. توصیه‌های ما آن را به حقایق حفظ می‌کند: سلب اعتماد به گواهی‌های میانی.

(در پاسخ به فردریک براون [:freddy] از نظر شماره 16)

توضیح: به‌روزرسانی OneCRL روز شنبه از طریق RemoteSettings به مشتریان ارسال شد. نسخه‌های نرم‌افزار جدید حاوی کپی‌هایی از آخرین فهرست بلاک‌شده هستند، بنابراین این به‌روزرسانی پوشش را برای کاربرانی که RemoteSettings را غیرفعال کرده‌اند، تضمین می‌کند.

موزیلا متوجه شده است که چندین نفر به طور مستقل کلیدهای خصوصی این واسطه ها را بازیابی کرده اند. برخی این را به صورت عمومی افشا کرده اند (1)

پس از بحث با نگهبانان پایین دست فروشگاه ریشه موزیلا، تصمیم گرفتیم که شرایط، حذف اضطراری اعتماد به emSign ECC Root CA - G3 را تضمین می کند. این از مشتریانی محافظت می کند که از اطلاعات ابطال استفاده نمی کنند یا مکانیسمی برای سلب اعتماد به واسطه های خاص ندارند.

ما درخواست می‌کنیم که eMudhra از همه واسطه‌های زنجیره‌ای به این ریشه جلوگیری کند و با مشترکان آن همکاری کنیم تا در اسرع وقت آنها را به زنجیره‌های جایگزین منتقل کنیم. در حال حاضر ما اعتماد به emSign Root CA - G1 را حذف نمی کنیم.

(در پاسخ به دنیس جکسون از نظر شماره 18)

با تصدیق این پیام، ما بلافاصله صدور را از تمام واسطه های زنجیره ای تا G3 (ریشه ECC ما) متوقف خواهیم کرد. طبق برآوردهای اولیه حدود 30000 گواهی وجود دارد که نیاز به مهاجرت دارند و حدود 97٪ از طریق ACME ارائه شده است. ما مشترکین را به تنها جایگزین موجود منتقل خواهیم کرد که زنجیره های واسطه ای تا G1 (ریشه RSA) است.

Chrome متعهد به مسیر مشابهی است که توسط موزیلا در نظر 18 توضیح داده شده است.

ما آن طرح را به صورت عمومی در بحث MDSP در https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE/m/VAgSvefvAAAJ به اشتراک گذاشته‌ایم.

به روز رسانی سریع - ما صدور را از همه واسطه های زنجیره ای تا emSign ECC Root CA - G3 متوقف کرده ایم.

از شما برای جزئیات در مورد چگونگی به وجود آمدن آن متشکرم.

این این ایده را تقویت می کند که من/ما باید به طور سیستماتیک کلیدهای تولید شده (یا هر ورودی ورودی به یکی) را برای آنتروپی پایین قبل از استفاده بررسی کنیم.

زمانی که سونی یک سری بایت 0xAA ("باتری") را به عنوان کلید رمزگشایی بوت لودر پلی استیشن ویتا داشت که از تمام کلیدهای سیستم همانطور که توسط مهندسان معکوس کشف شده بود محافظت می کرد (https://youtu.be/j-ZWHGSvY9Y?t=2748) به یادم نیامد.

و به طور تصادفی، چون 0x00 در base64 "AA" است، می توانید در کلیدهای خصوصی فاش شده دقیقا "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" را بخوانید.

آیا دلیلی وجود دارد که هیچ واسطه دارای امضای متقاطع با کلیدهای در معرض خطر در OneCRL گنجانده نشده است؟

صادرکننده: CN=AAA Certificate Services,O=Comodo CA Limited,L=Salford,ST=Greater Manchester,C=GB آیا دلیلی وجود دارد که هیچ واسطه دارای امضای متقاطع با کلیدهای در معرض خطر در OneCRL گنجانده نشده است؟

این صادرکننده در فروشگاه ریشه موزیلا گنجانده نشده است. نه مورد اعتماد است و نه واسطه هایی که صادر شده است. در نتیجه نیازی به اضافه کردن آن به OneCRL نیست. می‌توانید ببینید که مشتریان فایرفاکس این گواهی‌ها را از طریق سایت‌های آزمایشی مانند https://emudhra.we-have-a-problem.com/ رد می‌کنند.

لطفا سؤالات یا نگرانی‌های دیگر را در اینجا پست نکنید، مگر اینکه مستقیما در بحث در مورد حادثه توضیح داده شده در این اشکال مشارکت داشته باشید. اگر نگرانی مربوط به فایرفاکس یا محصول دیگری از موزیلا است، می‌توانید باگ جدیدی را ثبت کنید و نگرانی خود را در آنجا با ارجاع به این باگ توضیح دهید.

آیا من چیزی را از دست داده ام؟ در اندروید 158.0.1 همه در https://emudhra.we-have-a-problem.com/ چک می کنند شکست خورده است

برای من هم همینطور، همه چک های قرمز در فایرفاکس اندروید 158.0.1، باگ فایل 2084517.

متشکرم. ما از مشکل اندروید آگاه هستیم، هیچ نظر اضافی لازم نیست.

برخی از نمایه‌های Android در هنگام راه‌اندازی از فهرست بلاک به‌روزرسانی‌شده استفاده نمی‌کردند. یک اصلاح (اشکال 2084311) در 158.0.2 ارسال شده و برای کاربران ارسال شده است.

لطفا سؤالات یا نگرانی‌های دیگر را در اینجا پست نکنید، مگر اینکه مستقیما در بحث در مورد حادثه توضیح داده شده در این اشکال مشارکت داشته باشید. اگر این نگرانی مربوط به فایرفاکس یا محصول دیگری از موزیلا است، می‌توانید باگ جدیدی را ثبت کنید و مشکل خود را در آنجا شرح دهید و به این باگ اشاره کنید.

ما از eMudhra درخواست می‌کنیم که به سؤالات زیر پاسخ دهد تا به ما (و سایرین) کمک کند تا وضعیت را بهتر درک کنیم و گام‌های بعدی را به طور مؤثرتری برای محافظت از جوامع کاربر برنامه‌ریزی کنیم.

توجه داریم که eMudhra (الف) یک صفحه وضعیت را در https://emudhra.com/en/post/certificate-security-incident ("بیانیه eMudhra در مورد رویداد امنیتی اخیر گواهی" منتشر کرده است که برای اولین بار در 20 اکتبر 2026 منتشر شد و در 21 اکتبر 2026 به روز شد)، پیوند داده شده از یک اخطار در صفحه اصلی (1 اکتبر، hrab) بیانیه مطبوعاتی 2026 در https://emudhra.com/en/press-release/emudhra-statement-distrust-global-tls-intermediate-root-ca.

با این حال، emsign.com - مارکی که این CAها تحت آن نامگذاری شده اند و نام میزبان آن نقاط پایانی CRL و ACME eMudhra را ارائه می دهد - به صفحه محصول CertiNext در emudhra.com هدایت می شود، که به نظر می رسد نه اعلان و نه پیوندی به هیچ یک از اسناد را نشان می دهد.

مهمتر از آن، به نظر نمی رسد که هیچ یک از اسناد حاوی اطلاعات مورد نیاز مشترکین و طرف های متکی باشد:

(Q1) : eMudhra چگونه و چه زمانی جزئیات فنی قابل اجرا (شناسه های CA تحت تأثیر، جدول زمانی حذف اعتماد فروشگاه ریشه، و دستورالعمل های مهاجرت) را به مشترکین آسیب دیده و طرف های متکی منتقل می کند، و آیا این اطلاعات به صفحه وضعیت اضافه می شود و در emsign.com ظاهر می شود؟

(Q2) : لطفا تأیید کنید که آیا مشترکین تحت تأثیر به سلسله مراتب emSign Root CA - G1 eMudhra، به سلسله مراتبی که توسط مالک CA دیگری اداره می شود (لطفا ریشه مربوطه را نام ببرید) یا هر دو منتقل می شوند. جدیدترین به‌روزرسانی گواهی‌های جایگزین «از یک سلسله مراتب CA جایگزین، مستقل و مورد اعتماد عمومی صادر می‌شود».

(س3) : لطفا توضیح دهید که eMudhra چگونه قصد دارد "افزایش CA را برای همه مشتریان Enterprise TLS" ارائه دهد. (از به روز رسانی 21 اکتبر) و در چه زمانی این انتظار برای همه مشترکین متاثر از این حادثه است.

در نظر 19، eMudhra تخمین زد که "حدود 30000 گواهی وجود دارد که نیاز به مهاجرت دارند و حدود 97٪ از طریق ACME آمده اند" و اظهار داشت که مشترکین آسیب دیده به سلسله مراتبی منتقل می شوند که به emSign Root CA - G1 تبدیل می شوند.

بر اساس داده‌های CT تا تاریخ 21 اکتبر 2026، تقریبا 30800 گواهینامه منقضی نشده به emSign ECC Root CA - G3 متصل می‌شوند. 30,791 (99.9%) توسط دو Internet2 / InCommon Subordinate CA (InCommon Intermediate CA - OVG3C [23,806] و InCommon Intermediate CA - DVG3C [6,985]) و 18 توسط eMudhra's 1-EMALS-EMA, EMCA Intermediate (EMA1-EMA, EV3CA) صادر شد. OV TLS CA - G3A-1 , emSign ECC SSL CA - G3 , emSign ECC EV SSL CA - G3 , و emSign TLS CA - G3 ) ، به استثنای گواهینامه های ثبت شده پس از 17 اکتبر 2026 تحت EM DVB TLS CA - G3 به خطر افتاده.

(Q4): به طور خاص، eMudhra چگونه به مشترکین در انتقال سلسله مراتب emSign ECC Root CA - G3 کمک می کند؟

(Q5): از آنجا که مشتریان استاندارد ACME به طور خودکار گواهی ها را در خارج از پنجره تمدید پیکربندی شده خود بدون پشتیبانی اطلاعات تمدید ACME یا مداخله دستی جایگزین نمی کنند - و به این دلیل که انتقال از سلسله مراتب ECC G3 به سلسله مراتب RSA G1 ممکن است نیاز به پیکربندی سمت مشتری داشته باشد…

(الف) : eMudhra از چه مکانیزم مشخصی برای راه اندازی و تکمیل تمدید برای مشترکین ACME استفاده می کند؟

(ب) : آیا می توانید مجموعه مراحلی را که مشترکین برای تکمیل انتقال باید انجام دهند را توضیح دهید؟

(Q6): لطفا معیارهای دقیق را ارائه دهید که با صدور CA میانی تفکیک شده است:

در کامنت 11، eMudhra اظهار داشت که در مراسم 30 آوریل 2025 (KGC):

این افشای نگرانی های جدی در مورد شفافیت eMudhra و رسیدگی به حوادث در طول و بعد از اشکال 1970728 ایجاد می کند:

(س7) : پرسنل eMudhra برای اولین بار در چه تاریخ و زمان دقیقی متوجه شدند که چندین جفت کلید با برچسب های مشابه در HSM برای CA های متوسط G3B و G3C وجود دارد؟