Hyperledger fabric TLS握手失败，错误为远程错误：TLS:bad certificate server=订购方使用Raft和中间证书_Hyperledger Fabric_Tls1.2

Hyperledger fabric TLS握手失败，错误为远程错误：TLS:bad certificate server=订购方使用Raft和中间证书

hyperledger-fabric

Hyperledger fabric TLS握手失败，错误为远程错误：TLS:bad certificate server=订购方使用Raft和中间证书,hyperledger-fabric,tls1.2,Hyperledger Fabric,Tls1.2,我看到有很多关于这个错误的问题，我看到了这个解决方案，但我仔细检查了文件夹是否正确，证书是否在那里，我也查看了，但据我所知，我在使用Raft时不需要SAN（我可能错了）。我认为我的问题是因为我没有正确地处理中间证书，并且我在创建一个通道和在内存中都遇到了错误以下是我到目前为止所做的：我使用configtx.yaml和此msp文件夹结构创建了genesis块： + /crypto configtx.yaml + msp + cacerts > ca.crt + t

我看到有很多关于这个错误的问题，我看到了这个解决方案，但我仔细检查了文件夹是否正确，证书是否在那里，我也查看了，但据我所知，我在使用Raft时不需要SAN（我可能错了）。我认为我的问题是因为我没有正确地处理中间证书，并且我在创建一个通道和在内存中都遇到了错误

以下是我到目前为止所做的：

我使用configtx.yaml和此msp文件夹结构创建了genesis块：

+ /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

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

我使用以下方法创建了我的genesis块：

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文件在其他地方，但我正在复制我已经成功使用的配置

现在，我的订购者正在运行，但订购者1继续启动新的选择，订购者2变得不稳定，最终由于TLS握手错误而失败

以下是Order2中的错误日志：

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的一个文件中，如下所示：

+ /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

但它也不起作用

我尝试了openssl验证-CAfile chain.crt order1-tls.crt并返回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甚至不会运行，并且从azure开始创建genesis块，只添加中间信息

任何建议都很好

谢谢

更新：

我使用此变量激活了调试日志：

FABRIC_LOGGING_SPEC="grpc=debug:info"

发现问题在于：

传输：身份验证握手失败：x509:证书对任何名称都无效，但希望与Order1匹配

我的证书有以下主题：

CN=订购者1-tls@blockchain.company.com，O=公司，L=城市，ST=州，C=美国

现在，我不明白为什么它告诉我它没有名字，我想CN订购者1-tls@blockchain.company.com是名称，还有，我在哪里告诉订购者要搜索的名称是“订购者1”

更新2:

我将TLS证书更改为CN=order.company.com，然后错误如下：

x509: certificate is valid for orderer1.company.com, not orderer1

以便李可以说明，订购方希望证书CN中有主机名，而我的主机名是Order1，因此我将其更改为

现在我得到一个新的错误：

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

我想这是一个新的错误，所以我要提出一个新的问题。谢谢

Ana

我在学习织物的时候也遇到了同样的问题，我已经解决了，希望这能对你有所帮助

例如，当您在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_地址更改为exmaple.com（example.com将相同的ip链接到peer0.org1.example.com，您可以通过编辑/etc/hosts进行设置）

您将在对等日志中看到错误“TLS握手失败，错误为远程错误：TLS:bad certificate server=PeerServer”

但这并不是您遇到错误“tls:bad certificate”的唯一场景

我认为这个错误是由“主机名眩晕”引起的

例如，您希望访问peerpeer0.org1.example.com，并且该peer启用服务器tls，您可以在peer env中找到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.example.com相同的IP），并且对等方向您发送其证书时，您会发现证书的CN为“peer0.org1.example.com”，id不等于“example.com”，因此您不信任此服务器并出现错误。