via lists.hyperledger.org" <christoph.buttler=ruhr-uni-bochum.de@...>To:
06/16/2020 03:57 AMSubject:
Fabric] Adding a new organisation to the system channel fails after FAB-17733
#fabric #fabric-orderer #raftSent by:
- Yes, with FAB-17733 implemented
you need to do it in 2 stages- first expand the organizations and then
add the new consenter.
- I guess it's possible to address
your problem by speculatively looking at how the root TLS CA will look
like after applying the config and not before it. Please open a new JIRA?
- I'm not sure why you can't specify
the intermediate certificates in the channel config for each organization?
we are using an architecture where there is a TLS root
CA and each organisation has its own intermediate TLS CA which is an immediate
child to the TLS root CA (realized with fabric-ca v1.4.7). We only want
to specify the TLS root CA certificate for any connection within
the network (e.g. for "peer channel update --cafile") and have
had some trouble achieving that in the first place. Our workaround is to
append their respective intermediate TLS CA certificates to all peer/orderer
TLS certificates building the proper chain of trust up to the TLS root
Now, when checking if we could upgrade to Hyperledger Fabric v2.1.1 (from
2.1.0), updating the system channel with a new organisation (including
a new orderer) fails with the error "x509: certificate signed by unknown
authority". We made sure that "tls_root_certs" and "tls_intermediate_certs"
both contain the correct certificates, but still faced the same error.
We believe to have tracked down the problem to FAB-17733 which adds a certificate
check when adding a new consenter to the raft configuration. Our configuration
update for the system channel contains both the "channel_group.groups.Orderer.groups"
definition for the new organisation as well as the new orderer in "channel_group.groups.Orderer.values.ConsensusType.consenters".
Could this be a problem? Should we first update the orderer group definition
and then add the new consenter?
Any pointers towards a fix are greatly appreciated. We would also love
to learn more about how peers/orderers handle TLS connections - especially
how they handle multiple CAs in their chain of trust - to be able to move
away from appending intermediate TLS CA certificates to build the chain
of trust manually.