Обновление хэша алгоритма цифровой подписи с sha 1 на sha 2

Обновлено: 21.11.2024

SHA-1, SHA-2, SHA-256, SHA-384 — что все это значит!!

Если вы слышали о «SHA» во многих его формах, но не совсем уверены, что это за аббревиатура и почему это важно, сегодня мы попытаемся пролить на это немного света.< /p>

Прежде чем мы сможем перейти к самому SHA, нам нужно разобраться, что такое хеш, а затем мы узнаем, как SSL-сертификаты используют хэши для формирования цифровых подписей. Это важные понятия, которые необходимо понять, прежде чем вы сможете понять, что такое SHA-1 и SHA-2.

Что такое хэш?

Алгоритм хеширования – это математическая функция, сжимающая данные до фиксированного размера. Так, например, если бы мы взяли предложение…

…и прогнали его через специальный алгоритм хеширования, известный как CRC32, и мы получили:

Этот результат известен как хэш или хеш-значение. Иногда хеширование называют односторонним шифрованием.

Хеши удобны в ситуациях, когда компьютерам может потребоваться идентифицировать, сравнить или иным образом выполнить вычисления с файлами и строками данных. Компьютеру проще сначала вычислить хэш, а затем сравнить значения, чем сравнивать исходные файлы.

Одним из ключевых свойств алгоритмов хэширования является детерминизм. Любой компьютер в мире, понимающий выбранный вами алгоритм хеширования, может локально вычислить хэш нашего примерного предложения и получить тот же ответ.

Алгоритмы хэширования используются самыми разными способами — они используются для хранения паролей, в компьютерном зрении, в базах данных и т. д.

Существуют сотни алгоритмов хэширования, и все они предназначены для определенных целей: одни оптимизированы для определенных типов данных, другие — для скорости, безопасности и т. д.

Для сегодняшнего обсуждения нам нужны только алгоритмы SHA. SHA расшифровывается как Secure Hash Algorithm — его название раскрывает его назначение — это криптографическая безопасность.

Если вы вынесете из этого раздела только одну вещь, она должна заключаться в следующем: алгоритмы криптографического хэширования производят необратимые и уникальные хэши. Необратимость означает, что если бы у вас был только хэш, вы не могли бы использовать его, чтобы выяснить, что представлял собой исходный фрагмент данных, что позволяет исходным данным оставаться безопасными и неизвестными. Уникальность означает, что два разных фрагмента данных никогда не смогут создать один и тот же хэш. В следующем разделе объясняется, почему это так важно.

Примечание. Чтобы упростить чтение и понимание этой статьи, я использую в качестве примера строку данных и алгоритм хэширования, который значительно короче, чем тот, который фактически используется на практике. Хэши, которые вы видели до сих пор, НЕ являются хэшами SHA любого типа.

Теперь, когда мы знаем, что такое хэши, мы можем объяснить, как они используются в SSL-сертификатах.

Протокол SSL/TLS используется для обеспечения безопасной передачи данных с одного устройства на другое через Интернет. Для краткости кажется, что SSL часто называют «шифрованием». Но не забывайте, что SSL также обеспечивает аутентификацию. Файл сертификата SSL предназначен для предоставления необходимой информации, необходимой для аутентификации. Другими словами, SSL-сертификаты связывают определенный открытый ключ с личностью.

Помните, что протокол SSL/TLS упрощает подключение с использованием асимметричного шифрования. Это означает, что есть два ключа шифрования, каждый из которых выполняет одну половину процесса: открытый ключ для шифрования и закрытый ключ для расшифровки. Каждый SSL-сертификат содержит открытый ключ, который может использоваться клиентом для шифрования данных, а владелец указанного SSL-сертификата надежно хранит закрытый ключ на своем сервере, который он использует для расшифровки этих данных и их чтения.

В конечном счете, основной целью этого асимметричного шифрования является безопасный обмен ключами. Из-за вычислительной мощности, которую требуют асимметричные ключи, более практично (и при этом безопасно) использовать меньшие симметричные ключи для фактической коммуникационной части соединения. Таким образом, клиент создает ключ сеанса, затем шифрует его копию и отправляет на сервер, где ее можно расшифровать и использовать для связи в течение всего времени соединения (или до тех пор, пока он не будет отключен).

Вот почему аутентификация невероятно важна для того, чтобы убедиться, что SSL/TLS действительно обеспечивает значимую безопасность. Представьте, если бы у вашего компьютера не было надежного способа узнать, кому принадлежит ключ шифрования, который вы использовали?Шифрование вашего сеансового ключа с помощью этого открытого ключа было бы бесполезным, потому что вы не знали бы, у кого есть соответствующий закрытый ключ, который его расшифровывает. В конце концов, шифрование данных бесполезно, если вы отправляете их напрямую злоумышленнику-посреднику или злоумышленнику на другом конце соединения.

Цифровые подписи — важная часть аутентификации с помощью SSL-сертификатов. Когда сертификат выпускается, он подписывается цифровой подписью Центра сертификации (ЦС), который вы выбрали в качестве поставщика сертификата (например, Sectigo, DigiCert и т. д.). Эта подпись обеспечивает криптографическое доказательство того, что ЦС подписал SSL-сертификат и что сертификат не был изменен или воспроизведен. Что еще более важно, подлинная подпись является криптографическим доказательством того, что информация, содержащаяся в сертификате, была проверена доверенной третьей стороной.

Теперь давайте поговорим о том, как создается, наносится и ставится цифровая подпись — вы выбираете терминологию. Асимметричные ключи, о которых мы упоминали ранее, снова используются, но для подписи, а не для шифрования. С математической точки зрения подписание включает в себя изменение способа объединения данных и ключей (мы не будем слишком углубляться в особенности создания подписей, потому что это быстро усложняется. Если вам это интересно, Джошуа Дэвис написал отличный пост о том, как работают цифровые подписи). Чтобы облегчить компьютерам быстрое, но безопасное создание и проверку этих подписей, ЦС сначала хеширует файл сертификата и подписывает полученный хэш. Это более эффективно, чем подписывать весь сертификат.

