【发布时间】：2021-01-08 13:22:01
【问题描述】：
我们正在尝试在运行 API 服务器（基于 Node.js）的 docker 容器和运行 的另一个 docker 容器之间建立 grpcs (TLS) 连接来自 Fabric 网络的 peer0。 所有容器都由 docker swarm 编排，并且两个容器恰好运行在同一个 Linux 主机上。
API容器抛出的错误日志如下：
2021-01-07T18:27:38.110Z - 错误：[Remote.js]：错误：未能 截止前连接 URL:grpcs://10.0.1.2:9051 查询有 已完成，从查询检查结果错误 = { 错误：未能 截止前连接网址：grpcs://10.0.1.2:9051 在 checkState (/usr/src/app/node_modules/grpc/src/client.js:833:16) 连接失败： true } sampleEvent 错误：错误：14 不可用：连接失败 E0107 18:27:53.602719124 16 ssl_transport_security.cc:1229] 握手 失败并出现致命错误 SSL_ERROR_SSL: error:14090086:SSL 例程：ssl3_get_server_certificate：证书验证失败。
而从peer0抛出的错误日志是：
2021-01-07 18:50:22.224 UTC [core.comm] ServerHandshake -> ERRO 043 TLS 握手失败，错误 EOF server=PeerServer remoteaddress=10.0.1.4:46212
IP 地址布局
- API 容器的 IP 地址是 10.0.1.94
- peer0 容器的 IP 地址是 10.0.1.3
- docker service peer0 的虚拟 IP 地址是 10.0.1.2
- docker swarm 负载均衡器端点的 IP 地址是 10.0.1.4
有什么建议可以进一步排除故障吗？目前尚不清楚问题是 docker swarm 内部网络问题，还是网络任一端的 ssl 证书问题。
2021 年 2 月 2 日更新
通过升级 NodeSDK 中使用的 javascript 修复了原始 TLS 握手错误。除其他外，我们开始使用 commercial-paper 示例中包含的 addToWallet.js 脚本
在 Node.js API 和 peer0 之间成功建立 TLS 后，我们在对 chaincode_example02 进行简单查询时收到一个新的 access denied 错误
事实：
- 我们正在使用 2 个管理员用户运行查询
- 一个管理员是第一网络原创Admin@org1.example.com，凭据由
cryptogen工具生成 - 另一位管理员是 Admin@buyer.dlt.com，其凭据是使用 openssl 和自签名的公司内部 CA 创建的
- 在 CLI 中，两个 Admin 都很好，并且可以交替运行对等命令
- 从 Node.js 应用程序中，仅允许 Admin@org1.example.com 运行查询。打印到 console.log 的消息是：
Transaction has been evaluated, result is: 100
- 使用 Admin@buyer.dlt.com 运行查询时，我们会收到以下错误日志：
来自 peer0@buyer.dlt.com
的错误日志2021-02-02T04:08:45.291086617Z ^[[36m2021-02-02 04:08:45.290 UTC [protoutils] checkSignatureFromCreator -> DEBU 6e637^[[0m creator is &{BuyerMSP 8b7cc2ee996be4f7e5dbb1a4f64db67afd2ff8a2f41276c9bd7f33a2447dd9df}
2021-02-02T04:08:45.291094817Z ^[[36m2021-02-02 04:08:45.290 UTC [protoutils] checkSignatureFromCreator -> DEBU 6e638^[[0m creator is valid
2021-02-02T04:08:45.291100418Z ^[[36m2021-02-02 04:08:45.290 UTC [msp.identity] 2021-02-02T04:08:45.303821799Z ^[[33m2021-02-02 04:08:45.303 UTC [protoutils] ValidateProposalMessage -> WARN 6e63b^[[0m channel [mychannel]: creator's signature over the proposal is not valid: The signature is invalid
2021-02-02T04:08:45.303891604Z ^[[36m2021-02-02 04:08:45.303 UTC [endorser] func1 -> DEBU 6e63c^[[0m Exit: request from 10.0.1.84:52696
2021-02-02T04:08:45.303902005Z ^[[34m2021-02-02 04:08:45.303 UTC [comm.grpc.server] 1 -> INFO 6e63d^[[0m unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=10.0.1.84:52696 error="access denied: channel [mychannel] creator org [BuyerMSP]" grpc.code=Unknown grpc.call_duration=13.783655ms
来自脚本 query.js 的 console.log 错误日志：
2021-02-02T04:08:45.305Z - error: [Channel.js]: Error: 2 UNKNOWN: access denied: channel [mychannel] creator org [BuyerMSP]
2021-02-02T04:08:45.307Z - error: [Network]: _initializeInternalChannel: Unable to initialize channel. Attempted to contact 1 Peers. Last error was Error: 2 UNKNOWN: access denied: channel [mychannel] creator org [BuyerMSP]
Failed to evaluate transaction: Error: Unable to initialize channel. Attempted to contact 1 Peers. Last error was Error: 2 UNKNOWN: access denied: channel [mychannel] creator org [BuyerMSP]
【问题讨论】：
-
您是否尝试通过主机名或 IP 地址从 API 服务器访问对等方？对等方的 TLS 证书中的 SAN 是什么？
-
@GariSingh 我尝试过两种方式访问对等方。通过主机名的 IP 地址。对等 TLS 证书中的 SAN 与主机名匹配。更多事实：1) Peer 可通过其 SAN 从 API 容器 ping 2) API 容器正在使用管理员凭据进行连接。当使用来自 CLI 容器的相同管理员凭据时，它就像一个魅力 3）为了丢弃内部 docker swarm TLS 网络问题，我刚刚启动了一个具有相同（坏）结果的独立对等容器。至少我们知道这不是 docker swarm 制造噪音。
-
知道为什么同行会抛出错误 EOF？我们将凭据传递给 API，它用于建立与对等方的 TLS 连接。也许对等方正在从 API 接收格式错误的消息？
-
Node.js 是否使用正确的 CA 证书（为对等方颁发 TLS 证书的证书）？
-
EOF 通常意味着客户端终止了连接
标签： docker ssl hyperledger-fabric hyperledger docker-swarm