HyperLedger Fabric 和 Docker Swarm：握手失败，出现致命错误 SSL_ERROR_SSL

如何解决HyperLedger Fabric 和 Docker Swarm：握手失败，出现致命错误 SSL_ERROR_SSL

我们正在尝试在运行 API 服务器（基于 Node.js）的 docker 容器和运行 的另一个 docker 容器之间建立 grpcs (TLS) 连接peer0 来自 Fabric 网络。 所有容器都由 docker swarm 编排，并且两个容器恰好在同一 Linux 主机上运行。

API 容器抛出的错误日志如下：

2021-01-07T18:27:38.110Z - 错误：[Remote.js]：错误：未能 在截止日期前连接 URL:grpcs://10.0.1.2:9051 Query has 已完成，从查询检查结果错误 = { 错误：未能 在截止日期前连接 URL：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 失败：错误：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 后，我们在对 access denied 进行简单查询时出现新的 chaincode_example02 错误

事实：

1. 我们正在使用 2 个管理员用户运行查询
2. One Admin 是 first-network [e-mail]，凭据由 cryptogen 工具生成
3. 另一位管理员是 [e-mail]，其凭据是使用 openssl 和自签名公司内部 CA 创建的
4. 从 CLI 来看，两个管理员都很好，并且可以交替运行对等命令
5. 在 Node.js 应用中，仅允许 [e-mail] 运行查询。打印到 console.log 的消息是：

Transaction has been evaluated,result is: 100

6. 使用 [e-mail] 运行查询时，我们会收到以下错误日志：

来自 [e-mail]

的错误日志

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]

解决方法

最后，这个问题变成了两个问题，“俄罗斯娃娃”风格。

1.第一期：TLS Handshake error 这是通过将 SDK 库升级到最新版本来解决的

2.第二个问题：Node SDK 查询触发错误“The signature is invalid”。 原因原来是 CLI（用 Go 编写）使用 Go 加密支持，它允许它在不了解用于密钥的曲线的情况下从散列生成签名。相反，Node 实现使用的 SDK 库需要由生成签名的代码指定一条特定曲线，与私钥本身分开。 最重要的是，Node SDK 中使用的私钥应该是 P-256。 作为替代方案，正如超级账本开发团队所建议的：

如果你真的必须使用 P-256 以外的曲线，那么你也许可以 使用以下方法之一：

-使用文档中包含的离线签名方法，但指定替代曲线而不是“p256”。支持的曲线 对于此处记录的椭圆包： https://github.com/indutny/elliptic

-在支持网关对象的客户端上设置您自己的 CryptoSuite 实现，使用您自己的 CryptoSuite.sign() 实现： https://hyperledger.github.io/fabric-sdk-node/release-2.2/CryptoSuite.html#sign