Search code examples
hyperledger-fabricblockchainhyperledgertls1.2client-certificates

Hyperledger Fabric Orderer - TLS Handshake Bad Certificate Issue


I'm developing an insurance application project that utilizes a hyperledger fabric network. I currently have a problem where my orderer nodes do not stay online for more than about 10 seconds before they crash. Inspecting the logs, there are a multitude of error messages suggesting that TLS certificates are not agreeing. The error messages do not seem to specify exactly what certificates are the faulting certificates in question however further up the logs is an error that says it could not match an expected certificate with a certificate that it found instead (Shown in this screenshot). While this error was also vague, I deduced that it was in fact comparing the orderer's public key certificate with the certificate within the locally stored genesis block. Upon inspection of the genesis block in the orderer node, it is indeed a completely different certificate. I have noticed that even after destroying the whole network from Docker and re-building the network, the certificate inside the genesis block of which is stored in the orderer nodes always remains exactly the same.

In terms of my network layout, I have 2 organizations. One for my orderer(s) and one for my peers. I also have 4 CA Servers (A CA and TLS CA Server for both the orderer organization and peer organization). I have 3 peer nodes and 3 orderer nodes.

Included below is a pastebin of the logs from orderer1 node before it crashes, and the GitHub repo

orderer1 logs - ``https://pastebin.com/AYcpAKHn

repo - ``https://github.com/Ewan99/InsurApp/tree/remake

NOTE: When running the app, first run ./destroy.sh, then ./build.sh

  • "iaorderer" is the org for my orderers
  • "iapeer" is the org for my peers

I've tried re-naming certificates incase they were being over-written by each other on creation. I tried reducing down from 3 orderers to 1 to see if it made any differences. Of course, in going from 3 to 1 orderers I changed from RAFT to solo, and still encountered the same problems


Solution

  • As per david_k's comment suggestion:

    Looks like you are using persistent volumes in docker, so do you prune these volumes when you start again from scatch if you don't then you can pick up data that doesn't match newly created crypto material

    I had to prune my old docker volumes as they were conflicting and providing newly built containers with older certificates