Эти цифровые подписи обеспечивают необходимое доказательство того, что выданный вам сертификат является именно тем сертификатом, который был выдан доверенным ЦС для рассматриваемого веб-сайта. Никаких трюков. Нет спуфинга. Никакие посредники не манипулируют файлом сертификата SSL/TLS.

Цифровые подписи невероятно конфиденциальны: любое изменение в файле приведет к изменению подписи. Если мы возьмем наше примерное предложение из предыдущего раздела и напишем его полностью строчными («быстрая коричневая лиса перепрыгивает через ленивую собаку»), результирующий хэш будет совершенно другим. Это означает, что результирующая подпись этого хэша также будет другой. Даже изменение одного бита в документе объемом в несколько тысяч гигабайт приведет к совершенно другому хэшу.

Это делает невозможным изменение законного сертификата злоумышленником или создание мошеннического сертификата, который выглядит законным. Другой хеш означает, что подпись больше не будет действительной, и ваш компьютер узнает об этом при аутентификации SSL-сертификата. Если ваш компьютер обнаружит недопустимую подпись, это вызовет ошибку и полностью помешает безопасному соединению.

SHA-1 и SHA-2

Теперь, когда мы заложили основу, мы можем перейти к главной роли.

Как я уже говорил ранее, SHA означает безопасный алгоритм хеширования. SHA-1 и SHA-2 — это две разные версии этого алгоритма. Они различаются как конструкцией (способом создания результирующего хэша из исходных данных), так и битовой длиной подписи. Вы должны думать о SHA-2 как о преемнике SHA-1, так как это общее улучшение.

В первую очередь люди обращают внимание на длину в битах как на важное различие. SHA-1 — это 160-битный хэш. SHA-2 на самом деле представляет собой «семейство» хэшей различной длины, самая популярная из которых — 256-битная.

Разнообразие хэшей SHA-2 может привести к некоторой путанице, поскольку веб-сайты и авторы выражают их по-разному. Если вы видите «SHA-2», «SHA-256» или «SHA-256 бит», эти имена относятся к одному и тому же. Если вы видите «SHA-224», «SHA-384» или «SHA-512», это относится к альтернативной битовой длине SHA-2. Вы также можете увидеть, что некоторые сайты являются более подробными и указывают как алгоритм, так и длину в битах, например «SHA-2 384». Но это так же отвратительно, как заставлять людей включать свой инициал отчества, когда вы произносите свое имя.

Индустрия SSL выбрала SHA в качестве алгоритма хеширования цифровых подписей

С 2011 по 2015 год SHA-1 был основным алгоритмом. Растущее количество исследований, показывающих слабые стороны SHA-1, вызвало переоценку. На самом деле, Google даже зашел так далеко, что создал коллизию SHA-1 (когда две части разрозненных данных создают одно и то же значение хеш-функции) просто для обеспечения. Итак, с 2016 года SHA-2 является новым стандартом. Если вы получаете сертификат SSL/TLS сегодня, он должен использовать как минимум эту подпись.

Иногда вы увидите сертификаты, использующие 384-битный алгоритм SHA-2.Вы редко встретите 224-разрядную версию, которая не одобрена для использования с общедоступными доверенными сертификатами, или 512-разрядную версию, которая менее широко поддерживается программным обеспечением.

SHA-2, скорее всего, будет использоваться не менее пяти лет. Однако может быть обнаружена непредвиденная атака на алгоритм, которая вызовет более ранний переход.

Вот как выглядит хэш SHA-1 и SHA-2 SSL-сертификата нашего веб-сайта:

Так что да. Вот из-за этого вся суета. Это может показаться не таким уж большим, но цифровые подписи невероятно важны для обеспечения безопасности SSL/TLS.

По теме: Защитите свой веб-сайт с помощью SSL-сертификата Comodo.

Большой битовый хеш может обеспечить большую безопасность, поскольку существует больше возможных комбинаций. Помните, что одна из важных функций алгоритма криптографического хеширования заключается в том, что он создает уникальные хэши. Опять же, если два разных значения или файла могут создать один и тот же хэш, вы создаете то, что мы называем коллизией.

Безопасность цифровых подписей может быть гарантирована только в том случае, если не происходит коллизий. Конфликты чрезвычайно опасны, потому что они позволяют двум файлам создавать одну и ту же подпись, поэтому, когда компьютер проверяет подпись, она может оказаться действительной, даже если этот файл никогда не был подписан.

Если предполагается, что алгоритм хэширования создает уникальные хэши для каждого возможного входного значения, то сколько существует возможных хэшей?

Бит имеет два возможных значения: 0 и 1. Возможное количество уникальных хэшей можно выразить как количество возможных значений, возведенное в число битов. Для SHA-256 существует 2 256 возможных комбинаций.

Итак, 2 256 комбинаций. Сколько это? Что ж, это огромное число. Серьезно. Это ставит такие числа, как триллион и септиллион, в позор. Это намного превышает количество песчинок в мире.

Чем больше количество возможных хэшей, тем меньше вероятность того, что два значения создадут один и тот же хэш.

Существует (технически) бесконечное количество возможных входов[1], но ограниченное количество выходов. Таким образом, в конечном итоге каждый алгоритм хеширования, включая безопасный, приводит к коллизии. Но нас больше всего беспокоит, насколько легко это будет сделать. SHA-1 был признан небезопасным, поскольку из-за его размера и конструкции можно было создать коллизию.

