منابع در 22 اکتبر 2026 به وقت پکن بررسی شدند. Aمخاطب: کاربران فردی، اپراتورهای وب سایت، توسعه دهندگان و مدیران سیستم.

ضعف های جدی باعث شد گروهی از کلیدهای خصوصی eMudhra/emSign میانی CA قابل بازیابی باشند. این روی مشتریانی که از سیستم گواهی عمومی برای احراز هویت وب‌سایت‌ها، APIها و نرم‌افزارها استفاده می‌کنند، تأثیر می‌گذارد. اعتماد عمومی سیستم‌های عامل اصلی را در بر می‌گیرد، اما مجموعه کلیدهای در معرض خطر و تأثیر بالقوه مشتری دامنه‌های متفاوتی دارند. 15

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

TL;DR

هشت کلید خصوصی میانی CA به خطر افتاده است. گزارش‌های فعلی ثابت نمی‌کنند که کلیدهای خصوصی ریشه یا رمزنگاری HTTPS به طور کلی خراب شده‌اند. به روز رسانی ها بخش زیادی از اکوسیستم اعتماد عمومی را در بر می گیرد. ریسک باقیمانده به کاربرد واقعی بستگی دارد.15

  1. کاربران منفرد: مرورگرها، سیستم عامل ها و اجزای امنیتی به روز رسانی می شوند. در Android، خدمات Google Play را نیز به روز کنید. از Firefox Android 158.0.2 یا جدیدتر استفاده کنید. 12
  2. سرورهای : بسته‌های 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. Aبه‌روزرسانی‌ها را فعال کنید: سرویس‌های آسیب‌دیده را مجدداً راه‌اندازی کنید و کانتینرها را دوباره بسازید و مجدداً مستقر کنید. برای Cloudflare Tunnel، cloudflared را به 2026.10.2 یا جدیدتر به روز کنید. 7
  5. گواهی‌های وب‌سایت: جایگزین زنجیره آسیب‌دیده می‌شود اگر حاوی یک CA لغو یا مسدود شده باشد یا به یک ریشه نامعتبر متکی باشد. صدور مجدد گواهی جایگزین به روز رسانی فروشگاه های اعتماد مشتری نمی شود. 158
  6. تأیید: مسیر واقعی TLS هر برنامه را آزمایش کنید. تشخیص رد گواهی از مهلت زمانی و خرابی DNS. تأیید گواهی را فعال نگه دارید. برای سرکوب خطاها از -k استفاده نکنید یا از تأیید صحت رد شوید. 7

1 حقایق و علل حادثه

حقایق تایید شده

Mozilla و Google نقص‌هایی را در هشت کلید خصوصی eMudhra میانی CA تأیید کرده‌اند. محقق مدرک کنترل کلید خصوصی را ارائه کرد. Mozilla به طور مستقل کلیدها را بازیابی کرد و مشکل را دوباره تولید کرد. شش CA میانی TLS و دو سرویس امضای کد را ارائه می‌کنند. 25

نقص در کلیدهای تولید شده نهفته است: این CAهای میانی از منحنی P-384 استفاده می کنند، اما کلیدهای خصوصی آنها اعداد صحیح زیر 256 هستند. این به دور از انتخاب ایمن کلیدها به صورت تصادفی از محدوده بزرگ مورد نظر است. بازیابی این کلیدهای ضعیف نشان نمی دهد که کلیدهای P-384 که به درستی تولید شده اند می توانند شکسته شوند. 2

“گواهی کرک شده است” در اینجا باید دقیقاً به این صورت درک شود که “کلید خصوصی مربوطه قابل بازیابی است”. گواهی و کلید عمومی موجود در آن ذاتا عمومی هستند. چیزی که واقعاً باید مخفی بماند، کلید خصوصی است که می تواند یک امضای معتبر ایجاد کند.

مسائل فرآیند تولید کلید هنوز در دست بررسی است

