Когда и зачем вам нужно использовать CACert при согласовании TLS?

Я пытаюсь понять параметры, используемые для настройки TLS (в частности, для rabbitmq, но мой вопрос может быть более общим).

Следует рассмотреть 4 основных объекта:

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

  • Cert — сертификат, содержащий открытый ключ однорангового узла. Он также содержит некоторые идентифицирующие данные, такие как имя хоста, организация и т. д., многие из которых являются необязательными. Сертификат может быть неподписанным (редко, если вообще когда-либо?), самоподписанным или подписанным центром сертификации.

  • CACert — сертификат ЦС, которому доверяет одноранговый узел, который можно использовать для расшифровки и проверки подписи подписанного сертификата.

  • CA-key — закрытый ключ CA, который используется для подписи сертификата.

Они соответствуют параметрам конфигурации, включая:

  • enablePeerVerification — если true, то одноранговый узел пытается проверить, действительно ли сервер является тем, за кого он себя выдает, проверяя, действительно ли сертификат был подписан ЦС (и аналогично вверх по цепочке доверия, пока не достигнет ЦС, которому он доверяет, потому что в его сертификате есть сертификат). локальное хранилище доверия ЦС). Плохая идея установить для этого параметра значение false, поскольку кто-то может выдать себя за коллегу. (в go эта опция называется InsecureSkipVerify как предупреждение) Если сертификат самоподписанный, одноранговая проверка невозможна. Эта опция позволяет вам использовать самозаверяющий сертификат партнера на свой страх и риск (например, во время разработки).

  • Key - закрытый ключ, используемый для расшифровки

  • Cert — используется для шифрования (и установления связи)

  • CACert - сертификат ЦС, подписавшего сертификат "Cert"

Зачем нужны параметры конфигурации для CACert?

Если сертификат подписан ЦС, то он уже содержит достаточно информации для определения местонахождения ЦС (например, имя домена). Для чего нужен сертификат CACert и когда он отправляется во время согласования TLS? Это просто удобство, чтобы сэкономить на непосредственном обращении в ЦС? Вам все равно придется сделать это, если CACert не совпадает или не указывает на него в вашем доверенном хранилище.

Я имею в виду настройки "cacert" в rabbitmq.config для сервера и amqp_ssl_socket_set_cacert() в C API (rabbitmq-c).

Я хотел бы проверить правильность моего понимания (https://xkcd.com/386/)


ssl rabbitmq ssl-certificate rabbitmq-c
person Bruce Adams    schedule 12.10.2018    source источник
comment
Возможно, это дубликат security.stackexchange.com/questions/93157/. Сервер отправляет все сертификаты в цепочке в виде сообщений о сертификатах. Если это так, то не должен ли параметр конфигурации быть расположением локального хранилища доверенных сертификатов, которое их содержит, а не одним сертификатом?   -  person Bruce Adams    schedule 12.10.2018
comment
Я думаю, что ответ может заключаться в том, что CACert — это не один сертификат, а пакет (support.comodo.com/index.php?/Knowledgebase/Article/View/1145/1/) сертификатов, дающих всю цепочку (объединенных в корневом порядке). Кто-нибудь может подтвердить?   -  person Bruce Adams    schedule 12.10.2018

Ответы (1)


arrow_upward
1
arrow_downward

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

Рукопожатие TLS:

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

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

Часто эти две настройки являются только одним.

В настоящее время:

Если сертификат подписан ЦС, то он уже содержит достаточно информации для определения местонахождения ЦС (например, имя домена).

Не уверен, что понял вас, но в целом нет. Во-первых, сертификат не обязательно/только для доменного имени, он может быть для других вещей. Затем сертификат обычно подписывается промежуточным звеном, а не непосредственно ЦС. Поэтому я не уверен, как вы хотите найти ЦС?

person Patrick Mevzek    schedule 12.10.2018
comment
Последний пункт, который может быть моим неправильным использованием термина CA? Я предположил, что ЦС включает в себя как корневой ЦС, так и посредников. Сертификат, который у вас есть, указывает на первого посредника в цепочке. Я привел доменное имя в качестве примера, так как оно может указывать на следующий сертификат в цепочке. Тем не менее, это, кажется, суть моего непонимания. Эмитента можно найти через поле AIA, если оно присутствует, но вместо того, чтобы заставить вас уйти и получить его, TLS вместо этого заставляет вас отправлять целый пакет сертификатов. Возможно, мой вопрос должен заключаться в том, почему бы просто не включить ваш сертификат в ваш комплект, то есть вместе с CAcert? - person Bruce Adams; 12.10.2018
comment
То, что называется сертификатом CA, часто является (одним или несколькими) промежуточными звеньями. Поскольку настоящие сертификаты ЦС (самоподписанные сертификаты, которым вы абсолютно доверяете) часто хранятся на хосте, например /etc/ssl/certs в Unix, и все инструменты смотрят на них там, поэтому на них не нужно ссылаться в конфигурациях. Это просто необходимо для оценки достоверности. Его также не обязательно отправлять во время рукопожатия. - person Patrick Mevzek; 12.10.2018