当用户调用链代码时，他们需要传递对象地址，在该地址上将评估链代码的内存代码。如果启用了TLS，则用户还需要拥有上述对等方的CA证书。例如，假设有三个组织A，B，C。认可政策需要得到每个组织的认可。 A组织中的用户想要调用链代码。他们需要运行传递对等地址的peer chaincode invoke，以便包含来自每个组织的对等体。那没问题。但是如果启用了TLS，那么用户还应该包括每个组织的TLS CA证书（使用--tlsRootCertFiles选项），否则呼叫将失败。这怎么合理？如何让用户拥有其他组织的TLS CA Cert？在实践中，如何获得这个？
这与发布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），则客户端将要求--peerAddresses中的对等体的TLS CA证书成功进行TLS身份验证。
如何让用户拥有其他组织的TLS CA Cert？在实践中，如何获得这个？
获取TLS CA Certs =颁发其他组织TLS证书的机构的证书的一种方法是使用discover 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是运行Fabric安装script时下载的二进制文件的一部分。