Принимая эти вопросы за вопросом:
(1) «Мой интернет-магазин» как компания должна быть
«Сертифицирован» в какой-либо третьей стороне CA.
Это означает, что мне нужно купить какой-то
1 год членства в этом CA, и
Затем они зарегистрируют «Мой интернет-магазин».
в их системах и выдать мне некоторые
такие вещи, как сертификат и пара
уникальных открытых и закрытых ключей.
Получу ли я файл сертификата?
Да. Кроме того, это варьируется от ЦС к ЦС - некоторые ЦС, членство на 1 год и действующая кредитная карта достаточно (не трудно получить, даже если вы являетесь группой из них), некоторые ЦС требуют определенного количества документов чтобы убедиться, что вы тот, кем вы говорите. ЦС хорош только настолько, насколько хорош процесс проверки клиента, поэтому, как правило, чем более обременителен этот процесс, тем лучше (и дороже) ЦС.
Когда вы заплатите свои деньги и сделаете документы, тогда вы и ЦС сгенерируете как минимум 2 вещи:
- Пара открытых / закрытых ключей. Часто это генерируется ВАМИ, а не ЦС. Качество того, как вы сгенерировали и сохранили свою пару ключей, также является фактором, определяющим, насколько другая организация может доверять вашему веб-сайту. Как правило, для сертификатов идентификации (например, сертификатов сервера SSL) рекомендуется, чтобы клиент (My e-Shop) генерировал ключ.
- Вы отправите запрос на сертификат в стандартном формате (пример: PKCS10) в ЦС. Он будет содержать информацию о моем интернет-магазине и открытый ключ.
- Компания CA проверит ваши документы и удостоверится, что вы - это вы. Затем он будет использовать свой CA для цифровой подписи сертификата для вас. Этот сертификат содержит набор только что предоставленной вами информации, некоторую дополнительную информацию, которую поставщик CA устанавливает для вас, ваш открытый ключ и цифровую подпись, сгенерированную путем криптографического связывания всех вышеупомянутых данных с закрытым ключом CA.
Вы получаете одну из двух вещей:
- только сертификат (если вы сгенерировали собственную пару ключей)
- сертификат и пара ключей - если ЦС сгенерировал пару ключей для вас
(2) выданный сертификат заполнен моим
информация и открытый ключ и хранятся в
какой-то файл на моем веб-сервере.
сертификат подтверждает, что «мой
Интернет-магазин »- это не воровское бюро.
да ... вроде. Вашему веб-серверу понадобится как подписанный сертификат, так и пара ключей. Пара ключей используется как часть рукопожатия SSL для конечного пользователя, и этот обмен доказывает, что вы владеете парой ключей, а не какой-то группой тех, кто получил в руки сертификат. Вот почему вы хотите защитить пару ключей.
(3) Каждый раз, когда пользователи заходят в «Мой интернет-магазин»
через «https» их браузеры
«Молча» проверяет представленное
сертификат «Мой интернет-магазин» с
тот, который зарегистрирован в CA.
Для некоторого определения "молчать". Базовый браузер проверяет, что сертификат:
- в настоящее время действует
- подписан центром сертификации, которому доверяет браузер (либо он запрещает доступ, либо выдает всплывающее окно)
Надстройки браузера пойдут дальше и будут выполнять такие вещи, как проверка полного пути (вплоть до самозаверяющего корня) и проверка состояния сертификата. Чем выше риск распространения информации по каналу, тем больше нужно проверять.
(4) Когда какой-либо пользователь входит в «Мой интернет-магазин»
через https происходит следующее: «Мой
Интернет-магазин »(веб-сервер) получает общественность
ключ (PK1) пользователя. Сервер
молча вручает сертификат
«Мой интернет-магазин» для пользователя, поэтому
пользователи получают открытый ключ (PK2)
«Мой интернет-магазин». После некоторого молчания
проверка браузера пользователя
проверяет представленный сертификат и
установлена безопасная труба.
- А как насчет пользователей? У своих браузеров родылокальные открытые + закрытые ключи при входе в «Мой интернет-магазин» через https?
ОК - здесь все идет не так.
Для получения подробной информации, проверьте протокол SSL - раздел рукопожатия даст вам серьезные факты.
браузер и веб-сервер передают информацию туда и обратно, что позволяет им создавать ключ шифрования сеанса.Браузер генерирует некоторый исходный материал, используемый для настройки сеанса, но это не «открытый ключ пользователя (PK1)».Пользователю не нужно иметь учетные данные PKI, ЕСЛИ сервер не настроен для аутентификации клиента.При обычном запуске мельницы My e-Shop у сервера есть учетные данные PKI, браузер на лету генерирует какой-то ключевой материал только для одного сеанса.Сервер абсолютно не знает, кто пользователь браузера, с точки зрения SSL - вся идентификация пользователя происходит из пароля или чего-то еще на уровне приложения.
ПРИМЕЧАНИЕ. Это для обычной коммерческой транзакции.Чем выше риск, тем выше защита.Транзакции с высоким риском часто требуют аутентификации клиента.
(5) Когда пользователь отправляет запрос через защищенный канал, запросы шифруются открытым ключом «Мой интернет-магазин».Затем веб-сервер расшифровывает запрос с помощью своего закрытого ключа.Затем веб-сервер отправляет зашифрованный ответ с открытым ключом пользователя.В конце браузер пользователя расшифровывает ответ своим закрытым ключом.
Не совсем.Это и есть сорняки - разработчик веб-приложения относительно абстрагируется от всего этого.Но - содержимое сеанса не зашифровано асимметричными ключами - это будет мучительно загружать процессор.PKI сервера и данные квитирования, генерируемые браузером «на лету», используются для обмена ключом шифрования сеанса.Частично это то, что клиент выбирает и отправляет секретный ключ, зашифрованный в открытом ключе сервера.Поскольку только сервер имеет закрытый ключ, только сервер может дешифровать данные, отправленные клиентом.
Этот секретный ключ является симметричным (именно этот алгоритм также является частью квитирования) и используется для оставшейся частисеанс.