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

67

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

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

ssl ssl-certificate certificate-authority

— 131
источник

9

Это не правда, что «все» корневые сертификаты CA являются SHA1.

— Грег Аскью

5

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

— Рой Тинкер

@RoyTinker за исключением cogito ergo sum (см. Радикальное сомнение и ответ: декартовый скептицизм )?

— Ник Т

1

Кросс-стек: security.stackexchange.com/questions/120301/… и superuser.com/questions/1122069/…

— dave_thompson_085

6

@NickT: Берегите себя - cogito ergo cogito ;-)

— tonysdg

106

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

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

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

— user2233709
источник

3

Возникает вопрос, почему они вообще подписаны

— Ричард Тингл,

42

Потому что система не поддерживает сертификаты, которые не подписаны.

— Стоп Harm Monica

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

— Деви Морган,

20

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

— Йорг Миттаг,

13

@DewiMorgan Вы не можете «взломать» корневой сертификат с помощью коллизии хеша, потому что клиент доверяет самому сертификату , а не его (собственной) подписи. Вам придется восстановить закрытый ключ, который является атакой на RSA, а не на алгоритм хеширования.

— Звол

46

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

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

— Марк Хендерсон
источник

2

Не говоря уже о том, что обновление корневого сертификата требует повторного прохождения этого внеполосного процесса.

— Кайтар

4

+1 за «якобы, надеюсь»

— Натан Осман

6

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

— joshudson
источник

1

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

— Питер Олерт

1

Как примечание к этому, некоторые CA уже обновили свои корневые и промежуточные сертификаты до SHA256.

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

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

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

— B.Kaatz
источник

0

Для корневого ЦС вы доверяете открытому ключу ЦС, включенному в ЭЛТ, независимо от его собственной подписи.

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

— 131
источник

-1

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

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

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

— RJT
источник

Это совершенно неправильно. Промежуточные сертификаты (и сертификаты EE./leaf) требуют SHA2, а корни - нет. Собственная цепочка сертификатов от Google через свой частный CA (Google Internet Authority G3) переходит к GlobalSign Root CA R2 - SHA1 - и (что неудивительно) принимается Chrome.

— dave_thompson_085

Да, эти закрепленные сертификаты SHA1 принимаются, но не новые корневые сертификаты SHA1, даже если вы добавляете их в свое хранилище доверенных корневых сертификатов. Добавил тестовый пример в мой ответ.

— RJT