Обратите внимание, что большая длина в битах не означает автоматически, что алгоритм хеширования создает более безопасные хэши. Конструкция алгоритма также невероятно важна — именно поэтому индустрия SSL использует алгоритмы хэширования, специально разработанные для криптографической защиты.

Переход на SHA-2

В 2015 году в отрасли SSL произошел переход на SHA-2. Это включало перевыпуск тысяч существующих сертификатов, чтобы можно было создавать и подписывать новые файлы с помощью SHA-2. Это также связано с крупными обновлениями программного обеспечения для выдачи, с которым работают общедоступные доверенные центры сертификации (их десятки). Как и ожидалось, были некоторые сбои.

Крайний срок выпуска новых SSL-сертификатов с хешами SHA-1 – 31 декабря 2015 года. По большей части отрасль уложилась в этот срок. С тех пор было допущено несколько ошибок и разрешено несколько особых случаев.

Браузеры обрабатывали сертификаты, подписанные SHA-1, срок действия которых истекает в 2017 году, с более строгим предупреждением. Это связано с тем, что безопасность подписи напрямую связана с тем, как долго она действительна.

Теперь, в 2018 году, Google без суда и следствия казнит владельца сайта и оставляет его труп в качестве предупреждения для других, которые могут осмелиться совершить те же грехи.

Защита подписей

Со временем атаки на криптографию будут улучшаться, а вычислительная мощность компьютеров будет дешеветь. Это делает действующую подпись SHA-2 менее безопасной в 2020 году, чем в 2016 году. По этой причине выбор алгоритма будет намного более надежным, чем это необходимо немедленно, чтобы краткосрочные улучшения не привели к риску безопасности. Не исключено, что конкретный алгоритм хеширования будет оставаться безопасным в течение десятилетия.

Отраслевые эксперты и исследователи безопасности по всему миру постоянно анализируют SHA-2 и другие криптографические алгоритмы хеширования, поэтому будьте уверены, что текущие SSL-сертификаты еще какое-то время будут иметь надежные и безопасные цифровые подписи.

Это не означает, что криптографы будут просто сидеть и ждать, пока не возникнет проблема. Преемник SHA-2, получивший удобное название SHA-3, уже завершен. Когда придет время сделать еще один переход, индустрия SSL может использовать SHA-3 в качестве следующего выбора или может обратиться к совершенно другому алгоритму.

Потребуются годы, чтобы должным образом изучить и проверить новые криптографические стандарты, а затем разработать поддерживающее их программное обеспечение. Надеюсь, вам приятно осознавать, что отрасль всегда находится как минимум на один шаг впереди.

Время от времени нам нравится повторно хешировать некоторые из наших лучших старых материалов в надежде, что они понравятся нашим новым читателям. Эта статья, первоначально написанная Винсентом Линчем 29 июня 2016 г., была обновлена и исправлена Патриком Ноэ в 2018 г.

Это обновление обеспечивает поддержку функций подписи и проверки кода Secure Hash Algorithm-2 (SHA-2) в 64-разрядной версии Windows Server 2008 с пакетом обновления 2 (SP2), которая включает следующее:

Поддержка нескольких подписей в CAB-файлах.

Поддержка нескольких подписей для файлов Windows PE.

Поддержка просмотра нескольких цифровых подписей путем обновления пользовательского интерфейса (UI).

Поддержка проверки временных меток RFC3161 для компонента Code Integrity, который проверяет подписи в ядре.

Поддержка различных интерфейсов прикладного программирования (API), включая CertIsStrongHashToSign, CryptCATAdminAcquireContext2 и CryptCATAdminCalcHashFromFileHandle2.

Алгоритм безопасного хеширования (SHA) был разработан для использования с алгоритмом цифровой подписи (DSA) или стандартом цифровой подписи (DSS). Это сгенерирует 160-битное хеш-значение. Но известная слабость SHA-1 подвергает себя атакам коллизии, которые позволяют злоумышленнику генерировать дополнительные сертификаты с той же цифровой подписью, что и оригинал. Дополнительные сведения о SHA-1 см. в разделе Алгоритмы хеширования и подписи.

Как получить это обновление

Каталог Центра обновления Майкрософт

Чтобы получить отдельный пакет для этого обновления, перейдите на веб-сайт каталога Центра обновления Майкрософт.

Обновить информацию

Предпосылки

Чтобы установить это обновление, у вас должна быть установлена 64-разрядная версия Windows Server 2008 SP2.

Информация о реестре

Чтобы применить это обновление, вам не нужно вносить какие-либо изменения в реестр.

Требование перезапустить

После установки этого обновления необходимо перезагрузить компьютер.

Обновить информацию о замене

Это обновление не заменяет ранее выпущенное обновление.

Подробнее

Ваша система продолжит поддерживать операции SHA-1 без изменений в этой поддержке. Поддержка SHA-2 становится доступной до того, как Microsoft изменит обновления Windows, чтобы отказаться от подписей SHA-1 и полностью перейти на подписи SHA-2. Выпуск этой поддержки SHA-2 — первый шаг в этом переходе. Позже эта поддержка станет обязательной, чтобы упростить переход на подписанные SHA-2 обновления для Windows Server 2008 SP2.

RFC3161 определяет протокол меток времени (TSP) инфраструктуры открытых ключей Интернета X.509 и описывает формат запросов и ответов для центра меток времени (TSA). TSA можно использовать для подтверждения того, что цифровая подпись была сгенерирована в течение срока действия сертификата открытого ключа, см. раздел Инфраструктура открытых ключей X.509.

В криптографии с открытым ключом один из ключей, известный как закрытый ключ, должен храниться в секрете. Другой ключ, известный как открытый ключ, предназначен для совместного использования со всем миром. Однако у владельца ключа должен быть способ сообщить миру, кому принадлежит этот ключ. Цифровые сертификаты позволяют это сделать.