شرح اولیه eMudhra مشکل را به یک مراسم تولید کلید در آوریل 2025 نشان می‌دهد. توضیح شامل یک مرحله کپسوله‌سازی و کپسول‌زدایی کلید است: علاوه بر کلید قوی اصلی، مجموعه دیگری از کلیدهای ضعیف ظاهر می‌شود و کلیدهای ضعیف متعاقباً برای درخواست و صدور گواهی استفاده می‌شوند. این شرکت هنوز هم گفته است که علت اصلی آن به طور قطعی مشخص نشده است. 6

بنابراین، آنچه می توان تشخیص داد این است که این کلیدها به طور جدی ضعیف هستند و به خطر افتاده اند. این خرابی را نمی توان بیشتر به این دلیل توصیف کرد که منبع شماره تصادفی سخت افزار خاصی از HSM معیوب است و همچنین نمی توان آن را به عنوان یک پیشرفت رمزنگاری کلی از RSA، ECC یا TLS توصیف کرد.

بی اعتمادی گواهی ریشه به چه معناست؟

مرورگر یا سیستم عامل می تواند مستقیماً گواهی یا کلید عمومی واسطه آسیب دیده CA را مسدود کند، یا می تواند اعتماد ریشه منتهی به آنها را حذف کند. اقدام اخیر همچنین برخی از گواهی‌های مشروع تحت همین ریشه را رد می‌کند.

Google حذف emSign ECC Root CA - G3 را برای محافظت از کاربران فروشگاه ریشه Chrome که به‌روزرسانی‌های CRLSet را دریافت نمی‌کنند، برنامه‌ریزی کرده است. انتظار می رود حذف root store در دوره مربوطه از 27 تا 28 اکتبر به وقت پکن انجام شود. زمان اصلی Google صبح روز 27 اکتبر، به وقت تابستانی اقیانوس آرام ایالات متحده است. این طرح جدا از انسداد کلید عمومی اضطراری است که قبلاً اجرا شده است. 1

عدم اعتماد به ریشه یک معیار پاسخگویی است. این خود ثابت نمی کند که کلید خصوصی ریشه به خطر افتاده است.

2 چرا تأثیر بالقوه اکوسیستم اعتماد عمومی را در بر می گیرد؟

کلیدهای به خطر افتاده و مسیرهای اعتماد تحت تأثیر قرار گرفته است

موضوع قضاوتدامنه این حادثه
کلید مشکل ساز شناسایی شد8 کلید خصوصی CA میانی برای eMudhra
پلتفرم هایی که ممکن است نیاز به اقدام داشته باشندفروشگاه ریشه عمومی، مرورگر، سیستم عامل، زمان اجرا زبان، بسته نرم افزاری و اکوسیستم کانتینر
هویت احتمالاً جعل هویت 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 خدمات آدرس و اعتماد مشتری را رفع می کند. آنها به خطر افتادن کلیدهای خصوصی CA خود Cloudflare را نشان نمی دهند. 7

زنجیره گواهی TLS و امضای متقابل

