Включение SSL / TLS - openssl

Question

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

для создания CSR

---

Цель состоит в том, чтобы установить соединения SSL / TLS между двумя узлами (клиент и сервер).

Исходя из вышеприведенной схемы, я понимаю, что в качестве входных данных для передачи CSR должен использоваться открытый ключ, но шаг 4 использует закрытый ключ (server-key.pem) для создания CSR (server.CSR)

---

Шаг 1) Создание ключа центра сертификации (закрытый ключ)

$ openssl genrsa -aes256 -out ca-key.pem 4096

Шаг 2) Создание центра сертификации (корневого сертификата) с помощью ввода (ca-key.pem)

$ openssl req -new -x509 -days 365 -key ca-key.pem -sha256 -out ca.pem

Шаг 3) Создание личного ключадля веб-сервера

$ openssl genrsa -out server-key.pem 4096

Шаг 4) Создайте запрос на подпись сертификата (CSR), введя идентификатор пользователя.Это создаст открытый ключ по очереди.

$ openssl req -subj "/CN=dockerbuild.harebrained-apps.com" -sha256 -new -key server-key.pem -out server.csr

Шаг 5) Добавить конфигурацию

$ echo subjectAltName = IP:40.xx.xx.164,IP:10.0.0.4,IP:127.0.0.1,DNS:dockerbuildsys.westus.cloudapp.azure.com,DNS:dockerbuild.harebrained-apps.com > extfile.cnf

Шаг 6) Создать серверсертификат

$ openssl x509 -req -days 365 -sha256 -in server.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem -extfile extfile.cnf

Шаг 7) Создание личного ключа клиента

$ openssl genrsa -out key.pem 4096

Шаг 8) Создание CSR для клиента путем ввода идентификатора пользователя

$ openssl req -subj '/CN=client' -new -key key.pem -out client.csr

Шаг 9) Файл расширения сертификата для клиента

$ echo extendedKeyUsage = clientAuth > extfile.cnf

Шаг 10) Создание сертификата клиента

$ openssl x509 -req -days 365 -sha256 -in client.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out cert.pem -extfile extfile.cnf

Шаг 11) Удаление запросов на подпись

$ rm -v client.csr server.csr

Шаг 12) Удаление разрешений на запись для ключей

$ chmod -v 0400 ca-key.pem key.pem server-key.pem

Шаг13) Разрешения на чтение сертификата для каждого пользователя

$ chmod -v 0444 ca.pem server-cert.pem cert.pem

Шаг 14) Загружен на стороне сервера, Центр сертификации (ca.pem), Сертификат сервера (server-cert.pem)& ключ сервера (server-key.pem)

---

У меня очень хорошее понимание симметричного и асимметричного шифрования ключей.

Мы используем асимметричные ключи для решения проблемы распределения ключей (symметрический ключ) между двумя сторонами

Я понимаю, что каждый сертификат имеет открытый ключ + личность владельца (который предоставляет сертификат)

---

Вопросы:

1) Являются ли ca-key.pem, server-key.pem & key.pem симметричными ключами?

2) Зачем создавать центр сертификации (ca.pem)?Зачем нам нужен закрытый ключ (ca-key.pem) для создания центра сертификации?

3) Зачем нам нужен закрытый ключ для создания CSR?Поскольку это противоречит диаграмме (выше)?

4) Зачем создавать запрос на подпись сертификата (CSR) перед созданием сертификата?и клиент, и сервер

5) Зачем нам нужны два сертификата (сертификат сервера server-cert.pem и сертификат клиента cert.pem)?

6) openssl req -subj "/CN=dockerbuild.harebrained-apps.com" -sha256 -new -key server-key.pem -out server.csr создает server.csr, которые содержатоткрытый ключ + идентификация пользователя?Если да, то как этот открытый ключ отличается от открытого ключа, предоставленного сертификатом (server-cert.pem)?

7) Если в вышеуказанном процессе не созданы симметричные ключи, то как клиент и сервер взаимодействуют с шифрованием?

8) Как server-key.pem / server-cert.pem / ca.pem (загружено на сервер) работает с key.pem / cert.pem / ca.pem (на клиенте)?

Answer 1

1) Являются ли ca-key.pem, server-key.pem и key.pem симметричными ключами?

Это асимметричные ключи.При создании сертификатов вообще не задействованы симметричные ключи.Симметричные ключи используются только для фактического шифрования в TLS.

2) Зачем создавать центр сертификации (ca.pem)?Зачем нам нужен закрытый ключ (ca-key.pem) для создания центра сертификации?Поскольку это противоречит диаграмме (см. Выше)

CA - это якорь доверия.Закрытый ключ CA используется для выдачи (подписи) новых сертификатов.Сертификат CA, содержащий открытый ключ, является доверенным лицом, которому нравится проверять сертификат.См. Структура SSL-сертификата 101: Как браузер на самом деле проверяет действительность данного сертификата сервера? , чтобы лучше понять, как сертификаты CA и конечные сертификаты и подписи (выполняемые с использованием закрытого ключа) взаимодействуют.

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

3) Зачем нам нужен закрытый ключ для создания CSR?Поскольку это противоречит диаграмме (выше)?

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

4) Зачем создавать запрос на подпись сертификата (CSR) перед созданием сертификата?и клиент, и сервер

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

5) Зачем нам два сертификата (сертификат сервера server-cert.pem и сертификат клиента cert.pem)?

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

6) Содержит ли server.csr открытый ключ + идентификация пользователя?Если да, чем этот открытый ключ отличается от открытого ключа, предоставленного сертификатом?

Открытый ключ в CSR такой же, как в сертификате.В сертификате (домене) есть специфичная для пользователя информация, но ЦС должен проверить с помощью других средств, что эта информация действительно верна (т. Е. Пользователь владеет доменом), прежде чем выдавать сертификат.

7) Еслинет никаких симметричных ключей, созданных в вышеупомянутом процессе, тогда как клиент и сервер взаимодействуют с шифрованием?

Рукопожатие TLS содержит часть аутентификации (проверьте, что сервер является ожидаемым на основе сертификата)и обмен ключами.Последний генерирует симметричные ключи, используемые для шифрования данных приложения.Подробнее см. Как работает SSL / TLS? .

8) Как server-key.pem / server-cert.pem / ca.pem (загружено на сервер)работать с key.pem / cert.pem / ca.pem (на клиенте)?

Закрытый ключ сертификата сервера используется для подписания некоторого запроса в рукопожатии TLS, чтобы доказать, чтоСервер владеет данным сертификатом.Закрытый ключ сертификата клиента используется аналогичным образом, если выполняется взаимная проверка подлинности.Сертификат CA используется для проверки сертификата (снова см. Структура сертификата SSL 101: Как браузер фактически проверяет действительность данного сертификата сервера? ).