В чем разница между сертификатом и ключом по отношению к SSL?

Сертификат содержит открытый ключ.

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

Обычно сертификат подписывается самим центром сертификации (ЦС) с использованием закрытого ключа ЦС. Это проверяет подлинность сертификата.

Эти две фотографии вместе объяснили мне все:

Source: linuxvoice

Источник: infosecinstitute

Допустим, у компании А есть пара ключей и она должна опубликовать свой публичный ключ для публичного использования (он же ssl на его веб-сайте).

• Компания А должна сделать запрос на сертификат (CR) в центр сертификации (CA), чтобы получить сертификат для своей пары ключей.
  
• Открытый ключ, но не частный ключ, пары ключей компании А включается в запрос на получение сертификата.
  
• Затем УЦ использует идентификационные данные компании А для определения соответствия запроса критериям УЦ для выдачи сертификата.
  Если УЦ одобряет запрос, то он выдает сертификат компании А. Коротко говоря, УЦ подписывает открытый ключ компании А своим личным ключом, который проверяет его подлинность.
  

Таким образом, публичный ключ компании А, подписанный действительным личным ключом УЦ, называется сертификатом компании А.

Позвольте мне объяснить на примере.

В нормальной паре ключей PKI, основанной на закрытом и открытом ключах, существуют закрытый и открытый ключи.

В системе, основанной на сертификатах, есть закрытый ключ и сертификат. Сертификат содержит больше информации, чем открытый ключ.

Демонстрация (Вы можете сгенерировать сертификат и закрытый ключ): http://www.selfsignedcertificate.com/

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

Вы можете сопоставить сгенерированный вами сертификат (открываемый текстовым редактором) и частный ключ (открываемый текстовым редактором) с этого сайта: https://www.sslshopper.com/certificate-key-matcher.html

Если сертификат соответствует личному ключу клиента, клиент уверен, что этот сертификат предоставлен клиентом или выдан доверенным агентом (CA) клиента.

Как бы то ни было, существуют проблемы только с личным ключом и взаимодействием на основе сертификатов.

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

Есть несколько недостатков этого простого подхода. Со временем серверы должны иметь возможность апгрейда до более сильных ключей (“ротация ключей”), которая заменяет публичный ключ в сертификате на новый. К сожалению, теперь клиентское приложение приходится обновлять из-за того, что по сути представляет собой изменение конфигурации сервера. Это особенно проблематично, если сервер не находится под контролем разработчика приложения, например, если это веб-служба стороннего производителя. Такой подход также имеет проблемы, если приложению приходится общаться с произвольными серверами, такими как веб-браузер или почтовое приложение.

Чтобы устранить эти недостатки, серверы обычно настраиваются с помощью сертификатов от известных эмитентов под названием Certificate Authorities (CAs). он хост-платформа (клиент) обычно содержит список хорошо известных CA, которым он доверяет. Подобно серверу, CA имеет сертификат и частный ключ. При выпуске сертификата для сервера, CA подписывает сертификат сервера, используя свой закрытый ключ. Затем клиент может проверить, что сервер имеет сертификат, выданный известным ему центром сертификации.

Однако при решении некоторых проблем использование CA приводит к появлению еще одной. Так как CA выпускает сертификаты для многих серверов, вам все равно нужен какой-то способ убедиться, что вы говорите с нужным вам сервером. Для решения этой проблемы сертификат, выданный центром сертификации, идентифицирует сервер либо с определенным именем, таким как gmail.com, либо с набором узлов подстановки, таких как *.google.com.

Следующий пример сделает эти понятия немного более конкретными. В фрагменте ниже из командной строки, команда openssl инструмент s_client смотрит на информацию о сертификатах сервера Википедии. Она указывает порт 443, потому что это порт по умолчанию для HTTPS. Команда отправляет вывод openssl s_client на openssl x509, который форматирует информацию о сертификатах в соответствии со стандартом X.509. В частности, команда запрашивает субъекта, который содержит информацию об имени сервера, и издателя, который идентифицирует ЦС.

$ 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

Вы можете видеть, что сертификат был выпущен RapidSSL CA для серверов, соответствующих *.wikipedia.org.

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

SSL сертификат получен от доверенного центра сертификации, который выдает ваучеры на безопасное соединение с веб-сайтом . SSL-сертификаты обычно содержат логотип аутентификации, а также открытые ключи, необходимые для шифрования и расшифровки данных, которые необходимо отправить на компьютер. Функции ключей SSL 0x2 и 0x2 и несколько ключей SSL** могут быть сгенерированы во время сеанса. Они используются для шифрования и расшифровки информации, отправляемой на компьютер и от компьютера.ключи используются для проверки того, что информация не была изменена или подделана.

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

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

Подумай об этом вот так. Сертификат - это как банковская ячейка в вашем банке. Он содержит много важных вещей; обычно вещи, которые содержат вашу личность. Сертификат имеет открытый ключ и для его открытия нужен частный ключ. 0x2 и 0x2 и Ваша банковская ячейка тоже требует два ключа для открытия, так же как и сертификат.
При использовании сейфа ключ банкира подобен открытому ключу, так как он остается в банке, а открытый ключ - с сертификатом. У вас есть личный ключ, который необходим для “получения сертификата”, а в примере с банковской ячейкой помимо публичного ключа нужен еще и личный ключ.

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