当用户调用链码时，他们需要传递对等地址，在该地址上将评估链码以进行内化。如果启用了 TLS，则用户还需要拥有上述对等方的 CA 证书。例如，假设有三个组织 A、B、C。背书策略要求每个组织都背书。A 组织中的用户想要调用链码。他们需要运行对等链码调用传入对等地址，以便包含来自每个组织的对等。没关系。但是，如果启用了 TLS，则用户还应包含每个组织的 TLS CA 证书(使用--tlsRootCertFiles选项)，否则调用将失败。这怎么合理？如何期望用户拥有其他组织的TLS CA证书？在实践中，这将如何获得？
这与为 Web 服务颁发证书没有什么不同：您要么信任第三方提供商来交换证书，要么直接与交易对手交换。
Fabric是一个许可的区块链，一开始就有一定程度的信任。否则，你永远不会知道你在和谁进行交易，就像以太坊的比特币一样，它正在解决一个不同的用例。
怎么合理？
为了说明为什么提出这个问题的背景，当调用peer chaincode invoke时，需要传递一个CORE_PEER_ADDRESS否则会出现错误：
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x60 pc=0x110fddc]
goroutine 1 [running]:
github.com/hyperledger/fabric/peer/common.NewPeerClientForAddress(0x7ffd955fe783, 0x9, 0x7ffd955fe7a0, 0x10, 0x8fb52c, 0x9e8745, 0x14848a7)
/opt/gopath/src/github.com/hyperledger/fabric/peer/common/peerclient.go:44 +0x8c
我们认为peer chaincode invoke只是向 CORE_PEER_ADDRESS 中给出的节点提交请求，并且在--peerAddresses中给出的节点上调用链码的实际行为是由 CORE_PEER_ADDRESS 中的节点完成的。如果是这种情况，则执行peer chaincode invoke的客户端不必携带--peerAddresses中给出的对等方的 TLS CA 证书。然而，事实并非如此。执行peer chaincode invoke的客户端确实调用了--peerAddresses上的链码。如果在对等方上启用了 TLS(CORE_PEER_TLS_ENABLED=true在对等体启动时)，则客户端将需要 TLS CA 证书才能成功--peerAddressesTLS 身份验证。
如何期望用户拥有其他组织的TLS CA证书？在实践中，这将如何获得？
获取 TLS CA 证书 = 向其他组织颁发其 TLS 证书的颁发机构的证书的一种方法是使用发现 CLI，如下所示：
/etc/hyperledger/bin/discover --peerTLSCA my-ca-chain.pem --userKey msp/keystore/user-myorg.key --userCert msp/signcerts/user-myorg.pem --MSP myorgMSP --tlsCert user-myorg-tls-client.pem --tlsKey user-myorg-tls-client.key config --server peer1-myorg:7051 --channel mychannel > discover.json
discover.json中的证书采用 base64 编码。因此，它们需要进行base64解码，如果有中间证书，则需要在链文件中的根证书之前。
例：
cat discover.json | jq .msps.cvsMSP.tls_root_certs[0] | sed "s/"//g" | base64 --decode > rca-cvs.pem
cat discover.json | jq .msps.cvsMSP.tls_intermediate_certs[0] | sed "s/"//g" | base64 --decode > ica-cvs.pem
cat ica-cvs.pem rca-cvs.pem > cvs-ca-chain.pem
发现 CLI 是运行结构安装脚本时下载的二进制文件的一部分。