Hyperledger Fabric SDK - сертификат / ключ https & TLS

Question

Примечание. Я использую Go SDK, но это должно относиться к Node, Java и т. Д. SDK.

Я использую экземпляр fabric-ca в качестве центра сертификации, и для реалистичной производственной среды мне нужно использовать безопасное соединение.

Исходя из примера файла конфигурации config-e2e.yaml [1], мы должны иметь возможность использовать https в URL-адресе CA. Пример:

certificateAuthorities:
  org1-ca:
    url: https://localhost:7054

Однако, если требуется https, SDK требует, чтобы в разделе client [1] был добавлен путь к файлу сертификата / ключа TLS:

tlsCACerts:
      # Comma-Separated list of paths
      path: {filepath}
      # Client key and cert for SSL handshake with Fabric CA
      client:
        key:
          path: {filepath}
        cert:
          path: {filepath}

Однако другие документы [2] указывают, что раздел tlsCACerts предназначен для взаимных соединений TLS, и, исходя из моего ограниченного понимания TLS [3], взаимный TLS не должен быть необходим для соединения https (большинство браузеров не используйте взаимный TLS для защиты соединения).

Может кто-нибудь объяснить:

1) Самый простой способ защитить (https) соединение между SDK (клиентом) и CA / peer / orderer?

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

---

ПРИМЕЧАНИЕ: Этот вопрос / ответ , по-видимому, указывает на то, что вам не нужен взаимный TLS для безопасного соединения, но если я добавлю https: к своему URL-адресу CA, я получу ошибки, пока не заполню секция tlsCACerts.

[1] https://github.com/hyperledger/fabric-sdk-go/blob/master/test/fixtures/config/config_e2e.yaml
[2] (см. «Проверка подлинности клиента» и параметры TLS на стороне сервера) https://hyperledger -fabric.readthedocs.io / en / release-1.2 / enable_tls.html
[3] http://www.cafesoft.com/products/cams/ps/docs32/admin/SSLTLSPrimer.html

Answer 1

Ответы ниже приведены для Node SDK , но надеюсь, что они проливают некоторый свет на вопрос

1) Самый простой способ обеспечить (https) соединение междуSDK (клиент) и CA / peer / orderer?

Узел SDK не поддерживает связь с сервером фабрики ca, для которого включена поддержка клиентов (взаимный TLS) [ 1 ]

Сертификат TLS, предоставленный сервером (с поддержкой TLS), проверяется на соответствие сертификату в tlsCACerts.Процесс проверки можно представить как выполняющуюся ниже команду:

openssl verify -CAfile <tlsCACerts> <cert-provided-by-server>

Свойство tlsCACerts устанавливается для каждого участника, заказчика и фабрики ca server в файле network-config.yaml - все они могли бы использовать разные tlsCACerts, если они хотели.

Для однорангового и заказчика, узел sdk поддерживает clitatauth (или взаимный TLS), но он должен быть настроен в коде, а не в файле конфигурации, так какописано в [ 2 ] - см. раздел, в котором они показывают, как использовать client.setTlsClientCertAndKey(cert, key)

Утверждение в вопросе о том, что

tlsCACerts раздел для взаимнойСоединения TLS

неверны.

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

Не знаюНе думаю, что они будут обновляться очень часто.И если бы они были, то, по иронии судьбы, config был бы правильным местом IMO.

Это утверждение в вопросе

взаимный TLS не должен быть необходим для соединения https (большинство браузеровне используйте взаимный TLS для защиты соединения).

правильно.Взаимный TLS обеспечивает двунаправленную проверку, т. Е. Сервер также проверяет клиента.В одностороннем TLS только сервер проверяет сервер.