Цифровой сертификат — это электронное удостоверение личности, используемое для подтверждения личности отдельных лиц, организаций и компьютеров в Интернете. Цифровые сертификаты содержат открытый ключ, упакованный вместе с некоторой базовой информацией (кому он принадлежит, для чего его можно использовать, когда истечет срок его действия и т. д.). Дополнительные сведения см. в разделе Общие сведения о криптографии с открытым ключом и цифровых сертификатах.

Цифровые сертификаты в основном используются для проверки личности человека или устройства, аутентификации службы или шифрования файлов. Обычно вам вообще не нужно думать о сертификатах, за исключением случайного сообщения о том, что сертификат просрочен или недействителен. В этих случаях следует следовать инструкциям, приведенным в сообщении.

Статус

Microsoft подтвердила, что это проблема продуктов Microsoft, перечисленных в разделе "Относится к".

Ссылки

Узнайте о терминологии, которую Microsoft использует для описания обновлений программного обеспечения.

Windows 7 с пакетом обновления 1 Windows Server 2008 R2 с пакетом обновления 1 Windows Server 2008 с пакетом обновления 2 Windows 10, версия 1607, все выпуски Windows 10, версия 1703, все выпуски Windows 10, версия 1709, все выпуски Windows 10, версия 1803 , все выпуски Windows 10, версия 1809, все выпуски Windows 10 Windows Server 2012 Standard Windows Server 2012 R2 Windows 8.1 Windows Server 2019, все выпуски Windows Server Update Services 3.0 Service Pack 2 Еще. Меньше

Обзор

Чтобы защитить безопасность операционной системы Windows, обновления ранее были подписаны (используя алгоритмы хеширования SHA-1 и SHA-2). Подписи используются для подтверждения того, что обновления поступают непосредственно от Microsoft и не были изменены во время доставки. Из-за недостатков алгоритма SHA-1 и для соответствия отраслевым стандартам мы изменили подписывание обновлений Windows, чтобы использовать исключительно более безопасный алгоритм SHA-2. Это изменение было внесено поэтапно, начиная с апреля 2019 г. по сентябрь 2019 г., чтобы обеспечить плавный переход (дополнительную информацию об изменениях см. в разделе "График обновления продукта").

Клиенты, которые работают с устаревшими версиями ОС (Windows 7 с пакетом обновления 1 (SP1), Windows Server 2008 R2 с пакетом обновления 1 (SP1) и Windows Server 2008 с пакетом обновления 2 (SP2)), должны установить на свои устройства поддержку подписи кода SHA-2 для установки обновлений, выпущенных в июле 2019 г. или позже. Любые устройства без поддержки SHA-2 не смогут устанавливать обновления Windows в июле 2019 г. или позже. Чтобы помочь вам подготовиться к этому изменению, мы выпустили поддержку подписи SHA-2 в марте 2019 г. и внесли дополнительные улучшения. Службы Windows Server Update Services (WSUS) 3.0 SP2 получат поддержку SHA-2 для безопасной доставки обновлений, подписанных SHA-2. В разделе "График обновления продукта" указан график миграции только с SHA-2.

Общие сведения

Алгоритм безопасного хеширования 1 (SHA-1) был разработан как функция необратимого хеширования и широко используется как часть подписи кода. К сожалению, безопасность алгоритма хеширования SHA-1 со временем стала менее надежной из-за обнаруженных в алгоритме слабых мест, повышения производительности процессора и появления облачных вычислений. Более надежные альтернативы, такие как алгоритм безопасного хеширования 2 (SHA-2), теперь настоятельно рекомендуются, поскольку они не вызывают тех же проблем. Дополнительные сведения об устаревании SHA-1 см. в разделе Алгоритмы хеширования и подписи.

Расписание обновлений продукта

С начала 2019 года процесс перехода на поддержку SHA-2 начался поэтапно, и поддержка будет предоставляться в виде отдельных обновлений. Microsoft ориентируется на следующий график, чтобы предложить поддержку SHA-2. Обратите внимание, что следующий график может быть изменен. Мы продолжим обновлять эту страницу по мере необходимости.

Целевая дата

12 марта 2019 г.

Выпущены автономные обновления безопасности KB4474419 и KB4490628, в которых реализована поддержка кодового знака SHA-2.

Windows 7 с пакетом обновления 1
Windows Server 2008 R2 с пакетом обновления 1

12 марта 2019 г.

Отдельное обновление KB4484071 доступно в каталоге Центра обновления Windows для WSUS 3.0 с пакетом обновления 2 (SP2), которое поддерживает доставку обновлений, подписанных SHA-2. Для клиентов, использующих WSUS 3.0 SP2, это обновление необходимо установить вручную не позднее 18 июня 2019 г.

9 апреля 2019 г.

Отдельное обновление KB4493730, которое вводит поддержку знака кода SHA-2 для стека обслуживания (SSU), было выпущено в качестве обновления безопасности.

Windows Server 2008 SP2

14 мая 2019 г.

Выпущено автономное обновление для системы безопасности KB4474419, в котором реализована поддержка кодового знака SHA-2.

Windows Server 2008 SP2

11 июня 2019 г.

Выпущено повторное обновление для системы безопасности KB4474419 для добавления отсутствующей поддержки кодового знака MSI SHA-2.

Windows Server 2008 SP2

18 июня 2019 г.

Подписи обновлений Windows 10 изменены с двойной подписи (SHA-1/SHA-2) на только SHA-2. Никаких действий со стороны клиента не требуется.

Windows 10, версия 1709
Windows 10, версия 1803
Windows 10, версия 1809
Windows Server 2019

18 июня 2019 г.

Обязательно: для клиентов, использующих WSUS 3.0 SP2, к этой дате необходимо вручную установить KB4484071 для поддержки обновлений SHA-2.

9 июля 2019 г.

