Всякий раз, когда я пытаюсь что-то понять о SSL, мне всегда трудно отследить, что означают "ключ" и "сертификат". Я боюсь, что многие люди используют их неправильно или взаимозаменяемо. Есть ли стандартная разница между ключом и сертификатом?
7 ответов
90
Сертификат содержит открытый ключ.
Сертификат, помимо того, что он содержит открытый ключ, содержит дополнительную информацию, такую как издатель, для чего предполагается использовать сертификат, и другие типы метаданных.
Как правило, сертификат сам подписывается с помощью закрытого ключа, который проверяет его подлинность.
38
35
Допустим, компания A имеет пару ключей и должна опубликовать свой открытый ключ для публичного использования (он же ssl на своем веб-сайте).
- Компания A должна сделать запрос сертификата (CR) в центр сертификации (CA), чтобы получить сертификат для своей пары ключей.
- Открытый ключ, но не закрытый ключ, пары ключей компании А включен как часть запроса сертификата.
- CA затем использует идентификационную информацию компании A, чтобы определить, соответствует ли запрос критериям CA для выдачи сертификата.
Если CA подтверждает запрос, он выдает сертификат компании A. Вкратце CA подписывает открытый ключ компании A своим закрытым ключом (CA), который проверяет его подлинность.
Таким образом, открытый ключ компании A, подписанный действительным секретным ключом CA, называется сертификатом компании A.
4
Позвольте мне объяснить на примере.
В обычной PKI на основе пар ключей есть закрытый ключ и открытый ключ.
В системе на основе сертификатов есть закрытый ключ и сертификат. Сертификат содержит больше информации, чем открытый ключ.
Демо (Вы можете сгенерировать сертификат и закрытый ключ): http://www.selfsignedcertificate.com/
Вы можете скачать открыть файл закрытого ключа и файл сертификата, вы видите, что файл сертификата содержит много информации, как показано ниже.
Вы можете сопоставить сгенерированный сертификат (открытие текстовым редактором) и закрытый ключ (открытие текстовым редактором) с этого сайта: https://www.sslshopper.com/certificate-key-matcher.html
Если сертификат соответствует личному ключу клиента, клиент уверен, что сертификат выдан клиентом или доверенным агентом клиента (CA).
Однако существуют проблемы только в связи с закрытым ключом и сертификатом.
Потому что каждый может сгенерировать свой собственный сертификат и закрытый ключ, поэтому простое рукопожатие ничего не доказывает о сервере, кроме того, что сервер знает закрытый ключ, который соответствует открытому ключу сертификата. Одним из способов решения этой проблемы является предоставление клиенту набора из одного или нескольких сертификатов, которым он доверяет. Если сертификат не указан, серверу нельзя доверять.
У этого простого подхода есть несколько недостатков. Серверы должны иметь возможность обновляться до более надежных ключей с течением времени ("ротация ключей"), что заменяет открытый ключ в сертификате новым. К сожалению, теперь клиентское приложение должно быть обновлено из-за изменения конфигурации сервера. Это особенно проблематично, если сервер не находится под контролем разработчика приложения, например, если это сторонний веб-сервис. Этот подход также имеет проблемы, если приложение должно общаться с произвольными серверами, такими как веб-браузер или приложение электронной почты.
Чтобы устранить эти недостатки, серверы обычно настраиваются с помощью сертификатов от известных издателей, называемых центрами сертификации (CA). хост-платформа (клиент) обычно содержит список известных CA, которым она доверяет. Подобно серверу, CA имеет сертификат и закрытый ключ. При выдаче сертификата для сервера CA подписывает сертификат сервера, используя свой закрытый ключ. Затем клиент может проверить, что на сервере есть сертификат, выданный центром сертификации, известным платформе.
Тем не менее, при решении некоторых проблем использование CA вводит другую. Поскольку центр сертификации выдает сертификаты для многих серверов, вам все равно нужен какой-то способ убедиться, что вы общаетесь с нужным вам сервером. Чтобы решить эту проблему, сертификат, выданный ЦС, идентифицирует сервер либо с определенным именем, таким как gmail.com, либо с набором подстановочных знаков, например * .google.com.
Следующий пример сделает эти концепции немного более конкретными. В приведенном ниже фрагменте командной строки команда s_client инструмента openssl просматривает информацию о сертификатах сервера Википедии. Он указывает порт 443, потому что это по умолчанию для HTTPS. Команда отправляет выходные данные openssl s_client в openssl x509, который форматирует информацию о сертификатах в соответствии со стандартом X.509. В частности, команда запрашивает субъект, который содержит информацию об имени сервера, и издателя, который идентифицирует CA.
$ openssl s_client -connect wikipedia.org:443 | openssl x509 -noout -subject -issuer
subject= /serialNumber=sOrr2rKpMVP70Z6E9BT5reY008SJEdYv/C=US/O=*.wikipedia.org/OU=GT03314600/OU=See www.rapidssl.com/resources/cps (c)11/OU=Domain Control Validated - RapidSSL(R)/CN=*.wikipedia.org
issuer= /C=US/O=GeoTrust, Inc./CN=RapidSSL CA
Вы можете видеть, что сертификат был выдан для серверов, соответствующих * .wikipedia.org, RapidSSL CA.
Как видите, благодаря этой дополнительной информации, отправляемой ЦС на серверы, клиент может легко узнать, взаимодействует ли он со своим сервером или нет.
3
Сертификат SSL получен от доверенного центра сертификации, который гарантирует безопасное подключение к веб-сайту. Сертификаты SSL обычно содержат логотип аутентификации, а также открытые ключи, необходимые для шифрования и дешифрования данных, которые должны быть отправлены на компьютер. Функции ключей SSL
Несколько ключей SSL могут быть сгенерированы во время сеанса. Они используются для шифрования и дешифрования информации, передаваемой на компьютер и с компьютера.Ключи используются для проверки того, что информация не была изменена или подделана.
Разница в жизненном цикле
Сертификаты действуют дольше, чем ключи SSL. Сертификаты SSL получены от Удостоверяющего центра, который может регулярно обновляться банками и предприятиями. Ключи SSL или ключи сеанса, с другой стороны, уникальным образом генерируются во время сеанса и отбрасываются по окончании сеанса.
1
Хорошо, давайте разберемся с этим, чтобы не технические люди могли понять.
Думайте об этом так. Сертификат - это как сейф в вашем банке. Он содержит много важных вещей; как правило, вещи, которые содержат вашу личность. Сертификат имеет открытый ключ, и для его открытия необходим закрытый ключ.
Ваш сейф также открывает два ключа, как и сертификат.
В банковской ячейке ключ банка похож на открытый ключ, так как он остается в банке, а открытый ключ остается с сертификатом. У вас есть личный ключ, который необходим для "получения вашего сертификата", и в примере с сейфом ваш личный ключ необходим в дополнение к открытому ключу.
Прежде чем вы действительно сможете открыть свой сейф, вы должны сначала подтвердить свою личность (например, запрос на сертификат); как только вы были идентифицированы, вы используете свой закрытый ключ вместе с открытым ключом, чтобы открыть свой сейф. Это немного похоже на запрос вашего сертификата, а затем на получение сертификата от центра сертификации (если вы можете быть идентифицированы (доверены) и у вас есть правильный ключ).
-2
Связь между браузером и сервером
Рукопожатие:
- Клиент отправляет случайное число вместе с поддерживаемым шифрованием
- Сервер отправляет свой сертификат с поддерживаемым шифрованием. А клиент случайных чисел зашифровывает свой закрытый ключ и отправляет обратно. Сертификат содержит открытый ключ. Эмитент сертификата или (CA), срок действия и т.д.
- Клиент Проверяет сертификат, отправленный сервером.
Все ПК поставляются со списком CA, которому они доверяют, например, VeriSign или DigiCert. Это ROOT CA. Все корневые CA являются самоподписанными. Чтобы понять. Это как если я доверяю серверу A и сервер A знает сервер B, то сервер A может поручиться, что это сервер B, кем он себя называет. И способ сервера Vouch заключается в предоставлении сертификата серверу B. Этот сертификат на самом деле подписан секретным ключом CA в нашем случае, сервером A. публичная подпись которого уже есть на нашем ПК, с помощью которого я могу проверить подлинность сертификата, предоставленного Сервер Б.
Клиент проверяет сообщение или случайное число, которое он отправил ранее, с помощью открытого ключа (полученного в сертификате).
Теперь клиент проверяет, является ли сертификат действительным, отправив запрос OCSP и проверив в БД CRL.
Теперь, если сертификат не был отозван, будет установлена пара сеансовых ключей, с помощью которых устанавливается туннель шифрования, теперь весь трафик шифруется.
Все запросы CSR подписаны промежуточными сертификатами, а не корневым центром сертификации, чтобы сохранить целостность корневого центра сертификации, чтобы они не были скомпрометированы.