Hyperledger Fabric SDK-https& TLS证书/密钥

问题描述

注意:我正在使用Go SDK，但这应适用于Node，Java等SDK.

Note: I am using the Go SDK, but this should apply to Node, Java, etc. SDKs.

我正在使用fabric-ca实例作为我的证书颁发机构，并且对于现实的生产环境，我需要使用安全连接.

I am using a fabric-ca instance as my Certificate Authority, and for a realistic production environment I need to use a secure connection.

基于config-e2e.yaml示例配置文件[1]，我们应该能够在CA url中使用https.示例:

Based on the config-e2e.yaml example configuration file [1], we should be able to use https in the CA url. Example:

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

但是，一旦需要https，则SDK要求在client部分[1]中添加TLS证书/密钥文件路径:

However, once https is required, the SDK requires that the TLS cert/key filepath is added in the client section [1]:

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]的有限了解，对于https连接，不需要双向TLS(大多数浏览器不要使用双向TLS来确保连接的安全性.

However, other docs [2] indicate that the tlsCACerts section is for mutual TLS connections, and based on my limited understanding of TLS [3], mutual TLS should not be needed for an https connection (most browsers don't use mutual TLS to secure the connection).

有人可以解释:

1)最简单的方法来保护(https)SDK(客户端)与CA/对等方/订购方之间的连接安全吗?

1) The most simplistic way to secure (https) a connection between the SDK (client) and the CA / peer / orderer?

2)为什么在生产中使用TLS证书/密钥文件路径时应经常刷新这些文件时，为什么要将它们硬编码到配置文件中?

2) Why we are hard-coding TLS cert/key filepaths into the config file when these should be refreshed very often when use in production?

注意:此问题/答案似乎表明您不需要相互TLS来进行安全连接，但是如果我在我的CA url中添加https:，我将报错，直到填写tlsCACerts部分.

NOTE: This question/answer seems to indicate that you don't need mutual TLS for a secure connection, but if I add https: to my CA url, I get errors until I fill in the tlsCACerts section.

[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

推荐答案

下面的答案是w.r.t. Node SDK ，但希望他们对这个问题有所了解

The answers below are w.r.t. the Node SDK but hope they shed some light on the question

sdk节点不支持与启用了clientauth(又称为双向TLS)的结构ca服务器通信[ 1 ]

The node sdk does not support communicating with a fabric ca server that has clientauth (aka mutual TLS) enabled [1]

(tlsCACerts中的证书进行了验证.可以将验证过程视为在以下命令中运行:

The TLS certificate provided by a (TLS enabled) server is validated against the certificate in tlsCACerts. The validation process can be thought of as running below command:

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

tlsCACerts属性是在网络-config.yaml 文件-如果需要，它们都可以使用不同的tlsCACerts.

The tlsCACerts property is set per peer, orderer and fabric ca server in the network-config.yaml file - all of them could use different tlsCACerts if they wanted.

对于对等方和订购者，节点sdk确实支持clientauth(或双向TLS)，但必须使用代码而不是[ 2 ]-请参见显示如何使用client.setTlsClientCertAndKey(cert, key)

For the peer and orderer, the node sdk does support clientauth (or mutual TLS) but it has to be setup in code not the config file as described in [2] - see the section where they show how to use client.setTlsClientCertAndKey(cert, key)

问题中的陈述

是错误的.

我认为这些内容不会经常刷新.讽刺的是，如果它们是IMO，那将是正确的配置.

I don't think these would be refreshed very often. And if they were, then, ironically, config would be the right place IMO.

问题中的这个陈述

是正确的.相互TLS支持双向验证，即服务器还可以验证客户端.在单向TLS中，只有客户端才能验证服务器.

is correct. Mutual TLS enables bi-directional verification i.e., the server also validates the client. In one-way TLS, it is only the client that validates the server.

这篇关于Hyperledger Fabric SDK-https& TLS证书/密钥的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！