رابطه زیر این بار فقط مسیرهای مربوط به TLS را توصیف می کند. این شامل مسیرهای امضای کد نمی شود و به این معنا نیست که این مسیرها هنوز در همه پلتفرم ها قابل اعتماد هستند. 17

  • emSign ECC Root CA - G3 ← emSign Root TLS CA - G3 ← تحت تأثیر TLS کلید عمومی میانی CA → گواهی جعلی برای دامنه هدف
  • AAA Certificate Services → TLS میانی CA کلید عمومی → گواهی جعلی برای دامنه هدف

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 محاصره مربوطه را مستقر کرده استهر نسخه قدیمی و برنامه شخص ثالث تضمینی برای دریافت پوشش یکسان نیست
AndroidGoogle بلوک های معادل را از طریق سرویس Google Play توزیع می کندROM بدون سرویس Google Play باید طبق اعلام سازنده تأیید شود. برای تأیید بیشتر از تأیید کننده داخلی استفاده کنید
Ubuntuاصلاحات بسته گواهینامه سیستم، از جمله چندین شعبه نسخه فعلی و قدیمی ارائه شده استنسخه قدیمی ESM از شرایط، بسته گواهی داخلی کانتینر و کتابخانه داخلی برنامه پشتیبانی می کند.
Debian و DevuanDebian ثبت شد 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 2424.22.1 یا نسخه پایدار همان شاخه را به روز کنیدحاوی به‌روزرسانی‌های مخزن ریشه و رد زنجیره‌های کلید عمومی مسدود شده است. مسیر Node را که واقعاً توسط سرویس استفاده می شود بررسی کنید و راه اندازی مجدد کنید
Python certifi2026.10.19 یا نسخه جدیدترهر محیط در حال اجرا واقعی را بررسی کنید. شما نمی توانید تنها یک بسته را تحت جهانی Python به روز کنید
pip26.2.2 یا نسخه جدیدترpip را به طور جداگانه در محیط مجازی قدیمی به روز کنید و پس از ایجاد محیط جدید نسخه را بررسی کنید.
uv0.13.4 یا نسخه جدیدتریک نسخه از ابزار را همانطور که واقعاً نصب شده است به روز کنید
Go1.27.3 یا 1.26.10، نسخه به روز شده شعبه مربوطه نیز موجود استپس از به‌روزرسانی زنجیره ابزار، برنامه‌های مربوطه را بازسازی و استقرار دهید یا باینری تعمیر فروشنده را دریافت کنید.
Oracle JDKوصله های Critical برای خطوط نسخه پشتیبانی شده مربوطهناشران مختلف JDK اعلامیه های خود را دنبال می کنند. هیچ شماره نسخه واحدی وجود ندارد که برای همه نسخه‌های Java اعمال شود
Cloudflare Tunnelcloudflared 2026.10.2 یا نسخه جدیدتربه روز رسانی خدمات در حال اجرا؛ استقرار کانتینر نیاز به جایگزینی تصویر و استقرار مجدد دارد
Cloudflare One/WARPنسخه مشتری ثابت مربوط به پلتفرم یا نسخه پایدار به روز شدهاقدامات سمت مشتری و سمت سرور به طور جداگانه تأیید می شوند. برای نسخه‌های پلتفرم خاص، به پیوست 7 مراجعه کنید

دستورالعمل اصلی برای Node , Python , Go , Oracle و Cloudflare به ترتیب در دسترس هستند 13 , 12 , 14 , 15 , 7 .

مشکل پایگاه داده گواهی مستقل Python

مقامات Python اشاره کردند که pip قدیمی از ترکیبی از اعتماد سیستم و certifi داخلی استفاده می کند. صرفاً تغییر ذخیره‌گاه گواهی سیستم یا افزودن یک فایل CA به pip نمی‌تواند به‌طور قابل‌اطمینانی اعتماد قدیمی داخلی آن را حذف کند. بنابراین، PIP_CERT، REQUESTS_CA_BUNDLE یا --cert را نمی توان به عنوان جایگزین تعمیر جهانی برای pip قدیمی تر استفاده کرد. 12

پس از به‌روزرسانی، محیط‌های مجازی موجود را بررسی کنید. همچنین نسخه pip را که واقعاً در محیط های تازه ایجاد شده نصب شده است بررسی کنید تا اجزای بوت استرپ قدیمی تر ابزارهای آسیب پذیر را دوباره معرفی نکنند. برای ارتقای اولیه، منابع دانلود و مراحل تأیید SHA-256 در توصیه Python را قبل از به‌روزرسانی بسته‌های دیگر دنبال کنید. 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 - G3BTLSeMudhra BV
EM OV TLS CA - G3BTLSeMudhra BV
EM DV TLS CA - G3BTLSeMudhra BV
EM EV TLS CA - G3CTLSeMudhra Inc
EM OV TLS CA - G3CTLSeMudhra Inc
EM DV TLS CA - G3CTLSeMudhra 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