روز ۱۹ اکتبر ۲۰۲۶ گواهی Microsoft Windows Production PCA 2011 به پایان عمر ۱۵ ساله‌اش رسید. سه روز بعد مایکروسافت KB5132953 را منتشر کرد و نکتهٔ اولش خیال‌آسوده‌کننده است: به گفتهٔ این مقاله، انقضای گواهی باعث خاموش ماندن کامپیوترها یا بالا نیامدن ویندوز نمی‌شود. نکتهٔ دوم را باید دو بار خواند. آخرین نسخههای Windows Boot Manager که با گواهی 2011 امضا شده‌اند اکنون «به شکل باینری ثابت منجمد» شده‌اند و دیگر وصلهٔ امنیتی نمی‌گیرند.
پس روز ۲۰ اکتبر چیزی از کار نیفتاد. تغییر بی‌صداتر است. هر سروری که فرم‌ویرش هنوز فقط زنجیرهٔ 2011 را قبول دارد، دیگر اصلاحیههای سطح بوت را دریافت نمی‌کند و وصلهٔ بعدی مایکروسافت برای آسیب‌پذیری Boot Manager به آن نمی‌رسد. برای یک شرکت کوچک با چند سرور فیزیکی و دو سه ده ماشین مجازی، اگر همین حالا سراغش بروید کار یک بعدازظهر است. اگر صبر کنید تا یک اکسپلویت بوت خبرساز شود، کار یک آخر هفته میشود.
چرخهٔ وصله‌های اکتبر برای هر کسی که سرورهای مایکروسافت را روی سخت‌افزار خودش اجرا می‌کند پرکار بوده است (بخش مربوط به Exchange را اینجا نوشتیم). این یکی سروصدای کمتری دارد، ولی به هر ماشین ویندوزی که Secure Boot در آن روشن است مربوط میشود.
سه تاریخ انقضا در یک نگاه
صفحهٔ انقضای گواهیهای Secure Boot در سایت مایکروسافت گواهیهای 2011 و جایگزین‌هایشان را این‌طور فهرست می‌کند:
| گواهی منقضی‌شده | تاریخ انقضا | جایگزین | چه چیزی را امضا می‌کند |
|---|---|---|---|
| Microsoft Corporation KEK CA 2011 | ۲۴ ژوئن ۲۰۲۶ | Microsoft Corporation KEK 2K CA 2023 | بهروزرسانیهای DB و DBX |
| Microsoft UEFI CA 2011 | ۲۷ ژوئن ۲۰۲۶ | Microsoft UEFI CA 2023 | بوت‌لودرها و برنامه‌های EFI شخص ثالث |
| Microsoft UEFI CA 2011 | ۲۷ ژوئن ۲۰۲۶ | Microsoft Option ROM UEFI CA 2023 | Option ROMهای شخص ثالث |
| Microsoft Windows Production PCA 2011 | ۱۹ اکتبر ۲۰۲۶ | Windows UEFI CA 2023 | بوتلودر خود ویندوز |
تاریخ‌های ژوئن بی‌سروصدا گذشتند. اکتبر مهم‌تر است، چون Production PCA خود بوتلودر ویندوز را امضا می‌کند و مایکروسافت از آن برای فایل‌های معمولی ویندوز هم استفاده می‌کرد. طبق KB5132953، از ۱۹ اکتبر مایکروسافت دیگر هیچ فایل باینری یا کاتالوگ امنیتی را با گواهی PCA 2011 امضا نمی‌کند.
بعد از ۱۹ اکتبر دقیقاً چه عوض شد
اگر KB5132953 را با نگاه یک اتاق سرور بخوانید، چهار تغییر به چشم می‌آید:
- همهٔ وصله‌های امنیتی آیندهٔ بوتلودر ویندوز فقط با زنجیرهٔ Windows UEFI CA 2023 امضا میشوند. سروری که پایگاه امضای فرم‌ویرش (DB) این گواهی را ندارد نمی‌تواند از آن وصله‌ها استفاده کند.
- رسانه‌های نصب آینده برای نسخههای فعلی ویندوز به‌طور پیش‌فرض با Boot Manager امضاشده با 2023 بوت میشوند. روی سخت‌افزاری که فرم‌ویرش گواهی 2023 را ندارد، این رسانه با خطای Secure Boot violation متوقف میشود، مگر اینکه اسکریپت بازگردانی را که مایکروسافت وعده داده اجرا کنید.
- نسخههای اصلی آیندهٔ ویندوز، چه کلاینت و چه سرور، حتی برای بوت شدن رسانهٔ نصبشان به Windows UEFI CA 2023 در DB نیاز دارند.
- سیاست‌های App Control for Business (WDAC)، بررسیهای امضا در CI/CD و ابزارهای امنیتی که اعتمادشان را به PCA 2011 سنجاق کرده‌اند ممکن است فایل‌های به‌روزشدهٔ ویندوز را مسدود کنند. مایکروسافت نصب نشدن بهروزرسانیهای تجمعی، بالا نیامدن سرویس‌ها و رویداد Code Integrity 3077 را از نشانه‌ها می‌داند.
کدام ماشین‌ها نیاز به رسیدگی دارند
KB5132953 شامل Windows 11، Windows 10 ESU، Windows Server 2019، 2022 و 2025 و Azure است. به گفتهٔ مایکروسافت کاربران خانگی که Windows Update دارند کاری لازم نیست انجام دهند. مخاطب این مقاله تیم‌هایی هستند که به‌روزرسانی‌ها را خودشان مدیریت میکنند، و در سازمان‌های کوچک و متوسط این موارد را بیشتر از همه می‌بینیم:
- سرورهای فیزیکی با Secure Boot روشن، به‌خصوص مدل‌های قدیمی‌تری که سازنده دیگر برایشان بهروزرسانی BIOS نمی‌دهد.
- ماشینهای مجازی نسل ۲ در Hyper-V. مایکروسافت میگوید این ماشین‌ها گواهیهای جدید را از طریق بهروزرسانیهای تجمعی معمولی میگیرند، پس کار شما فقط اطمینان از انجام شدن آن است.
- ماشینهای مجازی روی VMware. توصیهٔ مایکروسافت این است که هاست‌های ESXi و نسخهٔ سخت‌افزار ماشین مجازی را به نسخه‌هایی برسانید که قالب UEFI مهمان در آنها گواهیهای 2023 را دارد.
- هر کسی که سیاست App Control اجرا می‌کند یا نرم‌افزار امنیتی‌ای دارد که امضای Authenticode را مستقیم بررسی می‌کند.
- تیم‌هایی که هنوز سرورها را با فلش‌های قدیمی یا ایمیج‌های PXE نصب میکنند.
Windows Server 2016 حساب جداگانه‌ای دارد. این نسخه در راهنمای قدیمی‌تر Boot Manager یعنی KB5025885 آمده ولی در KB5132953 نیست، و صفحهٔ چرخهٔ عمر Windows Server 2016 پایان پشتیبانی تمدیدشده را ژانویهٔ ۲۰۲۷ اعلام می‌کند. اگر هنوز هاست 2016 دارید، مهاجرت سیستم‌عامل و کار گواهی‌ها را با هم برنامه‌ریزی کنید. همین منطق پشت برنامهٔ خروج ما از Exchange 2016/2019 هم بود: یک پروژهٔ نگهداری بهتر از دو پروژهٔ عجولانه است.
بررسی وضعیت با PowerShell
این دستورها را در یک پنجرهٔ PowerShell با دسترسی Administrator اجرا کنید. اول ببینید Secure Boot اصلاً روشن است یا نه. Confirm-SecureBootUEFI مقدار True یا False برمی‌گرداند و روی سخت‌افزاری که UEFI Secure Boot را پشتیبانی نمی‌کند خطا میدهد.
Confirm-SecureBootUEFIسپس کلیدهای سرویس‌دهی را بخوانید که در صفحهٔ کلیدهای رجیستری Secure Boot مستند شده‌اند. مقدار UEFICA2023Status از NotStarted به InProgress و بعد به Updated می‌رسد. اگر UEFICA2023Error صفر نباشد یعنی یکی از مراحل شکست خورده، و UEFICA2023ErrorEvent نشان میدهد شمارهٔ کدام رویداد را باید جست‌وجو کنید.
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing' |
Select-Object UEFICA2023Status, UEFICA2023Error, UEFICA2023ErrorEventبرای اینکه ببینید DB فرمویر گواهی جدید ویندوز را دارد یا نه، KB5025885 این دستور یک‌خطی را میدهد. خروجی باید True باشد:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'بعد لاگ System را بررسی کنید. KB5016061 شماره‌های رویداد را توضیح میدهد: 1801 یعنی گواهی‌ها بهروز شده‌اند ولی هنوز روی فرمویر دستگاه اعمال نشده‌اند، 1808 یعنی گواهی‌ها و کلیدهای Secure Boot این دستگاه بهروز شده‌اند، 1795 خطایی است که فرمویر برگردانده، و 1803 یعنی برای این دستگاه هیچ KEK امضاشده با PK پیدا نشده، که باید از سازندهٔ سخت‌افزار پرسید.
Get-WinEvent -FilterHashtable @{LogName='System'; Id=1795,1796,1801,1803,1808} -MaxEvents 20 |
Format-Table TimeCreated, Id, Message -Wrapاگر لازم شد با سازندهٔ سرور تیکت باز کنید، راهنمای مایکروسافت برای متخصصان IT مشخصات فرمویر را با این دستورها جمع می‌کند:
(Get-CIMInstance Win32_BIOS).Description + ", " + (Get-CIMInstance Win32_BIOS).ReleaseDate.ToString("MM/dd/yyyy")
(Get-CIMInstance Win32_ComputerSystem).Manufacturer
(Get-CIMInstance Win32_ComputerSystem).Model
(Get-CIMInstance Win32_BaseBoard).Productاعمال بهروزرسانی، قدم به قدم
اول از هر مدل سخت‌افزاری یک سرور غیرحیاتی انتخاب کنید. ترتیب زیر از روال آزمایشی مستند مایکروسافت پیروی می‌کند.
- کلید بازیابی BitLocker را ذخیره کنید. KB5132953 هشدار میدهد که بعد از بهروزرسانی زنجیرهٔ بوت ممکن است درخواست بازیابی غیرمنتظره ظاهر شود. KB5025885 روش خواندن رمز بازیابی ۴۸ رقمی را نشان میدهد:
manage-bde -protectors -get %systemdrive% - آخرین فرمویر BIOS/UEFI را از سازندهٔ سرور نصب کنید. راهنمای مایکروسافت از مدیران میخواهد دربارهٔ فرمویر بهروز از OEM سؤال کنند، و رویدادهای 1795 و 1803 هم معمولاً به همین سمت اشاره دارند.
- استقرار را فعال کنید و به‌جای منتظر ماندن برای چرخهٔ ۱۲ ساعته، تسک زمانبندیشده را همین حالا اجرا کنید. هر دو دستور از صفحهٔ کلیدهای رجیستری آمده‌اند:
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update" - مقدار AvailableUpdates را زیر نظر بگیرید. وقتی به 0x4100 رسید، سرور را ریاستارت کنید و تسک را دوباره اجرا کنید. بعد از جایگزینی Boot Manager مقدار باید روی 0x4000 بماند.
- مطمئن شوید UEFICA2023Status مقدار Updated دارد و رویداد 1808 در لاگ System ثبت شده است.
- برای بقیهٔ سرورها اجرا کنید. در Group Policy تنظیم مربوط «Enable Secure Boot Certificate Deployment» است، در مسیر Computer Configuration، Administrative Templates، Windows Components، Secure Boot (روش GPO مایکروسافت را ببینید). Intune هم سیاست معادل خودش را دارد.
شروع استقرار سرور را مجبور به ریاستارت نمی‌کند. طبق صفحهٔ کلیدهای رجیستری، تعویض Boot Manager منتظر ریاستارت معمولی بعدی میماند، که برای بیشتر سرورها یعنی پنجرهٔ وصلهٔ بعدی.
App Control و رسانه‌های نصب قدیمی
اگر از App Control for Business استفاده می‌کنید، KB5132953 میخواهد در XML سیاست‌ها دنبال قوانین signer بگردید که به CAهای مایکروسافت ارجاع می‌دهند، از جمله قوانینی که از سیاست‌های پایهٔ نمونه به ارث رسیده‌اند، و تغییرات را اول در حالت audit منتشر کنید و بعد اجباری کنید. یک مقالهٔ قدیمی‌تر مایکروسافت دربارهٔ مدیریت CAهای جدید میگوید اگر سیاستی به CAهای فعلی اعتماد داشته باشد، App Control اعتماد به CAهای جایگزین را خودش استنتاج می‌کند. ما باز هم اول حالت audit را اجرا می‌کنیم. غافلگیری‌ها معمولاً از سیاست‌های سفارشی و ایجنت‌های شخص ثالث می‌آیند.
برای رسانهٔ نصب، مایکروسافت اسکریپت Make2023BootableMedia.ps1 را منتشر کرده تا ISOها و فلش‌های موجود را به Boot Manager نسخهٔ 2023 تبدیل کند (KB5053484). یک فلش قدیمی با برچسب واضح نگه دارید برای سخت‌افزاری که هنوز منتظر بهروزرسانی فرمویر است.
بازگشت: چه چیزی برگشت‌پذیر است و چه چیزی نه
قبل از شروع این را به تیم بگویید: مایکروسافت روش متوقف کردن استقرار را مستند کرده، نه روش بیرون کشیدن گواهی‌ها از فرمویر.
- قبل از اجرای تسک: طبق صفحهٔ کلیدهای رجیستری، مقدار 0 برای AvailableUpdates یعنی هیچ بهروزرسانی کلید Secure Boot انجام نمی‌شود. اگر این مقدار از Group Policy آمده باشد، حذف GPO آن را پاک نمی‌کند، پس خودتان آن را برگردانید.
- استقرار خودکار: مقدار 1 برای HighConfidenceOptOut دستگاه را از گروه‌های «اطمینان بالا» که مایکروسافت از طریق بهروزرسانی تجمعی ماهانه اعمال می‌کند خارج می‌کند. آن را روی سخت‌افزاری که می‌دانید شکننده است به کار ببرید و بعد از بهروزرسانی فرمویر دوباره سراغش بروید.
- بازنشانی فرمویر به تنظیمات کارخانه: KB5025885 هشدار میدهد دستگاهی که بعد از اعمال این تغییرات تنظیمات Secure Boot آن به پیش‌فرض برگردد بوت نخواهد شد، و روش ساخت یک فلش بازیابی با
securebootrecovery.efiرا توضیح میدهد که گواهی 2023 را دوباره به DB برمی‌گرداند. به هر کسی که به BIOS دسترسی دارد بگویید روی سرور به‌روزشده بدون هماهنگی کلیدهای کارخانه را بازنشانی نکند.
انقضای گواهی را راحت میشود نادیده گرفت، تا روزی که دیگر نمی‌شود. ما برای همهٔ سرورهایی که اداره می‌کنیم یک تقویم واحد از تاریخ‌های گواهی و پشتیبانی نگه می‌داریم، از TLS عمومی (ببینید چطور یک گواهی wildcard را روی چند سرور تمدید می‌کنیم) تا کلیدهای فرمویر مثل همین‌ها.
پرسش‌های متداول
آیا سرورهای ما به خاطر انقضای گواهی دیگر بوت نمیشوند؟
نه. KB5132953 میگوید دستگاهها مثل قبل روشن میشوند و ویندوز را اجرا میکنند. آنها با Boot Manager منجمدِ امضاشده با 2011 بوت میشوند که دیگر اصلاحیهٔ امنیتی جدید نمیگیرد.
آیا ماشینهای مجازی Hyper-V کار دستی لازم دارند؟
مایکروسافت میگوید ماشینهای مجازی نسل ۲ در Hyper-V گواهیهای بهروز را از طریق بهروزرسانیهای تجمعی استاندارد میگیرند. همان بررسیهای رجیستری و DB را داخل چند ماشین مهمان اجرا کنید تا مطمئن شوید، چون نتیجه به وصلهشدن خود مهمان بستگی دارد.
اگر سروری هیچوقت گواهی 2023 را نگیرد چه میشود؟
طبق KB5132953 همچنان بوت میشود ولی اصلاحیههای امنیتی آیندهٔ بوتلودر را از دست میدهد، و نسخههای اصلی آیندهٔ ویندوز روی آن نصب نمیشوند، چون رسانهٔ نصبشان به Windows UEFI CA 2023 در DB نیاز دارد.
آیا این بهروزرسانی میتواند BitLocker را به حالت بازیابی ببرد؟
ممکن است. مایکروسافت میگوید بسته به پیکربندی محافظها و فرمویر، درخواست بازیابی غیرمنتظره ممکن است ظاهر شود، و از مدیران میخواهد قبل از هر بهروزرسانی زنجیرهٔ بوت یا فرمویر، از جمله بهروزرسانیهای کیفی ماهانه، از کلیدهای بازیابی نسخهٔ پشتیبان بگیرند.
استقرار روی یک سرور چقدر طول میکشد؟
تسک زمانبندیشده هر ۱۲ ساعت اجرا میشود و تعویض Boot Manager منتظر ریاستارت میماند. اگر طبق مراحل بالا تسک را دستی اجرا کنید و یک بار ریاستارت کنید، کار یک سرور در یک پنجرهٔ نگهداری تمامشدنی است.
اگر ترجیح می‌دهید بررسی فرمویر، پنجره‌های وصله و مانیتورینگ را به کس دیگری بسپارید، فنپینو این کار را برای تیم‌های کوچک و متوسط انجام میدهد. خدمات زیرساخت ابری و DevOps ما را ببینید.
منابع: KB5132953: انقضای Windows Production CA 2011 و بهروزرسانیهای بوتلودر (پشتیبانی مایکروسافت، ۲۲ اکتبر ۲۰۲۶)، انقضای گواهیهای Secure Boot ویندوز و بهروزرسانی CAها، بهروزرسانی کلیدهای رجیستری برای Secure Boot، KB5016061: رویدادهای بهروزرسانی متغیرهای DB و DBX در Secure Boot و KB5025885.
عمر گواهی‌ها کوتاه میشود: عمر گواهی TLS در ۲۰۲۷ و آنچه باید ممیزی کرد.