Why are CA root certificates all SHA-1 signed (since SHA-1 is deprecated)?
I understand that SSL certs cannot be signed using SHA-1 anymore. Yet, all CA root certificates are SHA-1 signed (mostly). Does it mean the same algorithm that is no longer trusted for "you grandma SSL shop" is fine for the uttermost top secured certificate of the world?
Am I missing something? (key usage? key size?)
Подпись сертификатов корневого CA не имеет никакого значения, так как нет необходимости в их проверке. Все они являются самоподписными.
Если вы доверяете корневому сертификату CA, то нет необходимости проверять его подпись. Если вы не доверяете ему, то его подпись для вас ничего не стоит.
Правка: ниже приведены некоторые очень уместные комментарии. Мне неудобно их копировать или перефразировать и приписывать их авторам. Но я приветствую людей, которые добавят объяснения к этому ответу
.В конце дня корневой сертификат самоподписывается. Он никогда не подписывается другим субъектом, кроме самого себя. Корневой сертификат получает свое доверие через внеполосные процессы, такие как отправка его в список доверенных издателей браузеров, или получение его одобрения Microsoft для вставки в список доверенных издателей Windows по умолчанию.
Эти сертификаты (и компании, которые их самоподписали) (предположительно, надеюсь) тщательно проверяются с помощью других средств, кроме их подписей.
.Единственный случай, когда это имеет значение - если корень подписан SHA-1, то он может быть отозван SHA-1. То есть, кто-то, кто может атаковать SHA-1, может построить отзыв для корня. И я абсолютно уверен, что браузер не знает, как это сохранить, поэтому вандал совершил не более чем сброс SSL соединений. Какой отстой.
В качестве примечания к этому, SOME CA уже обновили свои корневые и промежуточные сертификаты до SHA256 в любом случае.
Я знаю, что в прошлом году GlobalSign обновляла свои сертификаты, так как мы обновляли наши сертификаты кодовой подписи, поэтому мне пришлось добавить к ним и их новую цепочку.
Вы можете проверить, какие именно сертификаты были обновлены, а какие обновлены, но также оставили старый сертификат SHA1 здесь => 1
Надеюсь, что это поможет.
Для корневого CA вы доверяете открытому ключу CA - встроенному в CRT - независимо от его собственной подписи.
Описание CA с использованием формата файла .CRT вместо необработанного открытого ключа .PEM позволяет вложить в него более подробную информацию - например, имя CA - (опять же, подпись ничего не стоит)
.Есть очень старые, в основном 2006 года или более ранней эпохи уже доверенные закрепленные корневые сертификаты SHA1, которые принимают браузеры, но не более новые сертификаты. Помните, когда версии Firefox и Chrome были однозначными?
Сертификаты не работают, если корневой ЦС использует сертификаты SHA1 с параметром «Не до», для которого установлено значение «после 2014 года». Фактические ограничения по дате зависят от браузера или другого приложения. Кабфорум WebCA дал понять это несколько лет назад. Проверьте это самостоятельно:
- Создайте частную инфраструктуру корневого центра сертификации, подписанную с помощью SHA1, назовите ее rootSHA1
- Попросите rootSHA1 создать «выдающий» ЦС или «промежуточный» ЦС, который выдает сертификаты с сертификатом, привязанным к корневому . Назовите его промежуточнымSHA256.
- Попросите CA, выпускающий промежуточныйSHA256, сгенерировать сертификаты, подписанные хешем sha256 или более высоким. Назовите его webServerSHA256.
- Установите webServerSHA256 на webServerSHA56.mydomain.com.
- Установите сертификаты rootSHA1, intermediateSHA256 и webServerSHA256 в соответствующие места в Google Chrome. Установите корень в доверенные корневые центры сертификации и другие с цепочкой сертификатов.
- Перейдите в Google Chrome на https://webServerSHA256.mydomain.com/ и убедитесь, что для webServerSHA256 нет зеленого замка. Тест не пройден.