TLS handshake failed with error remote error: tls: bad certificate server=Orderer using Raft and Intermediate certs
TLS handshake failed with error remote error: tls: bad certificate server=Orderer using Raft and Intermediate certs
我看到有很多关于这个错误的问题，我已经看到了这个解决方案 but I doubled checked and the folders are right and the certs are in there, I also looked at 但据我所知，我在使用 Raft 时不需要 Sans（我可能是错的）。我认为我的问题是因为我没有正确处理中间证书并且我在创建通道和 Raft 共识中都遇到了错误。
这是我到目前为止所做的：
我使用 configtx.yaml 和这个 msp 文件夹结构创建了我的创世块：
configtx.yaml
Organizations:
- &ordererOrg
Name: orderer
ID: orderer
MSPDir: /crypto/msp
Policies:
Readers:
Type: Signature
Rule: "OR('orderer.member')"
Writers:
Type: Signature
Rule: "OR('orderer.member')"
Admins:
Type: Signature
Rule: "OR('orderer.admin')"
Capabilities:
Channel: &ChannelCapabilities
V1_4_3: true
Orderer: &OrdererCapabilities
V1_4_2: true
Application: &ApplicationCapabilities
V1_4_2: true
Application: &ApplicationDefaults
Organizations:
Policies:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
Capabilities:
<<: *ApplicationCapabilities
Orderer: &OrdererDefaults
OrdererType: solo
BatchTimeout: 2s
BatchSize:
MaxMessageCount: 10
AbsoluteMaxBytes: 99 MB
PreferredMaxBytes: 512 KB
Kafka:
Brokers:
- 127.0.0.1:9092
Organizations:
Policies:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
BlockValidation:
Type: ImplicitMeta
Rule: "ANY Writers"
Channel: &ChannelDefaults
Policies:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
Capabilities:
<<: *ChannelCapabilities
Profiles:
SampleEtcdRaftProfile:
<<: *ChannelDefaults
Capabilities:
<<: *ChannelCapabilities
Orderer:
<<: *OrdererDefaults
OrdererType: etcdraft
Addresses:
- orderer1.xxxx.eastus.aksapp.io:443
- orderer2.xxxx.eastus.aksapp.io:443
Organizations:
- *ordererOrg
EtcdRaft:
Consenters:
- Host: orderer1
Port: 7050
ClientTLSCert: /crypto/orderers/orderer1/tls/server.crt
ServerTLSCert: /crypto/orderers/orderer1/tls/server.crt
- Host: orderer2
Port: 7050
ClientTLSCert: /crypto/orderers/orderer2/tls/server.crt
ServerTLSCert: /crypto/orderers/orderer2/tls/server.crt
Capabilities:
<<: *OrdererCapabilities
Application:
<<: *ApplicationDefaults
Organizations:
- <<: *ordererOrg
Consortiums:
SampleConsortium:
Organizations:
- *ordererOrg
MSP 文件夹结构：
+ /crypto
configtx.yaml
+ msp
+ cacerts > ca.crt
+ tlscacerts > ca.crt
+ intermediatecerts > intermediate.crt
+ tlsintermediatecerts > intermediate.crt
+ admincerts > admin.crt
+ orderers
+ orderer1/tls > server.crt
+ orderer2/tls > server.crt
我用这个创建了我的创世块：
configtxgen -profile SampleEtcdRaftProfile -outputBlock genesis.block -channelID mychannel
现在我在订购者内部怀疑 msp 结构是这样的：
+ /var/hyperledger/orderer
genesis.block
+ msp
+ cacerts > ca.crt
+ intermediatecerts > intermediate.crt
+ admincerts > admin.crt
+ signcerts > cert.pem
+ keystore > key.pem
+ tls
server.crt
server.key
ca.crt
intermediate.crt
这些是我的环境变量：
ORDERER_GENERAL_TLS_ENABLED=true
ORDERER_GENERAL_TLS_PRIVATEKEY=/var/hyperledger/orderer/tls/server.key
ORDERER_GENERAL_TLS_CERTIFICATE=/var/hyperledger/orderer/tls/server.crt
ORDERER_GENERAL_TLS_CLIENTROOTCAS=/var/hyperledger/orderer/tls/ca.crt
ORDERER_GENERAL_TLS_CLIENTAUTHREQUIRED=false
ORDERER_GENERAL_CLUSTER_CLIENTPRIVATEKEY=/var/hyperledger/orderer/tls/server.key
ORDERER_GENERAL_CLUSTER_CLIENTCERTIFICATE=/var/hyperledger/orderer/tls/server.crt
ORDERER_GENERAL_CLUSTER_ROOTCAS=/var/hyperledger/orderer/tls/ca.crt
我不确定为什么结构不同并且 tls 文件在其他地方，但我正在从我已经成功使用的 azure hyperledger template 复制配置。
现在我的排序节点是 运行，但是排序节点 1 一直在开始新的选举，排序节点 2 成为候选者并最终因 TLS 握手错误而失败。
这些是 orderer2 中的错误日志：
2021-03-23 22:15:21.969 UTC [orderer.consensus.etcdraft] Step -> INFO f96 2 is starting a new election at term 1 channel=canalenergia node=2
2021-03-23 22:15:21.969 UTC [orderer.consensus.etcdraft] becomePreCandidate -> INFO f97 2 became pre-candidate at term 1 channel=canalenergia node=2
2021-03-23 22:15:21.969 UTC [orderer.consensus.etcdraft] poll -> INFO f98 2 received MsgPreVoteResp from 2 at term 1 channel=canalenergia node=2
2021-03-23 22:15:21.969 UTC [orderer.consensus.etcdraft] campaign -> INFO f99 2 [logterm: 1, index: 2] sent MsgPreVote request to 1 at term 1 channel=canalenergia node=2
2021-03-23 22:15:26.673 UTC [core.comm] ServerHandshake -> ERRO f9a TLS handshake failed with error remote error: tls: bad certificate server=Orderer remoteaddress=x.x.x.x:45472
我尝试删除 intermediate.crt 并将 ca.crt 和 intermediate.crt 混合到订购者 tls 文件夹中 ca.crt 中的一个文件中，如下所示：
-----BEGIN CERTIFICATE-----
ROOTCERTxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
INTERMEDIATExxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
-----END CERTIFICATE-----
但是也没用。
我尝试了 openssl verify -CAfile chain.crt orderer1-tls.crt 和 returns OK。
这是我尝试创建新频道时发生的情况：
peer channel create -o orderer1.xxxx.eastus.aksapp.io -c testchannel -f ./channel.tx --tls --cafile /var/hyperledger/peer/msp/tlscacerts/ca.crt --clientauth --certfile /var/hyperledger/peer/tls/cert.pem --keyfile /var/hyperledger/peer/tls/key.pem
2021-03-24 00:04:40.331 UTC [comm.tls] ClientHandshake -> ERRO 001 Client TLS handshake failed after 939.077µs with error: EOF remoteaddress=x.x.x.x:443
我用 telnet 测试了我的 url，它们没问题。
我使用 openSSL 创建了我的证书，但我没有发现它们有任何问题，唯一的区别是它们不是由 fabric-ca 签署的，而是由一家大公司的中间 CA 签署的。
我已经仔细检查了所有的值，但我猜 orderer 甚至不会是 运行 如果它们不正确并遵循这个 script 来自 azure 仅用于创建创世块添加中间信息。
任何建议都很好。
谢谢
更新：
我用这个变量激活了调试日志：
FABRIC_LOGGING_SPEC="grpc=debug:info"
发现问题是这样的：
传输：身份验证握手失败：x509：证书对任何名称均无效，但希望匹配 orderer1
我的证书有这个主题：
CN=orderer1-tls@blockchain.company.com,O=公司,L=城市,ST=州,C=美国
现在，我不明白为什么它告诉我它没有名字，我虽然 CN orderer1-tls@blockchain.company.com 是名字，而且，还有，我在哪里告诉要搜索的名称是“orderer1”的订购者？
更新 2：
我将我的 TLS 证书更改为 CN=orderer.company.com 然后错误是这样的：
x509: certificate is valid for orderer1.company.com, not orderer1
正如李可以所说，订购者需要证书 CN 中的主机名，而我的主机名是 orderer1，所以我将其更改为那个。
现在我收到一个新错误：
UTC [comm.grpc.server] 1 -> INFO 118 streaming call completed grpc.service=orderer.Cluster grpc.method=Step grpc.peer_address=x.x.x.x:39424 error="no TLS certificate sent" grpc.code=Unknown grpc.call_duration=161.713µs
我想这是一个新错误，所以我要开一个新问题。谢谢！
安娜
我在学习的时候遇到了同样的问题fabric.and我已经解决了，希望能帮到你
例如，当你在linux终端执行时
export CORE_PEER_TLS_ENABLED=true
export CORE_PEER_LOCALMSPID="Org1MSP"
export CORE_PEER_TLS_ROOTCERT_FILE=/home/www/byfn-on-k8s/crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt
export CORE_PEER_MSPCONFIGPATH=/home/www/byfn-on-k8s/crypto-config/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
export CORE_PEER_ADDRESS=peer0.org1.example.com:30011
peer channe list
你会得到正确的结果
并将 CORE_PEER_ADDRESS 更改为 exmaple.com(example.com link 与 peer0.org1.example.com 相同的 ip，您可以通过编辑 /etc/hosts),
export CORE_PEER_ADDRESS=example.com:30011
peer channe list
并且您将在对等日志中收到错误“TLS 握手失败并出现错误远程错误：tls：错误的证书服务器=PeerServer”
但这不是遇到错误“tls：错误证书”的唯一场景，
我认为这个错误是由“主机名验证”引起的
例如，你想访问对等点peer0.org1.example.com，这个对等点启用服务器tls，你可以找到server.crt和server.key 在对等环境中。
如果你解析server.crt，你会发现这个crt的CN是“peer0.org1.example.com”
当你联系对等点“peer0.org1.example.com”时，对等点会把它的证书发给你，你发现这个证书的CN是“peer0.org1.example.com” ,所以你信任这个服务器,
但是当你联系“example.com”（指向与 peer0.org1 相同的 IP。example.com），并且对等方向你发送它的证书时，你会发现证书的 CN 是“peer0.org1.example.com”，id 不等于“example.com”，所以你不信任这个服务器并得到错误。
我认为新错误“未发送 TLS 证书”是由您在订购者环境中设置 CORE_PEER_TLS_CLIENTAUTHREQUIRED=true 引起的。
所以我尝试在 CORE_PEER_TLS_CLIENTAUTHREQUIRED=true 时进行测试，当 raft elect 时我遇到另一个错误“tls:bad certificate”，所以我像这样更改排序者环境：
- ORDERER_GENERAL_TLS_ENABLED=true
- ORDERER_GENERAL_TLS_PRIVATEKEY=/var/hyperledger/orderer/tls/server.key
- ORDERER_GENERAL_TLS_CERTIFICATE=/var/hyperledger/orderer/tls/server.crt
- ORDERER_GENERAL_TLS_ROOTCAS=[/var/hyperledger/orderer/tls/ca.crt]
- ORDERER_KAFKA_TOPIC_REPLICATIONFACTOR=1
- ORDERER_KAFKA_VERBOSE=true
- ORDERER_GENERAL_TLS_CLIENTAUTHREQUIRED=true
- ORDERER_GENERAL_TLS_CLIENTROOTCAS=/var/hyperledger/orderer/tls/ca.crt
- ORDERER_GENERAL_CLUSTER_CLIENTCERTIFICATE=/var/hyperledger/orderer/tls/server.crt
- ORDERER_GENERAL_CLUSTER_CLIENTPRIVATEKEY=/var/hyperledger/orderer/tls/server.key
- ORDERER_GENERAL_CLUSTER_ROOTCAS=[/var/hyperledger/orderer/tls/ca.crt]
elect的时候没有报错，但是创建channel的时候没有设置authclient
peer channel create -o orderer.example.com:7050 -c mychannel -f ./channel-artifacts/channel.tx --tls true --cafile /root/go/src/github.com/hyperledger/fabric-samples/first-network/crypto-config/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
我没有设置authclient，又遇到一个错误
TLS handshake failed with error tls: client didn't provide a certificate server=Orderer remoteaddress=192.168.192.11:57372
所以我改变了我的命令
peer channel create -o orderer.example.com:7050 -c mychannel -f ./channel-artifacts/channel.tx --tls true --cafile /root/go/src/github.com/hyperledger/fabric-samples/first-network/crypto-config/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem --clientauth --certfile /root/go/src/github.com/hyperledger/fabric-samples/first-network/crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/server.crt --keyfile /root/go/src/github.com/hyperledger/fabric-samples/first-network/crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/server.key
执行成功，你可以看到 --certfile 值是对端的 server.crt 和 --keyfile 值是对端的服务器密钥。
所以我认为你遇到的问题是客户端tls引起的，你可以检查客户端crt和密钥是否正确。
希望这些对你有用。
我看到有很多关于这个错误的问题，我已经看到了这个解决方案
这是我到目前为止所做的：
我使用 configtx.yaml 和这个 msp 文件夹结构创建了我的创世块：
configtx.yaml
Organizations:
- &ordererOrg
Name: orderer
ID: orderer
MSPDir: /crypto/msp
Policies:
Readers:
Type: Signature
Rule: "OR('orderer.member')"
Writers:
Type: Signature
Rule: "OR('orderer.member')"
Admins:
Type: Signature
Rule: "OR('orderer.admin')"
Capabilities:
Channel: &ChannelCapabilities
V1_4_3: true
Orderer: &OrdererCapabilities
V1_4_2: true
Application: &ApplicationCapabilities
V1_4_2: true
Application: &ApplicationDefaults
Organizations:
Policies:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
Capabilities:
<<: *ApplicationCapabilities
Orderer: &OrdererDefaults
OrdererType: solo
BatchTimeout: 2s
BatchSize:
MaxMessageCount: 10
AbsoluteMaxBytes: 99 MB
PreferredMaxBytes: 512 KB
Kafka:
Brokers:
- 127.0.0.1:9092
Organizations:
Policies:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
BlockValidation:
Type: ImplicitMeta
Rule: "ANY Writers"
Channel: &ChannelDefaults
Policies:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
Capabilities:
<<: *ChannelCapabilities
Profiles:
SampleEtcdRaftProfile:
<<: *ChannelDefaults
Capabilities:
<<: *ChannelCapabilities
Orderer:
<<: *OrdererDefaults
OrdererType: etcdraft
Addresses:
- orderer1.xxxx.eastus.aksapp.io:443
- orderer2.xxxx.eastus.aksapp.io:443
Organizations:
- *ordererOrg
EtcdRaft:
Consenters:
- Host: orderer1
Port: 7050
ClientTLSCert: /crypto/orderers/orderer1/tls/server.crt
ServerTLSCert: /crypto/orderers/orderer1/tls/server.crt
- Host: orderer2
Port: 7050
ClientTLSCert: /crypto/orderers/orderer2/tls/server.crt
ServerTLSCert: /crypto/orderers/orderer2/tls/server.crt
Capabilities:
<<: *OrdererCapabilities
Application:
<<: *ApplicationDefaults
Organizations:
- <<: *ordererOrg
Consortiums:
SampleConsortium:
Organizations:
- *ordererOrg
MSP 文件夹结构：
+ /crypto
configtx.yaml
+ msp
+ cacerts > ca.crt
+ tlscacerts > ca.crt
+ intermediatecerts > intermediate.crt
+ tlsintermediatecerts > intermediate.crt
+ admincerts > admin.crt
+ orderers
+ orderer1/tls > server.crt
+ orderer2/tls > server.crt
我用这个创建了我的创世块：
configtxgen -profile SampleEtcdRaftProfile -outputBlock genesis.block -channelID mychannel
现在我在订购者内部怀疑 msp 结构是这样的：
+ /var/hyperledger/orderer
genesis.block
+ msp
+ cacerts > ca.crt
+ intermediatecerts > intermediate.crt
+ admincerts > admin.crt
+ signcerts > cert.pem
+ keystore > key.pem
+ tls
server.crt
server.key
ca.crt
intermediate.crt
这些是我的环境变量：
ORDERER_GENERAL_TLS_ENABLED=true
ORDERER_GENERAL_TLS_PRIVATEKEY=/var/hyperledger/orderer/tls/server.key
ORDERER_GENERAL_TLS_CERTIFICATE=/var/hyperledger/orderer/tls/server.crt
ORDERER_GENERAL_TLS_CLIENTROOTCAS=/var/hyperledger/orderer/tls/ca.crt
ORDERER_GENERAL_TLS_CLIENTAUTHREQUIRED=false
ORDERER_GENERAL_CLUSTER_CLIENTPRIVATEKEY=/var/hyperledger/orderer/tls/server.key
ORDERER_GENERAL_CLUSTER_CLIENTCERTIFICATE=/var/hyperledger/orderer/tls/server.crt
ORDERER_GENERAL_CLUSTER_ROOTCAS=/var/hyperledger/orderer/tls/ca.crt
我不确定为什么结构不同并且 tls 文件在其他地方，但我正在从我已经成功使用的 azure hyperledger template 复制配置。
现在我的排序节点是 运行，但是排序节点 1 一直在开始新的选举，排序节点 2 成为候选者并最终因 TLS 握手错误而失败。
这些是 orderer2 中的错误日志：
2021-03-23 22:15:21.969 UTC [orderer.consensus.etcdraft] Step -> INFO f96 2 is starting a new election at term 1 channel=canalenergia node=2
2021-03-23 22:15:21.969 UTC [orderer.consensus.etcdraft] becomePreCandidate -> INFO f97 2 became pre-candidate at term 1 channel=canalenergia node=2
2021-03-23 22:15:21.969 UTC [orderer.consensus.etcdraft] poll -> INFO f98 2 received MsgPreVoteResp from 2 at term 1 channel=canalenergia node=2
2021-03-23 22:15:21.969 UTC [orderer.consensus.etcdraft] campaign -> INFO f99 2 [logterm: 1, index: 2] sent MsgPreVote request to 1 at term 1 channel=canalenergia node=2
2021-03-23 22:15:26.673 UTC [core.comm] ServerHandshake -> ERRO f9a TLS handshake failed with error remote error: tls: bad certificate server=Orderer remoteaddress=x.x.x.x:45472
我尝试删除 intermediate.crt 并将 ca.crt 和 intermediate.crt 混合到订购者 tls 文件夹中 ca.crt 中的一个文件中，如下所示：
-----BEGIN CERTIFICATE-----
ROOTCERTxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
INTERMEDIATExxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
-----END CERTIFICATE-----
但是也没用。
我尝试了 openssl verify -CAfile chain.crt orderer1-tls.crt 和 returns OK。
这是我尝试创建新频道时发生的情况：
peer channel create -o orderer1.xxxx.eastus.aksapp.io -c testchannel -f ./channel.tx --tls --cafile /var/hyperledger/peer/msp/tlscacerts/ca.crt --clientauth --certfile /var/hyperledger/peer/tls/cert.pem --keyfile /var/hyperledger/peer/tls/key.pem
2021-03-24 00:04:40.331 UTC [comm.tls] ClientHandshake -> ERRO 001 Client TLS handshake failed after 939.077µs with error: EOF remoteaddress=x.x.x.x:443
我用 telnet 测试了我的 url，它们没问题。
我使用 openSSL 创建了我的证书，但我没有发现它们有任何问题，唯一的区别是它们不是由 fabric-ca 签署的，而是由一家大公司的中间 CA 签署的。
我已经仔细检查了所有的值，但我猜 orderer 甚至不会是 运行 如果它们不正确并遵循这个 script 来自 azure 仅用于创建创世块添加中间信息。
任何建议都很好。
谢谢
更新：
我用这个变量激活了调试日志：
FABRIC_LOGGING_SPEC="grpc=debug:info"
发现问题是这样的：
传输：身份验证握手失败：x509：证书对任何名称均无效，但希望匹配 orderer1
我的证书有这个主题：
CN=orderer1-tls@blockchain.company.com,O=公司,L=城市,ST=州,C=美国
现在，我不明白为什么它告诉我它没有名字，我虽然 CN orderer1-tls@blockchain.company.com 是名字，而且，还有，我在哪里告诉要搜索的名称是“orderer1”的订购者？
更新 2：
我将我的 TLS 证书更改为 CN=orderer.company.com 然后错误是这样的：
x509: certificate is valid for orderer1.company.com, not orderer1
正如李可以所说，订购者需要证书 CN 中的主机名，而我的主机名是 orderer1，所以我将其更改为那个。
现在我收到一个新错误：
UTC [comm.grpc.server] 1 -> INFO 118 streaming call completed grpc.service=orderer.Cluster grpc.method=Step grpc.peer_address=x.x.x.x:39424 error="no TLS certificate sent" grpc.code=Unknown grpc.call_duration=161.713µs
我想这是一个新错误，所以我要开一个新问题。谢谢！
安娜
我在学习的时候遇到了同样的问题fabric.and我已经解决了，希望能帮到你
例如，当你在linux终端执行时
export CORE_PEER_TLS_ENABLED=true
export CORE_PEER_LOCALMSPID="Org1MSP"
export CORE_PEER_TLS_ROOTCERT_FILE=/home/www/byfn-on-k8s/crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt
export CORE_PEER_MSPCONFIGPATH=/home/www/byfn-on-k8s/crypto-config/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
export CORE_PEER_ADDRESS=peer0.org1.example.com:30011
peer channe list
你会得到正确的结果
并将 CORE_PEER_ADDRESS 更改为 exmaple.com(example.com link 与 peer0.org1.example.com 相同的 ip，您可以通过编辑 /etc/hosts),
export CORE_PEER_ADDRESS=example.com:30011
peer channe list
并且您将在对等日志中收到错误“TLS 握手失败并出现错误远程错误：tls：错误的证书服务器=PeerServer”
但这不是遇到错误“tls：错误证书”的唯一场景，
我认为这个错误是由“主机名验证”引起的
例如，你想访问对等点peer0.org1.example.com，这个对等点启用服务器tls，你可以找到server.crt和server.key 在对等环境中。
如果你解析server.crt，你会发现这个crt的CN是“peer0.org1.example.com”
当你联系对等点“peer0.org1.example.com”时，对等点会把它的证书发给你，你发现这个证书的CN是“peer0.org1.example.com” ,所以你信任这个服务器,
但是当你联系“example.com”（指向与 peer0.org1 相同的 IP。example.com），并且对等方向你发送它的证书时，你会发现证书的 CN 是“peer0.org1.example.com”，id 不等于“example.com”，所以你不信任这个服务器并得到错误。
我认为新错误“未发送 TLS 证书”是由您在订购者环境中设置 CORE_PEER_TLS_CLIENTAUTHREQUIRED=true 引起的。
所以我尝试在 CORE_PEER_TLS_CLIENTAUTHREQUIRED=true 时进行测试，当 raft elect 时我遇到另一个错误“tls:bad certificate”，所以我像这样更改排序者环境：
- ORDERER_GENERAL_TLS_ENABLED=true
- ORDERER_GENERAL_TLS_PRIVATEKEY=/var/hyperledger/orderer/tls/server.key
- ORDERER_GENERAL_TLS_CERTIFICATE=/var/hyperledger/orderer/tls/server.crt
- ORDERER_GENERAL_TLS_ROOTCAS=[/var/hyperledger/orderer/tls/ca.crt]
- ORDERER_KAFKA_TOPIC_REPLICATIONFACTOR=1
- ORDERER_KAFKA_VERBOSE=true
- ORDERER_GENERAL_TLS_CLIENTAUTHREQUIRED=true
- ORDERER_GENERAL_TLS_CLIENTROOTCAS=/var/hyperledger/orderer/tls/ca.crt
- ORDERER_GENERAL_CLUSTER_CLIENTCERTIFICATE=/var/hyperledger/orderer/tls/server.crt
- ORDERER_GENERAL_CLUSTER_CLIENTPRIVATEKEY=/var/hyperledger/orderer/tls/server.key
- ORDERER_GENERAL_CLUSTER_ROOTCAS=[/var/hyperledger/orderer/tls/ca.crt]
elect的时候没有报错，但是创建channel的时候没有设置authclient
peer channel create -o orderer.example.com:7050 -c mychannel -f ./channel-artifacts/channel.tx --tls true --cafile /root/go/src/github.com/hyperledger/fabric-samples/first-network/crypto-config/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
我没有设置authclient，又遇到一个错误
TLS handshake failed with error tls: client didn't provide a certificate server=Orderer remoteaddress=192.168.192.11:57372
所以我改变了我的命令
peer channel create -o orderer.example.com:7050 -c mychannel -f ./channel-artifacts/channel.tx --tls true --cafile /root/go/src/github.com/hyperledger/fabric-samples/first-network/crypto-config/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem --clientauth --certfile /root/go/src/github.com/hyperledger/fabric-samples/first-network/crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/server.crt --keyfile /root/go/src/github.com/hyperledger/fabric-samples/first-network/crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/server.key
执行成功，你可以看到 --certfile 值是对端的 server.crt 和 --keyfile 值是对端的服务器密钥。
所以我认为你遇到的问题是客户端tls引起的，你可以检查客户端crt和密钥是否正确。
希望这些对你有用。