Обязательно: для обновлений устаревших версий Windows потребуется установить поддержку подписи кода SHA-2. Поддержка, выпущенная в апреле и мае (KB4493730 и KB4474419), потребуется, чтобы продолжать получать обновления для этих версий Windows.

В настоящее время сигнатуры всех устаревших обновлений Windows изменены с SHA1 и двойной подписи (SHA-1/SHA-2) на SHA-2.

Windows Server 2008 SP2

16 июля 2019 г.

Windows 10, версия 1507
Windows 10, версия 1607
Windows Server 2016
Windows 10, версия 1703

13 августа 2019 г.

Обязательно: для обновлений устаревших версий Windows потребуется установить поддержку подписи кода SHA-2. Поддержка, выпущенная в марте (KB4474419 и KB4490628), потребуется, чтобы продолжать получать обновления для этих версий Windows. Если у вас есть устройство или виртуальная машина, использующая загрузку EFI, ознакомьтесь с разделом часто задаваемых вопросов, чтобы узнать о дополнительных действиях по предотвращению проблемы, из-за которой ваше устройство может не запускаться.

Сигнатуры всех устаревших обновлений Windows изменены с SHA-1 и двойной подписи (SHA-1/SHA-2) на SHA-2 только в настоящее время.

Windows 7 с пакетом обновления 1
Windows Server 2008 R2 с пакетом обновления 1

10 сентября 2019 г.

Устаревшие подписи обновлений Windows изменены с двойной подписи (SHA-1/SHA-2) на только SHA-2. Никаких действий со стороны клиента не требуется.

Windows Server 2012
Windows 8.1
Windows Server 2012 R2

10 сентября 2019 г.

Выпущено повторное автономное обновление безопасности KB4474419, в которое добавлены отсутствующие диспетчеры загрузки EFI. Убедитесь, что эта версия установлена.

Windows 7 SP1
Windows Server 2008 R2 SP1
Windows Server 2008 SP2

28 января 2020 г.

Подписи в списках доверия сертификатов (CTL) для программы Microsoft Trusted Root изменены с двойной подписи (SHA-1/SHA-2) на только SHA-2. Никаких действий со стороны клиента не требуется.

Все поддерживаемые платформы Windows

Август 2020 г.

Конечные точки службы Центра обновления Windows на основе SHA-1 больше не поддерживаются. Это влияет только на старые устройства Windows, на которые не были установлены соответствующие обновления безопасности. Дополнительные сведения см. в статье KB4569557.

Windows 7
Windows 7 SP1
Windows Server 2008
Windows Server 2008 SP2
Windows Server 2008 R2
Windows Server 2008 R2 SP1

3 августа 2020 г.

Майкрософт удалил из Центра загрузки Майкрософт контент, подписанный Windows для алгоритма безопасного хеширования 1 (SHA-1). Дополнительные сведения см. в блоге ИТ-специалистов по Windows SHA-1. Содержимое Windows будет удалено 3 августа 2020 года.

Windows Server 2000
Windows XP
Windows Server 2003
Windows Vista
Windows Server 2008
Windows 7
Windows Server 2008 R2
Windows 8
Windows Server 2012
Windows 8.1
Windows Server 2012 R2
Windows 10
Windows 10 Server

Текущий статус

Windows 7 с пакетом обновления 1 (SP1) и Windows Server 2008 R2 с пакетом обновления 1 (SP1)

Перед установкой любого обновления, выпущенного 13 августа 2019 года или более поздней версии, необходимо установить следующие обязательные обновления, а затем перезапустить устройство. Требуемые обновления можно устанавливать в любом порядке, и их не нужно переустанавливать, если только нет новой версии требуемого обновления.

Обновление стека обслуживания (SSU) (KB4490628). Если вы используете Центр обновления Windows, требуемый SSU будет предложен вам автоматически.

Обновление SHA-2 (KB4474419), выпущенное 10 сентября 2019 г. Если вы используете Центр обновления Windows, необходимое обновление SHA-2 будет предложено вам автоматически.

Важно! Необходимо перезагрузить устройство после установки всех необходимых обновлений, перед установкой ежемесячного накопительного пакета, обновления только для системы безопасности, предварительной версии ежемесячного накопительного пакета или отдельного обновления.

Windows Server 2008 SP2

Перед установкой любого накопительного пакета, выпущенного 10 сентября 2019 г. или более поздней версии, необходимо установить следующие обновления, а затем перезапустить устройство. Требуемые обновления можно устанавливать в любом порядке, и их не нужно переустанавливать, если только нет новой версии требуемого обновления.

Обновление стека обслуживания (SSU) (KB4493730). Если вы используете Центр обновления Windows, необходимое обновление SSU будет предложено вам автоматически.

Последнее обновление SHA-2 (KB4474419), выпущенное 10 сентября 2019 г. Если вы используете Центр обновления Windows, необходимое обновление SHA-2 будет предложено вам автоматически.

Часто задаваемые вопросы

Общая информация, планирование и предотвращение проблем

<р>1. Чем обновления для KB3033929 и KB4039648 отличаются от отдельных обновлений, выпущенных в марте и апреле?

Поддержка подписи кода SHA-2 была предоставлена заранее, чтобы гарантировать, что большинство клиентов получат поддержку задолго до того, как корпорация Майкрософт перейдет на подписывание SHA-2 для обновлений этих систем. Автономные обновления включают в себя некоторые дополнительные исправления и доступны, чтобы гарантировать, что все обновления SHA-2 находятся в небольшом количестве легко идентифицируемых обновлений. Корпорация Майкрософт рекомендует клиентам, поддерживающим образы систем для этих ОС, применять эти обновления к образам.

Начиная с WSUS 4.0 в Windows Server 2012, WSUS уже поддерживает обновления, подписанные SHA-2, и для этих версий не требуется никаких действий со стороны клиента.

