Назад | Перейти на главную страницу

Почему все корневые сертификаты ЦС подписаны SHA-1 (поскольку SHA-1 устарел)?

Я понимаю, что сертификаты SSL больше не могут быть подписаны с использованием SHA-1. Тем не менее, все корневые сертификаты CA подписаны SHA-1 (в основном). Означает ли это, что тот же алгоритм, которому больше не доверяют для «бабушкиного магазина SSL», подходит для самого надежного сертификата в мире?

Я что-то упускаю? (использование ключа? размер ключа?)

Подпись корневых сертификатов ЦС вообще не имеет значения, так как нет необходимости их проверять. Все они самоподписаны.

Если вы доверяете сертификату корневого ЦС, нет необходимости проверять его подпись. Если вы ему не доверяете, его подпись для вас ничего не стоит.

Изменить: ниже есть несколько очень важных комментариев. Мне неудобно копировать или перефразировать их и отдавать должное им, а не их авторам. Но я приветствую людей, которые добавляют пояснения к этому ответу.

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

Эти сертификаты (и компании, которые сами подписали их) (как предполагается, будем надеяться) тщательно проверяются другими способами, помимо их подписей.

Единственный случай, когда это имеет значение, - если корень подписан с помощью SHA-1, он может быть отозван с помощью SHA-1. То есть кто-то, кто может атаковать SHA-1, может создать аннулирование для корня. И я абсолютно уверен, что браузер не знает, как это сделать, поэтому вандал не сделал ничего, кроме сброса SSL-соединений. Как хромает.

В качестве примечания к этому, НЕКОТОРЫЕ В любом случае центры сертификации уже обновили свои корневые и промежуточные сертификаты до SHA256.

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

Вы можете проверить, какие именно сертификаты были обновлены, а какие они обновлены, но также оставили здесь устаревший сертификат SHA1 => 1

Надеюсь, это поможет.

Для корневого CA вы доверяете открытому ключу CA, объединенному в CRT, независимо от его собственной подписи.

Описание CA с использованием формата файла .CRT вместо необработанного открытого ключа .PEM позволяет объединить в него более подробную информацию - например, Имя CA - (опять же, подпись ничего не стоит)

Есть очень старый, в основном 2006 года или ранее уже доверенные закрепленные корневые сертификаты SHA1, которые принимают браузеры, но не более новые сертификаты. Помните, когда версии Firefox и Chrome были однозначными?

Сертификаты не работают, если корневой ЦС использует сертификаты SHA1 с параметром «Не до», для которого установлено значение после 2014 года. Фактические ограничения по дате зависят от браузера или другого приложения. Кабфорум WebCA дал понять это несколько лет назад. Проверьте это сами:

  1. Создайте частную инфраструктуру корневого центра сертификации, подписанную с помощью SHA1, назовите ее rootSHA1
  2. Попросите rootSHA1 создать «выдающий» CA или «промежуточный» CA, который выдает сертификаты с сертификатом, связанным с корневым. Назовите это промежуточным SHA256.
  3. Попросите промежуточный центр сертификации SHA256 создать сертификаты, подписанные хешем sha256 или более высоким. Назовите его webServerSHA256.
  4. Установите webServerSHA256 на webServerSHA56.mydomain.com.
  5. Установите сертификаты rootSHA1, intermediateSHA256 и webServerSHA256 в соответствующие места в Google Chrome. Установите корень в доверенные корневые центры сертификации и другие с цепочкой сертификатов.
  6. Перейдите в Google Chrome к https://webServerSHA256.mydomain.com/ и убедитесь, что на webServerSHA256 нет зеленого замка. Тест не пройден.