{"schema_version":"1.0","service":"Publicasta","type":"article","id":935,"slug":"emudhra_ca_key_compromise_browser_trust_store_update","title":"Компрометация ключей УЦ eMudhra превращает обновление доверия браузеров в проверку ИТ-парка","excerpt":"Были скомпрометированы ключи восьми промежуточных сертификатов eMudhra, из-за чего браузеры, операционные системы и пакеты начали отзывать доверие. Проверки могут потребоваться и для неуправляемых хранилищ, TLS-инспекции и подписанного ПО.","language":"ru","default_language":"en","canonical_url":"https://publicasta.com/it_today_news/emudhra_ca_key_compromise_browser_trust_store_update?lang=ru","image":{"url":"https://publicasta.com/storage/projects/17/pages/935/2026/10/06122f7c-9c09-42f1-b1c4-b43140a5259d.webp","alt":"Специалист по кибербезопасности проверяет цепочки сертификатов и состояние хранилищ доверия в серверной инфраструктуре"},"publisher":{"id":17,"slug":"it_today_news","name":"ИТ сегодня","url":"https://publicasta.com/it_today_news"},"author":{"name":"Anton R"},"published_at":"2026-10-22T06:41:46+00:00","updated_at":"2026-10-22T06:41:46+00:00","content_markdown":"## Что было скомпрометировано, а что — нет\n\n ![Специалист по кибербезопасности проверяет цепочки сертификатов и состояние хранилищ доверия в серверной инфраструктуре](https://publicasta.com/storage/projects/17/pages/935/2026/10/06122f7c-9c09-42f1-b1c4-b43140a5259d.webp)\n\n 17 октября инцидент eMudhra перестал быть исключительно проблемой управления сертификатами и превратился в более масштабный вопрос доверия. Расследование показало, что закрытые ключи восьми подчинённых центров сертификации eMudhra можно было восстановить: при их генерации использовалась недостаточная криптографическая случайность. Это существенно, поскольку скомпрометированный закрытый ключ УЦ позволяет атакующему создавать сертификаты, которые выглядят как выпущенные через доверенную цепочку. Поэтому реагирование нельзя ограничить вопросом о том, посещался ли конкретный сайт. Нужно точно определить, какие центры выдачи затронуты, и отделить подтверждённую уязвимость от предположений об остальной иерархии eMudhra.\n\n Восемь затронутых подчинённых УЦ делятся на две отдельные группы. Шесть из них — промежуточные TLS-центры, использовавшиеся в цепочках сертификатов для зашифрованных сетевых соединений. Ещё два — промежуточные центры для подписи кода, поддерживавшие подписи программного обеспечения и другого подписанного содержимого. Если считать эти категории взаимозаменяемыми, можно смешать два разных вопроса проверки. Браузер или операционная система оценивает TLS-цепочку при подключении к сервису, тогда как средство проверки подписи анализирует саму подпись и её цепочку сертификатов, решая, можно ли доверять программному обеспечению. В обоих случаях задействована инфраструктура сертификатов, но сценарии использования и системы, которые кэшируют или применяют доверие, различаются.\n\n В уведомлениях Google и Mozilla говорится, что компрометация затронула именно эти восемь промежуточных УЦ eMudhra. В тех же рекомендациях проведена важная граница вокруг того, что не установлено: в указанных уведомлениях нет признаков того, что были скомпрометированы все корневые сертификаты eMudhra или каждый другой промежуточный сертификат eMudhra. Это не означает, что все сертификаты eMudhra можно оставить без изменений, но и не даёт оснований считать весь центр сертификации одинаково небезопасным. Практический вопрос уже и полезнее: зависит ли система от одного из выявленных промежуточных УЦ либо от цепочки, проходящей через корневой или перекрёстно подписывающий путь, который поставщики выводят из доверия?\n\n Именно это различие объясняет, почему реагирование реализуется через точечные действия по отзыву доверия, а не через общее утверждение, будто любой сертификат, выданный eMudhra, недействителен. Механизмы поставщиков могут блокировать сертификаты, связанные с затронутыми открытыми ключами, или удалять конкретные доверенные пути. При этом администраторам всё равно нужно выяснить, зависят ли их собственные сертификаты, инфраструктура инспекции, рабочие процессы проверки программ или встроенные хранилища доверия от этих путей. Иными словами, подтверждённая компрометация определяет набор ключей, которые необходимо считать раскрытыми; сама по себе она не отвечает, какие сервисы организации перестанут работать после ужесточения проверки доверия.\n\n Техническая причина не менее важна. Возможность восстановить закрытые ключи объясняется недостаточной случайностью при генерации криптографических ключей. Это не то же самое, что доказательства подбора пароля или получения закрытого ключа в результате обычного взлома сервера. Однако если исходный материал ключа можно восстановить, практическое последствие для доверяющих сторон будет похожим: сертификаты, выданные затронутыми подчинёнными УЦ, больше нельзя считать надёжными только потому, что в них указано знакомое имя eMudhra или их цепочка ведёт к признанному корневому сертификату. При проверке нужно учитывать конкретного скомпрометированного издателя и используемые теперь механизмы отзыва доверия.\n\n Поэтому для ИТ-команд первой границей инвентаризации должна быть цепочка сертификатов, а не бренд, отображаемый в средстве просмотра сертификата. Зафиксируйте, заканчиваются ли сертификаты на одном из шести затронутых TLS-промежуточных УЦ, зависит ли подписанное программное обеспечение от одного из двух промежуточных УЦ для подписи кода и достигает ли цепочка затронутого корневого или перекрёстно подписывающего пути, удаление которого поставщик запланировал. При этом не скрывайте отрицательный результат: из приведённых здесь уведомлений не следует автоматически, что системы, использующие другие корневые или промежуточные УЦ eMudhra, были скомпрометированы. Такое разделение делает последующее устранение проблемы точнее, сохраняет обоснованную запись о проведённых проверках и не позволяет превратить целевое обновление хранилища доверия в неоправданный масштабный сбой.\n\n ## Почему пользователи браузеров оказались защищены быстрее, чем пользователи другого ПО\n\n Первый уровень защиты достиг массовых браузеров, поскольку их разработчики могут распространять решения о недоверии через централизованно управляемые механизмы обновления. Chrome использовал блокировку на основе SPKI в CRLSet, чтобы отклонять сертификаты, связанные с скомпрометированными промежуточными ключами eMudhra. Важно, что это действие нацелено на идентификатор открытого ключа центра сертификации, а не только на серийный номер одного сертификата. Благодаря этому браузер может блокировать затронутые цепочки, даже если предъявляемый сертификат новый, заменённый или иным образом не внесён в отдельный список. На Android Google также задействовала Google Play Services, чтобы расширить защиту за пределы самого браузера: соответствующее решение о недоверии могло поступить на поддерживаемые устройства через системный сервис, не дожидаясь, пока каждое приложение реализует собственную логику работы с сертификатами.\n\n Firefox преследовал ту же цель с помощью OneCRL — механизма Mozilla для распространения решений об отзыве сертификатов клиентам Firefox. Mozilla также описала изменения в хранилище корневых сертификатов, которые действуют на более широкой границе доверия: вместо отклонения только сертификатов, выпущенных конкретным промежуточным центром, клиент может полностью перестать доверять корневому сертификату или связанному с ним пути сертификации. Такой охват полезен, когда к одной экосистеме можно подключиться через разные промежуточные центры или схемы кросс-подписания, но он же объясняет, почему изменения доверия требуют тщательной оценки. Обновление браузера может закрыть уязвимость в обычных веб-сеансах, оставив другое ПО с иным представлением о той же цепочке сертификатов.\n\n Certificate Transparency помогла сократить окно риска для клиентов, которые её проверяют, поскольку от публично доверенных TLS-сертификатов ожидается наличие проверяемой записи в общедоступных журналах. Для клиента, выполняющего такую проверку, эта запись может служить основой для обнаружения сертификатов и принятия политических решений о сертификатах, которые не должны были выпускаться или которым не следует доверять. Однако это не превращает каждого потребителя TLS в систему, выполняющую проверку Certificate Transparency. Проверки Certificate Transparency, механизмы отзыва и обновления хранилищ доверия — отдельные средства контроля, и приложение может реализовывать некоторые из них, не реализовывать ни одного или использовать внутренний вариант, работающий иначе, чем актуальный браузер.\n\n Поэтому фразу «пользователи браузеров были защищены» нельзя понимать как «все системы, использующие TLS, были защищены». Браузер обычно получает управляемые поставщиком политики и обновления хранилища доверия, но организация также может полагаться на пакеты сертификатов операционной системы, встроенные хранилища приложений, хранилища Java и других сред выполнения, сетевые устройства, системы инспекции TLS, образы контейнеров и отдельные библиотеки. Эти компоненты могут обновляться по разным графикам или требовать от администратора непосредственной замены пакета. Одни приложения выполняют собственные проверки отзыва, другие зависят от операционной системы хоста. Сервис, который не обращается к обновлённому хранилищу, может продолжать строить цепочку, отклоняемую актуальным браузером.\n\n Сбой может развиваться и в противоположном направлении. Клиент способен иметь функцию проверки отзыва, но считать недоступный ответ приемлемым либо переходить в режим разрешения при невозможности завершить проверку. В таком случае наличие сигнала об отзыве не гарантирует его исполнения. Значение имеют локальная политика, доступность сети, кэшированные решения и поведение приложения. То же касается устройств, которые завершают или инспектируют TLS: браузер на конечной точке может быть обновлён, тогда как промежуточное устройство всё ещё хранит старый набор доверия и продолжает принимать или создавать цепочки в соответствии со своей конфигурацией.\n\n Для ИТ-команд практическое различие заключается в защите браузеров, управляемой поставщиком, и решениях о доверии, контролируемых локально. Ответ CRLSet в Chrome, средства защиты Google Play Services, действие OneCRL в Firefox и изменения хранилища корневых сертификатов снижают риск для клиентов, которые получают и применяют эти меры. Но они не доказывают, что каждый компонент парка, работающий с сертификатами, имеет такой же охват. Вопрос уже не сводится к тому, обновили ли пользователи браузеры. Нужно понять, выявила ли организация ПО и устройства, которые поддерживают отдельные хранилища доверия, самостоятельно выполняют проверки отзыва или продолжают работать при сбое этих проверок.\n\n ## Операционные сбои, к которым ИТ-командам нужно подготовиться\n\n Отзыв доверия к скомпрометированному центру сертификации необходим для клиентов, способных применить это изменение, но он не проходит бесследно для инфраструктуры. Google предупреждает, что удаление **emSign ECC Root CA - G3** может нарушить работу легитимных сертификатов, которые по-прежнему зависят от этого корневого сертификата или связанной с ним цепочки. Анализ Mozilla также указывает на несколько затронутых корневых и перекрёстно подписанных путей. Поэтому для ИТ-команд практический вопрос заключается не только в том, сообщает ли браузер о доверии к сертификату. Нужно выяснить, не зависит ли какой-либо бизнес-сервис, устройство инспекции трафика, программный пакет или процесс проверки от пути, который вскоре перестанет считаться доверенным.\n\n Веб-сайты следует рассматривать как одну категорию инвентаризации, а не как замену проверке всего парка. Публичный сервис может передавать сертификат по цепочке, которую браузеры быстро обновят, тогда как внутренний сервис, устаревшая конечная точка или небраузерный клиент продолжит строить эту цепочку иначе. То же относится и к серверам: сервер может быть правильно настроен для входящих соединений, но при исходящих вызовах всё ещё зависеть от затронутого сертификата. Поэтому поиск сертификатов должен охватывать как сертификаты, которые предоставляют принадлежащие организации сервисы, так и сертификаты, которым доверяют системы, обеспечивающие их работу.\n\n Инспекция TLS создаёт ещё один сценарий отказа. Сетевые устройства и корпоративные прокси часто завершают соединение, анализируют его, а затем от имени пользователя устанавливают второе соединение. Если у устройства есть собственное хранилище доверия, встроенный пакет сертификатов или управляемая поставщиком логика проверки, обновление браузера на конечной точке может не изменить способ, которым это устройство оценивает затронутую цепочку. И наоборот, замена или удаление сертификата, используемого системой инспекции, способно одновременно прервать трафик для множества пользователей. Шлюзы инспекции, балансировщики нагрузки и другие посредники следует проверять как самостоятельных потребителей доверия, отдельно фиксируя их конфигурацию и механизмы обновления, не смешивая их с браузерами на конечных устройствах.\n\n Образы контейнеров и прикладные среды создают аналогичное разделение между операционной системой и рабочей нагрузкой. Образ может содержать пакетный набор CA-сертификатов, который останется неизменным после обновления хоста. Развёртывания Java и другие приложения со своими наборами сертификатов также могут продолжать использовать встроенное хранилище доверия вместо хранилища платформы. Поэтому образ, среда выполнения и пакет приложения нужно учитывать как отдельные вопросы инвентаризации. Командам следует определить, какие сервисы наследуют доверие от хоста, какие копируют сертификаты в образ, а какие поддерживают частный набор, обновляемый в рамках собственного процесса выпуска приложения.\n\n Проверку подписей кода необходимо проводить отдельно от HTTPS. Среди скомпрометированных промежуточных сертификатов eMudhra есть не только сертификаты для TLS, но и сертификаты для подписи кода, поэтому реакция, ориентированная на браузеры, ещё не означает, что пути проверки программного обеспечения были изучены. Системы сборки, средства защиты конечных точек, менеджеры пакетов и другие системы проверки подписей могут использовать другие корневые и промежуточные сертификаты или иные правила отзыва. Кроме того, они могут применять политики не в тот же момент, что браузер или хранилище доверия операционной системы. Важно выяснить не то, получил ли рабочий компьютер обновление браузера, а то, проверила ли каждая система, принимающая подписанное ПО, затронутые пути подписи.\n\n Риск сбоев особенно высок там, где доверие дублируется, встраивается в компоненты или проходит через устройства-посредники. Массовое удаление доверия может закрыть скомпрометированный путь для клиентов, соблюдающих новую политику, но то же изменение способно сделать легитимный сервис недоступным, если его цепочка сертификатов ещё не заменена. Узкая мера сохранит доступность, однако оставит неуправляемые клиенты под угрозой. Поэтому перед общесистемными изменениями стоит составить карту зависимостей: зафиксировать сертификат, цепочку, хранилище доверия, проверяющий компонент и связанный бизнес-сервис, а затем протестировать результат именно в той среде, где фактически выполняется проверка.\n\n Для смешанных парков «обновлённый» браузер — это далеко не всё. Нужно убедиться, что проверены соответствующие цепочки сайтов, конфигурации серверов, устройства инспекции, контейнерные и Java-хранилища доверия, пакеты приложений и валидаторы подписей кода. Если изменение корневого хранилища может повлиять на легитимные сертификаты, его следует внедрять поэтапно и заранее подготовить план отката, связанный с проверенными зависимостями сервисов. Цель — контролируемый отказ от доверия: убрать зависимость от скомпрометированных путей и при этом сохранить понятный, подтверждённый данными способ восстановить работу, если легитимная цепочка была упущена.\n\n ## Обоснованный план реагирования для смешанных парков\n\n Безопаснее всего рассматривать инцидент eMudhra как задачу по проверке хранилищ доверия и инвентаризации сертификатов, а не как обновление браузеров. Сначала определите, где в инфраструктуре доверяют затронутым промежуточным сертификатам eMudhra и их корневым сертификатам: на управляемых рабочих станциях, серверах, в контейнерах, Java- и прикладных пакетах, сетевых устройствах, средствах TLS-инспекции, мобильных устройствах, а также в системах сборки и подписания. Важен не сам факт актуальности браузера. Нужно понять, может ли критичное для бизнеса соединение, библиотека валидации, сетевое устройство или процесс работы с подписанным ПО по-прежнему принять цепочку, которая больше не должна считаться доверенной.\n\n Используйте рекомендации поставщиков как первую точку контроля. В рамках обычного процесса управления изменениями установите соответствующие обновления Chrome, Firefox, Android, Ubuntu и других пакетов, затем проверьте на репрезентативных системах, что ожидаемое изменение хранилища доверия или механизма отзыва действительно применилось. Обновление Ubuntu `ca-certificates` особенно важно для систем, использующих дистрибутивный набор доверенных сертификатов. Браузеры и приложения со своими хранилищами нужно проверять отдельно. Для каждой поддерживаемой платформы зафиксируйте версию пакета или браузера, статус обновления и состояние хранилища доверия. Тогда слово «исправлено» будет иметь проверяемый смысл, а не выводиться только из факта последнего выхода устройства на связь.\n\n Затем составьте карту сертификатов и путей валидации. Проверьте реестры сертификатов, конфигурации балансировщиков и веб-серверов, сервисные сетки, образы контейнеров, хранилища ключей Java, пакеты приложений, профили инспекции и политики сетевых устройств на наличие затронутых промежуточных сертификатов eMudhra и связанных с ними корней. Для сертификатов, используемых на внешних ресурсах, определите полную цепочку, которую фактически отдаёт каждая конечная точка: сертификат может быть действительным в браузере, тогда как другой клиент, прокси или серверная библиотека выберет иной путь. Для внутреннего или инспектируемого трафика изучите обе стороны соединения: настройки доверия на устройстве инспекции и хранилище доверия клиента, который получает перевыпущенный сертификат. Проверку подписей кода следует отделять от анализа TLS: сертификат подписи может повлиять на распространение и запуск ПО даже при полном отсутствии браузера.\n\n Замену следует выполнить до изменения Chrome Root Store, запланированного на 27 октября. Любой сертификат внешнего сервиса, зависящий от затронутого пути, нужно перевыпустить или заменить цепочкой, которая не использует скомпрометированные промежуточные сертификаты или корень, намеченный к исключению из доверия, а затем развернуть её в контролируемой последовательности. Операционная цель — устранить рискованную зависимость до того, как клиенты начнут применять новое состояние, а не ждать сбоев соединений, чтобы выяснить, какой сервис был пропущен. Замена сертификата должна охватывать отдаваемую цепочку, установку промежуточных сертификатов, автоматизацию продления, а также любые закреплённые или явно заданные отношения доверия, способные помешать принять новую цепочку.\n\n Тестирование должно охватывать пути, которые обычная проверка в браузере не обнаруживает. Составьте небольшую, но репрезентативную матрицу критичных для бизнеса сайтов, API, исходящих интеграций, административных консолей, маршрутов инспекции, контейнерных сервисов, Java-приложений, мобильных сценариев, а также процессов подписания и обновления программного обеспечения. Проверяйте системы из управляемых и неуправляемых сетевых сегментов, если оба типа входят в область работ, и используйте те обновлённые хранилища доверия и версии браузеров, которые получат рабочие системы. Успешная загрузка страницы — лишь один из результатов. Там, где это важно, фиксируйте проверку цепочки сертификатов, поведение прокси, работу прикладных библиотек и возможность устанавливать или проверять подписанное ПО.\n\n Поскольку удаление корневого сертификата может нарушить работу легитимных сертификатов, при невозможности полностью оценить среду за одно окно обслуживания недоверие следует вводить поэтапно. Начните с инвентаризации и выявления зависимостей, затем обновите контролируемую пилотную группу, наблюдайте за сбоями и расширяйте охват после проверки критически важных путей. Если сервис зависит от отклоняемого сертификата, предпочтительный откат — документированное исправление сертификата или цепочки на стороне сервиса. Когда временное исключение из доверия неизбежно, рассматривайте его как явное ограниченное по времени решение о принятии риска с назначенными ответственным и датой удаления, а не как незаметное восстановление широкого доверия во всем парке.\n\n Наконец, сохраните подтверждения, демонстрирующие и выполненные действия, и охват: обнаруженные затронутые активы, замененные сертификаты, установленные обновления поставщиков, проверенные хранилища доверия, завершенные тесты, утвержденные исключения и назначенные ответственные за оставшиеся пробелы. Такая запись помогает отличить реальное отсутствие уязвимости от непроверенной системы и обеспечивает возможность дальнейших действий, когда дополнительные пакеты, приложения или устройства публикуют собственные рекомендации по устранению проблемы. Защищаемый результат заключается не просто в том, что крупные браузеры изменили свое поведение, а в способности организации показать, где доверие применялось, где оно было отозвано, какие сервисы прошли проверку и как управляется сохраняющаяся неопределенность.","available_translations":[{"language":"ar","title":"اختراق مفاتيح eMudhra CA يحوّل تحديثات ثقة المتصفحات إلى فحص لأسطول تقنية المعلومات","html_url":"https://publicasta.com/it_today_news/emudhra_ca_key_compromise_browser_trust_store_update?lang=ar","markdown_url":"https://publicasta.com/it_today_news/emudhra_ca_key_compromise_browser_trust_store_update.md?lang=ar","json_url":"https://publicasta.com/it_today_news/emudhra_ca_key_compromise_browser_trust_store_update.json?lang=ar","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/emudhra_ca_key_compromise_browser_trust_store_update?lang=ar"},{"language":"de","title":"Kompromittierte eMudhra-CA-Schlüssel machen Browser-Trust-Updates zum IT-Flottencheck","html_url":"https://publicasta.com/it_today_news/emudhra_ca_key_compromise_browser_trust_store_update?lang=de","markdown_url":"https://publicasta.com/it_today_news/emudhra_ca_key_compromise_browser_trust_store_update.md?lang=de","json_url":"https://publicasta.com/it_today_news/emudhra_ca_key_compromise_browser_trust_store_update.json?lang=de","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/emudhra_ca_key_compromise_browser_trust_store_update?lang=de"},{"language":"en","title":"eMudhra CA Key Compromise Turns Browser Trust Updates into an IT Fleet Check","html_url":"https://publicasta.com/it_today_news/emudhra_ca_key_compromise_browser_trust_store_update?lang=en","markdown_url":"https://publicasta.com/it_today_news/emudhra_ca_key_compromise_browser_trust_store_update.md?lang=en","json_url":"https://publicasta.com/it_today_news/emudhra_ca_key_compromise_browser_trust_store_update.json?lang=en","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/emudhra_ca_key_compromise_browser_trust_store_update?lang=en"},{"language":"es","title":"El compromiso de claves de eMudhra CA convierte las actualizaciones de confianza del navegador en una revisión de toda la flota informática","html_url":"https://publicasta.com/it_today_news/emudhra_ca_key_compromise_browser_trust_store_update?lang=es","markdown_url":"https://publicasta.com/it_today_news/emudhra_ca_key_compromise_browser_trust_store_update.md?lang=es","json_url":"https://publicasta.com/it_today_news/emudhra_ca_key_compromise_browser_trust_store_update.json?lang=es","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/emudhra_ca_key_compromise_browser_trust_store_update?lang=es"},{"language":"fr","title":"La compromission d’une AC eMudhra transforme les mises à jour de confiance des navigateurs en audit du parc informatique","html_url":"https://publicasta.com/it_today_news/emudhra_ca_key_compromise_browser_trust_store_update?lang=fr","markdown_url":"https://publicasta.com/it_today_news/emudhra_ca_key_compromise_browser_trust_store_update.md?lang=fr","json_url":"https://publicasta.com/it_today_news/emudhra_ca_key_compromise_browser_trust_store_update.json?lang=fr","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/emudhra_ca_key_compromise_browser_trust_store_update?lang=fr"},{"language":"pl","title":"Kompromitacja kluczy CA eMudhra zmienia aktualizacje zaufania przeglądarek w kontrolę floty IT","html_url":"https://publicasta.com/it_today_news/emudhra_ca_key_compromise_browser_trust_store_update?lang=pl","markdown_url":"https://publicasta.com/it_today_news/emudhra_ca_key_compromise_browser_trust_store_update.md?lang=pl","json_url":"https://publicasta.com/it_today_news/emudhra_ca_key_compromise_browser_trust_store_update.json?lang=pl","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/emudhra_ca_key_compromise_browser_trust_store_update?lang=pl"},{"language":"ru","title":"Компрометация ключей УЦ eMudhra превращает обновление доверия браузеров в проверку ИТ-парка","html_url":"https://publicasta.com/it_today_news/emudhra_ca_key_compromise_browser_trust_store_update?lang=ru","markdown_url":"https://publicasta.com/it_today_news/emudhra_ca_key_compromise_browser_trust_store_update.md?lang=ru","json_url":"https://publicasta.com/it_today_news/emudhra_ca_key_compromise_browser_trust_store_update.json?lang=ru","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/emudhra_ca_key_compromise_browser_trust_store_update?lang=ru"},{"language":"zh","title":"eMudhra CA 密钥泄露：浏览器信任更新转变为 IT 资产盘点","html_url":"https://publicasta.com/it_today_news/emudhra_ca_key_compromise_browser_trust_store_update?lang=zh","markdown_url":"https://publicasta.com/it_today_news/emudhra_ca_key_compromise_browser_trust_store_update.md?lang=zh","json_url":"https://publicasta.com/it_today_news/emudhra_ca_key_compromise_browser_trust_store_update.json?lang=zh","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/emudhra_ca_key_compromise_browser_trust_store_update?lang=zh"}],"_links":{"self":"https://publicasta.com/it_today_news/emudhra_ca_key_compromise_browser_trust_store_update.json?lang=ru","api":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/emudhra_ca_key_compromise_browser_trust_store_update?lang=ru","html":"https://publicasta.com/it_today_news/emudhra_ca_key_compromise_browser_trust_store_update?lang=ru","canonical":"https://publicasta.com/it_today_news/emudhra_ca_key_compromise_browser_trust_store_update?lang=ru","markdown":"https://publicasta.com/it_today_news/emudhra_ca_key_compromise_browser_trust_store_update.md?lang=ru","json":"https://publicasta.com/it_today_news/emudhra_ca_key_compromise_browser_trust_store_update.json?lang=ru","channel":"https://publicasta.com/api/public/v1/channels/it_today_news","channel_articles":"https://publicasta.com/api/public/v1/channels/it_today_news/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}