Только для WSUS 3.0 SP2 требуется установка KB4484071 для поддержки обновлений, подписанных только SHA2.

<р>3. У меня есть система Windows Server 2008 SP2, которая выполняет двойную загрузку с Windows Server 2008 R2 (или Windows 7). Как обновить поддержку SHA-2?

Предположим, вы используете Windows Server 2008 SP2. Если вы используете двойную загрузку с Windows Server 2008 R2 SP1/Windows 7 SP1, диспетчер загрузки для этого типа системы будет из системы Windows Server 2008 R2/Windows 7. Чтобы успешно обновить обе эти системы для использования поддержки SHA-2, необходимо сначала обновить систему Windows Server 2008 R2/Windows 7, чтобы диспетчер загрузки был обновлен до версии, поддерживающей SHA-2. Затем обновите систему Windows Server 2008 SP2 с поддержкой SHA-2.

<р>4.У меня есть система с двумя разделами, один с Windows Server 2008 SP2, а второй с загрузочной средой Windows 7 PE (WinPE). Как перейти на поддержку SHA-2?

Как и в случае с двойной загрузкой, среда Windows 7 PE должна быть обновлена до поддержки SHA-2. Затем необходимо обновить систему Windows Server 2008 SP2 до поддержки SHA-2.

<р>5. Я использую программу установки для чистой установки Windows 7 с пакетом обновления 1 (SP1) или Windows Server 2008 R2 с пакетом обновления 1 (SP1). Я использую образ, настроенный с помощью обновлений (например, с помощью dism.exe). Как перейти на поддержку SHA-2?

Выполните установку Windows до конца и загрузитесь в Windows перед установкой обновлений от 13 августа 2019 г. или более поздних версий

Откройте окно командной строки администратора, запустите bcdboot.exe. Это копирует загрузочные файлы из каталога Windows и настраивает загрузочную среду. Дополнительные сведения см. в разделе Параметры командной строки BCDBoot.

Перед установкой каких-либо дополнительных обновлений установите перевыпуск KB4474419 и KB4490628 от 13 августа 2019 г. для Windows 7 с пакетом обновления 1 (SP1) и Windows Server 2008 R2 с пакетом обновления 1 (SP1).

Перезагрузите операционную систему. Требуется перезагрузка

Установите все оставшиеся обновления.

<р>6. Я устанавливаю образ Windows 7 с пакетом обновления 1 (SP1) или Windows Server 2008 R2 с пакетом обновления 1 (SP1) непосредственно на диск без запуска программы установки. Как заставить этот сценарий работать?

Установите образ на диск и загрузитесь в Windows.

В командной строке запустите bcdboot.exe. Это копирует загрузочные файлы из каталога Windows и настраивает загрузочную среду. Дополнительные сведения см. в разделе Параметры командной строки BCDBoot.

Перед установкой каких-либо дополнительных обновлений установите перевыпуск KB4474419 и KB4490628 от 23 сентября 2019 г. для Windows 7 с пакетом обновления 1 (SP1) и Windows Server 2008 R2 с пакетом обновления 1 (SP1).

Перезагрузите операционную систему. Требуется перезагрузка

Установите все оставшиеся обновления.

<р>7. Поддерживается ли мое устройство x64 или виртуальная машина, использующая загрузку EFI, этим обновлением SHA-2 для Windows 7 с пакетом обновления 1 (SP1) и Windows Server 2008 R2 с пакетом обновления 1 (SP1)?

Да, перед продолжением необходимо установить необходимые обновления: обновление SSU (KB4490628) и SHA-2 (KB4474419). Кроме того, вам необходимо перезагрузить устройство после установки необходимых обновлений, прежде чем устанавливать какие-либо дальнейшие обновления.

<р>8. Windows 10 версии 1903 не указана в таблице выше, поддерживает ли она обновления SHA-2? Требуются ли какие-либо действия?

Windows 10 версии 1903 поддерживает SHA-2 с момента ее выпуска, и все обновления уже подписаны только SHA-2. Для этой версии Windows не требуется никаких действий.

<р>9. Я устанавливаю обновления в онлайновую (работающую) систему, используя dism.exe /online. Как заставить этот сценарий работать?

Windows 7 с пакетом обновления 1 (SP1) и Windows Server 2008 R2 с пакетом обновления 1 (SP1)

Загрузитесь в Windows перед установкой любых обновлений от 13 августа 2019 г. или более поздних версий.

Перед установкой любых дополнительных обновлений установите перевыпуск KB4474419 и KB4490628 от 23 сентября 2019 г. для Windows 7 с пакетом обновления 1 (SP1) и Windows Server 2008 R2 с пакетом обновления 1 (SP1).

Перезагрузите операционную систему. Требуется перезагрузка

Установите все оставшиеся обновления.

Windows Server 2008 SP2

Загрузитесь в Windows перед установкой любых обновлений от 9 июля 2019 г. или более поздних версий.

Перед установкой каких-либо дополнительных обновлений установите перевыпуск KB4474419 и KB4493730 для Windows Server 2008 SP2 от 23 сентября 2019 года.

Перезагрузите операционную систему. Требуется перезагрузка

Установите все оставшиеся обновления.

Устранение неполадок

<р>1. Мое устройство x86 или x64 или виртуальная машина (ВМ) не запускается, и я получаю сообщение об ошибке 0xc0000428 (STATUS_INVALID_IMAGE_HASH), или мое устройство запускается в среду восстановления при перезапуске после установки обновлений, выпущенных 13 августа 2019 г. или позже. Я установил KB4474419 и KB4490628, чтобы включить поддержку SHA-2. Как восстановить установку?

Если вы видите ошибку 0xc0000428 с сообщением «Windows не может проверить цифровую подпись для этого файла. Недавнее изменение оборудования или программного обеспечения могло привести к установке файла с неправильной подписью или повреждения, либо это могло быть вредоносное ПО из неизвестного источника». выполните следующие действия для восстановления.

