Как ROOT CA проверяет подпись?

Ответ 1

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

Весь контейнер подписан доверенным центром сертификации (= CA). У CA также есть пара секретный/открытый ключ. Вы даете им свой сертификат, они проверяют правильность информации в контейнере (например, является ли контактная информация правильной, действительно ли этот сертификат принадлежит этому серверу) и, наконец, подписываете его своим закрытым ключом. Открытый ключ CA должен быть установлен в пользовательской системе. Наиболее известные сертификаты CA уже включены в установку по умолчанию вашей любимой ОС или браузера.

Когда теперь пользователь подключается к вашему серверу, ваш сервер использует закрытый ключ для подписи случайных данных, упаковывает подписанные данные вместе со своим сертификатом (= открытый ключ + метаинформация) и отправляет все клиенту. Что клиент может сделать с этой информацией?

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

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

Поэтому после проверки подписанных данных (или перед их проверкой) клиент проверяет, что полученный сертификат имеет действительную подпись CA. Используя уже установленный открытый ключ CA, он проверяет, что полученный открытый ключ был подписан известным и, мы надеемся, доверенным CA. Сертификат, который не подписан, по умолчанию не является доверенным. Пользователь должен явно доверять этому сертификату в своем браузере.

Наконец, он проверяет информацию в самом сертификате. Действительно ли IP-адрес или доменное имя соответствуют IP-адресу или доменному имени сервера, с которым клиент сейчас общается? Если нет, то что-то подозрительно!

Люди могут задаться вопросом: что мешает хакеру просто создать свою собственную пару ключей и просто вставить свое доменное имя или IP-адрес в свой сертификат и затем подписать его ЦС? Простой ответ: если он это сделает, ни один СА не подпишет свой сертификат. Чтобы получить подпись CA, вы должны доказать, что вы действительно являетесь владельцем этого IP-адреса или доменного имени. Хакер не является владельцем, поэтому он не может доказать это, и поэтому он не получит подпись.

Но что, если хакер зарегистрирует свой собственный домен, создаст для этого сертификат и будет подписан центром сертификации? Это работает, он получит CA подписанный, это его домен в конце концов. Однако он не может использовать его для взлома вашего соединения. Если он использует этот сертификат, браузер сразу увидит, что подписанный открытый ключ предназначен для домена example.net, но в настоящее время он обращается к домену example.com, а не к тому же домену, поэтому что-то снова не так.

Ответ 2

Сертификат сервера подписывается закрытым ключом CA. Браузер использует открытый ключ CA для проверки подписи. Нет прямой связи между браузером и CA.

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

Если вы этого не понимаете, поищите основы асимметричной криптографии и цифровых подписей.

Ответ 3

Сертификаты основаны на использовании асимметричного шифрования, такого как RSA. У вас есть два ключа, обычно называемые частными и открытыми ключами. То, что вы шифруете с помощью закрытого ключа, может быть расшифровано только с помощью открытого ключа. (И, наоборот, наоборот.)

Вы можете думать о сертификате как о паспортной или водительской лицензии: это удостоверение, в котором говорится: "Это кто я, вы можете доверять ему, потому что он был предоставлен мне кем-то (например, Verisign), которому вы доверяете". Это делается с помощью "подписи", которая может быть вычислена с использованием открытого ключа центра сертификации. Если данные - это то, что первоначально получил ЦС, вы можете проверить сертификат.

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

Ответ 4

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

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

CACert.org имеет эту же проблему, имеет действующие сертификаты, но поскольку браузеры не имеют своих корневых сертификатов в своем списке, их сертификаты генерируют предупреждения до тех пор, пока пользователи не загрузят корневой ЦС и не добавят их в свой браузер.