Октябрь для администраторов Windows Server вышел плотным. Сначала, 13 октября, пришёл обычный набор исправлений, после которого у части почтовых серверов Exchange стали отваливаться веб-доступ и отправка писем. Затем, 26 октября, Microsoft вне графика выпустила KB5134140 для Windows Server 2022 с обновлённым набором доверенных корневых сертификатов. Причина спешки лежит в другой плоскости: у индийского центра сертификации eMudhra оказались скомпрометированы ключи промежуточных сертификатов. Две истории развивались параллельно, а связывает их неочевидная деталь. Новый пакет накопительный, а значит, привёз на серверы не только исправление доверия, но и всё, что входило в октябрьское обновление, включая известную проблему. Ниже разобрано, что именно делает KB5134140, как устроен механизм списков доверия в изолированных сетях и как диагностировать и поднять лимит Endpoint Mapper, если Exchange начал терять соединения.
Что входит в KB5134140 и каким серверам Windows Server 2022 он нужен в первую очередь
KB5134140 относится к внеплановым накопительным обновлениям без исправлений безопасности. Microsoft выпустила его 26 октября 2026 года, и оно поднимает сборку Windows Server 2022 до 20348.5773. Накопительность означает, что пакет включает всё из обновления KB5126655, вышедшего 13 октября (сборка 20348.5761), а при установке на уже обновлённый сервер система докачивает только недостающее. В комплекте идёт и обновление служебного стека KB5126654 (сборка 20348.5739).
Главное содержимое пакета одно: свежий набор доверенных корневых сертификатов, встроенный прямо в накопительное обновление. Адресат у него вполне определённый. Это устройства, которые не могут обратиться к службе обновления сертификатов Microsoft, и машины, где автоматические обновления списка доверия (CTL, certificate trust list) отключены. Всем остальным ручная работа не нужна: они получают списки доверия сами, и для них KB5134140 выглядит как очередное накопительное обновление. Для Windows Server 2025 вышел собственный пакет KB5134137 (сборка 26100.33674), для клиентских систем тоже свои номера.
К группе, которой пакет нужен всерьёз, обычно относятся изолированные сегменты без выхода в интернет, закрытые производственные контуры, тестовые стенды за строгими прокси и серверы, где групповая политика намеренно выключила автоматическое обновление корней. У такого сервера собственный список доверия живёт ровно в том состоянии, в каком его застало последнее обновление, и новости о скомпрометированных ключах до него сами не дойдут. Поэтому внеплановый пакет здесь работает как курьер, доставляющий в закрытый периметр то, что в открытом приходит по сети незаметно.
Компрометация ключей eMudhra и что именно Microsoft убрала из доверия Windows
Исходная проблема выглядит почти пугающе просто. У центра сертификации eMudhra оказались восемь промежуточных сертификатов, закрытые ключи которых были настолько слабыми, что их удавалось восстановить практически мгновенно. Шесть из этих сертификатов предназначались для TLS, два для подписи кода. Последствие понятно без долгих пояснений: тот, кто вычислил такой ключ, может выпустить сертификат для чужого сайта, и обычная проверка цепочки признает его настоящим, хотя eMudhra ничего подобного не выдавала.
Ответ Microsoft шёл в два этапа. 20 октября компания добавила восемь ключей в список запрещённых сертификатов Windows, блокируя их по данным открытого ключа. Эта мера точечная: она бьёт ровно по тем промежуточным центрам, о которых известно, что ключи скомпрометированы. Второй этап пришёл 26 октября вместе с внеплановыми обновлениями: из списка доверия убрали семь сертификатов, шесть корневых eMudhra поколения G3 и один сертификат с перекрёстной подписью под корнем AAA Certificate Services. Здесь решение уже шире. Удаление корня из списка доверия и отзыв конкретных промежуточных сертификатов это разные вещи, и Microsoft подчёркивает это различие.
Остальные участники рынка отреагировали согласованно: заблокировать затронутые сертификаты решили и производители браузеров, и другие платформы. Следы той же истории видны в инструментах, которые на первый взгляд никак не связаны с Windows. Например, свежие версии среды Go, на которой написан Docker Engine, отвергают цепочки с теми же восемью отозванными промежуточными сертификатами, и загрузка образов из реестров с такой цепочкой перестаёт проходить проверку TLS. Так что вопрос шире одной операционной системы: любой компонент, который сам проверяет цепочки, получает собственный запрет, и администратору полезно знать, где именно живёт его список доверия.
Механизм обновления списков доверия CTL и почему изолированные сети остаются без защиты
Windows не носит в себе полный перечень корневых сертификатов. В хранилище лежит базовый набор, а всё остальное система подтягивает по требованию: когда ей попадается цепочка, ведущая к корню, которого локально нет, она обращается к службе Microsoft, сверяется со списком доверия и при успехе добавляет корень в хранилище. Параллельно живёт отдельный список запрещённых сертификатов, откуда и приходит блокировка скомпрометированных ключей. Оба списка распространяются в виде подписанных каталогов (файлы authrootstl.cab и disallowedcertstl.cab), и обновляются они без участия администратора, пока у сервера есть доступ к узлу, который их раздаёт.
В изолированной сети этот ход ломается. Сервер не может скачать свежий список, поэтому ничего не знает о новых запретах и продолжает доверять тому, что доверял вчера. Для таких сред у Microsoft предусмотрены два пути. Первый путь: пропустить через межсетевой экран обращения к узлу со списками доверия, и сервер начнёт обновляться сам. Второй: взять списки на подключённой машине и разнести их по закрытому периметру вручную. Для второго пути есть штатная утилита.
certutil -syncWithWU \\fileserver\ctl
Команда запускается на машине с выходом в интернет и складывает в указанную папку файлы каталогов и самих сертификатов, в том числе authrootstl.cab, authroot.sst, disallowedcertstl.cab и disallowedcert.sst. Дальше эту папку выкладывают на общий ресурс внутри закрытого сегмента, а серверам через групповую политику или реестр указывают, где искать файлы (за это отвечает значение RootDirUrl в ветке AuthRoot\AutoUpdate), и выключают обращение к внешнему узлу. Точный формат пути стоит сверить с руководством Microsoft по настройке доверенных корней, потому что от слэшей и протокола зависит, подхватит ли система папку.
Узнать, в каком режиме живёт конкретный сервер, можно двумя проверками. Первая показывает, выключено ли автоматическое обновление корней политикой, вторая показывает, остались ли в хранилище корни eMudhra.
reg query "HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\AuthRoot" /v DisableRootAutoUpdate
Get-ChildItem Cert:\LocalMachine\Root |
Where-Object { $_.Subject -match 'eMudhra|emSign' } |
Select-Object Subject, Thumbprint, NotAfter
Значение DisableRootAutoUpdate, равное 1, означает, что автоматическое обновление выключено и серверу нужна ручная доставка. Пустой результат второй команды на обновлённом сервере ожидаем. Если же корни найдены на машине, которая должна была получить новый набор, это повод проверить, действительно ли пакет установился и не вернула ли их какая-нибудь локальная политика или собственная ручная загрузка.
Побочная проблема Exchange с лимитом Endpoint Mapper, которую пакет унаследовал от октябрьского обновления
Теперь к тому, что в брифе звучит как побочный эффект KB5134140. Формально это не совсем так. Причина сидит в октябрьском обновлении от 13 октября: для Windows Server 2022 это KB5126655, для 2025 версии KB5126646, для 2019 KB5126651, для 2016 KB5126868. KB5134140 накопительный и включает октябрьский набор, поэтому унаследовал и проблему. Установка пакета не создаёт её заново, но и не снимает, а Microsoft прямо предупреждает, что внеплановые пакеты несут все известные проблемы октябрьских обновлений.
Суть в следующем. Октябрьские обновления ввели лимит на объём памяти, который Endpoint Mapper может занять при обработке вызовов Endpoint Lookup. По умолчанию он соответствует 512 одновременным вызовам. Endpoint Mapper это часть RPC, механизм, который подсказывает клиенту, на каком порту и в каком интерфейсе работает нужная служба. Exchange пользуется им постоянно и при большой нагрузке выходит за рамки этих 512, после чего запросы начинают отбрасываться. Вероятной причиной появления лимита называют исправление уязвимости CVE-2026-96300, отказа в обслуживании из-за неконтролируемого расхода ресурсов в службе RPC Endpoint Mapper, и это выглядит логично: защиту от исчерпания памяти поставили жёсткой, а запас под высоконагруженные продукты не рассчитали.
Проявляется всё так. Пользователи не могут войти в веб-доступ Outlook, письма из Outlook зависают в папке "Исходящие", а при репликации почтовых ящиков между серверами группы доступности баз данных Exchange испытывает трудности с доступом к ящикам. В журнале приложения появляются записи с кодом события 1006 и текстом MapiExceptionMdbOffline: Unable to make connection to the server (hr=0x80004005, ec=1142). Администраторы также сообщают об ошибке 0x6d9 "There are no more endpoints available from the endpoint mapper", которая встречается, например, при обращении к кластерному API. Перезагрузка сервера помогает, но временно: по наблюдениям администраторов, симптомы возвращаются примерно через 22-30 часов после установки обновления.
Есть три нюанса, которые стоит держать в голове. Первый: проблема затрагивает любую версию Exchange на затронутой версии Windows, то есть Exchange 2016, 2019 и Subscription Edition, а облачный Exchange Online она не касается. Второй: сервера страдают неравномерно, потому что скорость и тяжесть проявления зависят от нагрузки, и на некоторых серверах проблема может не проявиться вовсе. Третий: Microsoft подчёркивает, что октябрьские обновления самого Exchange тут ни при чём, и откат этих обновлений ничего не даст. На момент последних подтверждённых данных, примерно 20-23 октября, статус проблемы значился как "смягчена", расследование продолжалось, а актуальный статус перед работой лучше сверить заново.
Диагностика Endpoint Mapper на сервере Exchange по журналам, счётчикам и сетевой трассировке
Диагностику удобно строить от простого к сложному. Первым делом проверяется, какая сборка стоит на сервере и затронут ли он вообще. Сборка 20348.5761 и выше означает наличие октябрьского набора, а 20348.5773 означает KB5134140.
$v = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
"$($v.CurrentBuild).$($v.UBR)"
reg query "HKLM\SOFTWARE\Microsoft\Rpc" /v EpmapSavedContextCap
Вторая команда показывает, задан ли уже обходной параметр. Если значения нет, действует лимит по умолчанию. Дальше смотрится журнал приложения: нужны записи с кодом 1006, в тексте которых упоминается MapiExceptionMdbOffline.
Get-WinEvent -FilterHashtable @{
LogName = 'Application'
Id = 1006
StartTime = (Get-Date).AddDays(-3)
} | Where-Object { $_.Message -match 'MapiExceptionMdbOffline' } |
Select-Object TimeCreated, ProviderName -First 20
Полезно сопоставить время записей с рабочей нагрузкой и со временем последней перезагрузки. Если сбои собираются в пики и повторяются примерно через сутки после старта сервера, это совпадает с описанной картиной. Следующий шаг касается самого RPC. Служба RpcSs обычно работает в отдельном процессе, и за ним можно наблюдать, а заодно оценить число подключений к порту 135, на котором слушает Endpoint Mapper.
Get-NetTCPConnection -LocalPort 135 |
Group-Object State | Sort-Object Count -Descending
$rpcPid = (Get-CimInstance Win32_Service -Filter "Name='RpcSs'").ProcessId
Get-Process -Id $rpcPid | Select-Object Id, WorkingSet64, HandleCount
while ($true) {
$p = Get-Process -Id $rpcPid
'{0:u};{1};{2}' -f (Get-Date), [int]($p.WorkingSet64/1MB), $p.HandleCount |
Add-Content C:\Temp\rpcss.log
Start-Sleep -Seconds 300
}
Последний блок пишет в файл раз в пять минут размер рабочего набора и число дескрипторов процесса. Это не официальная методика Microsoft, а практический приём: журнал поможет увидеть динамику и сопоставить её со сбоями, но сам по себе причину не докажет. Если нужна точность, остаётся сетевая трассировка. Её снимают на сервере в момент проблемы, а потом разбирают в анализаторе пакетов.
netsh trace start capture=yes tracefile=C:\Temp\epm.etl maxsize=512 filemode=circular
netsh trace stop
Файл формата etl обычно конвертируют в pcapng сторонней утилитой etl2pcapng, после чего в анализаторе пакетов остаётся отфильтровать трафик по протоколу epm. В обычное время в трассировке видны запросы на поиск конечных точек и успешные ответы. В момент проблемы запросы остаются без ответа или завершаются ошибкой, а клиентские сообщения совпадают с кодом 1753, то есть 0x6d9. Именно такая картина отличает исчерпание лимита от сетевой неполадки: до порта 135 пакеты доходят, а службе нечем ответить.
Подъём лимита одновременных вызовов Endpoint Lookup и проверка того, что настройка сработала
Обходное решение у Microsoft одно, и оно простое. На проблемном сервере Exchange создаётся значение EpmapSavedContextCap в ветке HKLM\SOFTWARE\Microsoft\Rpc типа REG_DWORD со значением 65536, после чего сервер перезагружается. Команду запускают из командной строки с повышенными правами.
reg add "HKLM\SOFTWARE\Microsoft\Rpc" /v EpmapSavedContextCap /t REG_DWORD /d 65536 /f
То же самое в PowerShell:
New-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Rpc' `
-Name EpmapSavedContextCap -PropertyType DWord -Value 65536 -Force
Restart-Computer
Параметр увеличивает допустимое число одновременных вызовов и вместе с ним объём памяти, который Endpoint Mapper имеет право занять. Microsoft сообщает, что в обработанных обращениях клиентов такой способ проблему снимал, но называет его временной мерой. Откатывать обновления компания не советует. Есть три практических правила, которые уберегают от лишних неприятностей. На серверах группы доступности баз данных перезагрузки делаются по одному, по обычной процедуре перевода сервера в обслуживание, иначе вместо одной проблемы получится две. Перед изменением значение стоит записать, даже если параметра раньше не было, чтобы в журнале изменений осталась точка отсчёта. А наблюдение после перезагрузки должно идти не минуты, а сутки-двое, потому что описанная цикличность в 22-30 часов проявляется именно на такой дистанции.
Если симптомы возвращаются, Microsoft предлагает повышать лимит дальше и следить за средой. Официальной оценки, сколько памяти это добавляет, нет, поэтому разумно менять значение ступенями, следя за расходом памяти процессом RpcSs, и не ставить сразу рекордное число на все серверы. Проверка результата состоит из трёх признаков: значение читается командой reg query, после перезагрузки веб-доступ и отправка работают, а записей с кодом 1006 в журнале за следующие сутки нет.
Порядок действий на неделю для администраторов серверов и почтовой инфраструктуры
Чтобы не держать всё это в голове, действия можно разложить в короткую последовательность. Она подходит и тем, кто отвечает за один сервер, и командам, где доверие, обновления и почта живут в разных руках.
Рабочая последовательность состоит из следующих шагов:
- Составить список серверов Windows Server 2022 и отметить, какие из них получают списки доверия автоматически, а какие живут в изоляции или с выключенной политикой автообновления корней;
- Проверить сборку на каждом сервере: 20348.5773 означает, что KB5134140 установлен, а 20348.5761 означает, что на месте только октябрьское обновление;
- Для изолированных серверов доставить пакет вручную или подготовить папку с файлами каталогов через certutil -syncWithWU и настроить к ней путь;
- Убедиться, что корни eMudhra в хранилище отсутствуют, а значение DisableRootAutoUpdate не мешает получению списков там, где автообновление должно работать;
- На каждом сервере Exchange проверить значение EpmapSavedContextCap и просмотреть журнал приложения на записи с кодом 1006 за последние дни;
- Задать значение 65536 там, где признаки проблемы есть, перезагружая серверы группы доступности по одному в режиме обслуживания;
- Вести наблюдение не меньше двух суток, помня о цикле в 22-30 часов, и при возвращении симптомов поднимать лимит ступенями;
- Зафиксировать в журнале изменений версии, значения и даты, а следующую проверку назначить на ноябрьский набор обновлений от 10 ноября и на новую запись о статусе известной проблемы.
Две темы, которые на первый взгляд никак не связаны, оказались в одном пакете, и это хороший повод пересмотреть привычку читать описания обновлений по диагонали. Накопительное обновление всегда несёт на себе багаж предыдущих, и "выпущено по срочной причине" ещё не значит "ничего лишнего". К тому же календарь у почтовых серверов непростой: последние плановые обновления безопасности для Exchange 2016 и 2019 вышли в октябре, дальше они будут выходить только для Subscription Edition, так что запас прочности у старых серверов тает вместе с каждым месяцем. Админ, который сегодня разложил доверие и лимиты по полочкам, завтра не будет разбираться с зависшими письмами в разгар рабочего дня.