Запустите операционную систему с помощью носителя для восстановления.

Перед установкой каких-либо дополнительных обновлений установите обновление KB4474419 от 23 сентября 2019 г. или более поздней даты с помощью системы обслуживания образов развертывания и управления ими (DISM) для Windows 7 с пакетом обновления 1 (SP1) и Windows Server 2008 R2 с пакетом обновления 1 (SP1).

Перезагрузите операционную систему.

<р>2. Я развернул накопительное обновление для всех устройств или виртуальных машин (ВМ) в своей среде, и после перезапуска я получаю сообщение об ошибке 0xc0000428 (STATUS_INVALID_IMAGE_HASH) или мое устройство запускается в среду восстановления. Что мне делать с оставшимися устройствами или ВМ, которые еще не были перезапущены?

Остановите развертывание на других устройствах и не перезапускайте устройства или виртуальные машины, которые еще не были перезапущены.

Определите устройства и ВМ в состоянии ожидания перезапуска с обновлениями, выпущенными 13 августа 2019 г. или позже, и откройте командную строку с повышенными привилегиями

Найдите идентификатор пакета для обновления, которое вы хотите удалить, с помощью следующей команды, используя номер базы знаний для этого обновления (замените 4512506 номером базы знаний, на который вы ориентируетесь, если это не Ежемесячный накопительный пакет, выпущенный 13 августа 2019 г.) : dism/online/get-packages | найти 4512506

Используйте следующую команду, чтобы удалить обновление, заменив его тем, что было найдено в предыдущей команде: Dism.exe /online /remove-package /packagename:

Теперь вам нужно установить необходимые обновления, перечисленные в разделе Как получить это обновление обновления, которое вы пытаетесь установить, или необходимые обновления, перечисленные выше в разделе Текущее состояние этой статьи.

Примечание. Любое устройство или виртуальная машина, на которых вы в настоящее время получаете сообщение об ошибке 0xc0000428 или запускаете среду восстановления, вам необходимо выполнить действия, описанные в разделе часто задаваемых вопросов об ошибке 0xc0000428.

<р>3. Что делать, если я получаю код ошибки 80096010 или код ошибки 80092004 (CRYPT_E_NOT_FOUND), «Центр обновления Windows обнаружил неизвестную ошибку» при попытке установить обновление для Windows 7 с пакетом обновления 1, Windows Server 2008 R2 с пакетом обновления 1 или Windows Server 2008 с пакетом обновления 2?< /p>

Если вы столкнулись с этими ошибками, вам необходимо установить необходимые обновления, перечисленные в разделе Как получить это обновление обновления, которое вы пытаетесь установить, или необходимые обновления, перечисленные выше в разделе Текущее состояние этой статьи.< /p> <р>4. Мое устройство Intel Itanium IA64 не запускается, и я получаю сообщение об ошибке 0xc0000428 (STATUS_INVALID_IMAGE_HASH), но я установил KB4474419 и KB4490628. Как восстановить установку?

Запустите операционную систему с помощью носителя для восстановления.

Установите последнее обновление SHA-2 (KB4474419), выпущенное 13 августа 2019 года или позже, с помощью системы обслуживания образов развертывания и управления ими (DISM) для Windows 7 с пакетом обновления 1 (SP1) и Windows Server 2008 R2 с пакетом обновления 1 (SP1).

Перезагрузитесь с носителя для восстановления. Требуется перезагрузка

Перезагрузите операционную систему.

<р>5. После установки обновления SHA-2 (KB4474419), выпущенного 10 сентября 2019 г. для Windows Server 2008 SP2, я не могу вручную установить обновления, дважды щелкнув файл .msu, и получаю сообщение об ошибке «Установщик обнаружил ошибку: 0x80073afc . Загрузчику ресурсов не удалось найти файл MUI."

Если вы столкнулись с этой проблемой, вы можете решить эту проблему, открыв окно командной строки и выполнив следующую команду для установки обновления (замените заполнитель на фактическое местоположение и имя файла обновления):

Эта проблема устранена в KB4474419, выпущенном 8 октября 2019 г. Это обновление будет установлено автоматически из Центра обновления Windows и служб обновления Windows Server (WSUS). Если вам нужно установить это обновление вручную, вам нужно будет использовать обходной путь, описанный выше.

Примечание. Если вы ранее установили обновление KB4474419, выпущенное 23 сентября 2019 года, значит, у вас уже установлена последняя версия этого обновления, и вам не нужно переустанавливать его.

Перенос сертификатов SHA-1 в алгоритм хеширования SHA-2

Несмотря на то, что непосредственной опасности не существует, DigiCert настоятельно рекомендует администраторам перейти на SHA-2 как можно скорее.

Следующее руководство по миграции поможет администраторам спланировать и развернуть SSL-сертификаты SHA-2.

Этапы перехода с SHA-1 на SHA-2

1. Проверить среду на наличие поддержки сертификата SHA-2

Первый шаг — убедиться, что ваша среда, включая программное и аппаратное обеспечение, поддерживает сертификаты SHA-2. Список поддерживаемого оборудования и программного обеспечения см. на странице совместимости SHA-2.

Если часть вашей среды не будет поддерживать SHA-2, вы должны заменить или обновить эти части, прежде чем сможете внедрить новые сертификаты.

2. Найти все сертификаты SHA-1

Найдите все сертификаты SHA-1 в вашей сети, независимо от их эмитента, с помощью таких инструментов сканирования, как Discovery.

3. Создание новых CSR для каждого сертификата SHA-1

Создайте новые запросы на подпись сертификата (CSR) для любых сертификатов, все еще использующих SHA-1 на сервере, на котором они установлены.

DigiCert предоставляет полезные генераторы CSR для всех основных типов серверов, которые автоматизируют процесс создания CSR.Вы можете получить доступ к генераторам CSR DigiCert в разделе «Общие платформы и операционные системы» на странице «Создать CSR (запрос на подпись сертификата)».

4. Замена сертификатов SHA-1 сертификатами SHA-2

Чтобы заменить существующие сертификаты SHA-1 сертификатом SHA-2, вы можете повторно выпустить сертификат, обновить сертификат или приобрести новый сертификат.

5. Установите новые сертификаты SHA-2

После получения новых сертификатов установите их в своей сети вместе со всеми необходимыми промежуточными сертификатами.

Раздел поддержки на веб-сайте DigiCert содержит огромную коллекцию статей поддержки, в которых вы найдете ответы на любые вопросы об установке сертификатов в вашей среде.

Если вы используете DigiCert® Certificate Utility для Windows, вы можете использовать нашу инновационную функцию экспресс-установки, которая автоматизирует этот процесс, помогая установить сертификат всего несколькими щелчками мыши. См. Инструкции по импорту SSL-сертификата: утилита сертификатов DigiCert® для Windows.

6. Тестовая установка сертификата

Последний шаг — протестировать веб-сайт и убедиться, что сертификаты установлены и работают правильно. Вы можете использовать бесплатное средство диагностики установки DigiCert SSL для поиска проблем. Вы также можете использовать обнаружение, чтобы убедиться, что вы не создали другие потенциальные уязвимости в зависимости от того, как вы настроили сертификаты.

Бесплатная замена сертификатов SHA-1

DigiCert понимает, что переход на SHA-2 может быть трудным, особенно если вы не планировали переход в ближайшее время. Чтобы максимально упростить перенос сертификатов SHA-1, мы сделали ряд бесплатных опций.

Чтобы перейти на SHA-2:

Вы можете переиздать, расширить или заменить. Сертификаты DigiCert выпускаются с неограниченным количеством бесплатных повторных выпусков, поэтому вы можете легко заменить свой сертификат SHA-1 сертификатом SHA-2.

Чтобы перевыпустить любые текущие сертификаты DigiCert:

Вы можете войти в свою учетную запись клиента DigiCert и, находясь в ней, следовать инструкциям по повторному выпуску SSL-сертификата DigiCert®.

Чтобы обновить текущие сертификаты DigiCert:

Клиенты DigiCert также могут обновить существующий сертификат, чтобы получить SHA-2. За 90 дней до истечения срока действия сертификата в вашей учетной записи клиента DigiCert появляется кнопка продления, с помощью которой можно продлить сертификат.

Сертификаты, отличные от DigiCert:

Для сертификатов, отличных от DigiCert, вы можете отказаться от существующего сертификата SHA-1 и перейти на сертификат DigiCert SHA-2 бесплатно.

Шифрование SHA-2: поэтапный отказ от SHA-1

Корпорация Майкрософт прекратила использование алгоритма безопасного хеширования 1 (SHA-1) для проверки подлинности и целостности исполняемых файлов и сетевых соединений в Windows. Это часть долгосрочной отраслевой инициативы по отказу от использования SHA-1 в пользу более безопасного алгоритма SHA-2. NIST объявил устаревшим использование SHA-1 в 2011 году. Поддержка SHA-2 была добавлена в Windows Server 2012 и Windows 7.

По состоянию на 2020 год были продемонстрированы новые атаки, способные полностью взломать SHA-1. В ответ Microsoft выпустила исправления безопасности, которые задним числом добавляют поддержку SHA-2 в Windows Server 2008 и Windows Server 2008 R2.

SHA-1 в этих операционных системах. Это имеет важные последствия для обратной совместимости (см. ниже).

U-Move 2.7 — последняя версия, поддерживающая SHA-1

Microsoft объявила, что больше не будет выпускать сертификаты для подписи кода Authenticode, которые используют цифровые подписи SHA-1 и SHA-2 для перекрестной подписи для новых приложений Windows. Это предотвратит установку новых версий U-Move в старых операционных системах, не поддерживающих SHA-2. Сюда входят Windows Server 2003 и Windows Server 2003 R2. Это также предотвратит установку U-Move на Windows Server 2008 и Windows Server 2008 R2 без KB4490628 и KB4474419.

В дальнейшем U-Move 2.8+ будет поддерживать только SHA-2 . Список совместимых операционных систем см. в разделе Совместимость.

Шифрование SHA-2 для подписей билетов Kerberos KDC в Active Directory

Корпорация Майкрософт обновила Active Directory с помощью алгоритма SHA-2 для защиты билетов службы Kerberos, выданных центром распространения ключей (KDC) для ограниченного делегирования (KB4598347). Это затронет старые контроллеры домена, которые не поддерживают SHA-2 .

Microsoft объявила, что ограниченное делегирование с неподдерживаемых контроллеров домена больше не будет работать на поддерживаемых контроллерах домена. U-Move предупредит вас, если обнаружит такую ситуацию. См. раздел Подписи билетов KDC в справке U-Move.

Как обновить Windows Server 2008 и Windows Server 2008 R2 для SHA-2

Microsoft опубликовала обновления для Windows Server 2008 и Windows Server 2008 R2, чтобы задним числом добавить поддержку SHA-2. (Обновления также применимы к Windows 7.) Исходное объявление см. в разделе Требование поддержки подписи кода SHA-2 2019 для Windows и WSUS.Дополнительная информация была опубликована в обновлении поддержки подписи кода SHA-2 для Windows Server 2008 R2, Windows 7 и Windows Server 2008: 23 сентября 2019 г. (KB4474419).

Расширенные обновления безопасности

Активация ключа продукта Windows для Windows Server 2008 и Windows Server 2008 R2

Вам потребуется применить обновления SHA-2, чтобы успешно активировать ключ продукта Windows (WPK) после клонирования AD.

Читайте также: