向基于RAFT的Hyperledger Fabric网络添加Orderer Org遇权限错误

从你的错误日志和操作步骤来看，核心问题集中在证书信任链缺失和系统通道配置更新不完整/错误两个方面，下面分步拆解并给出修复方案：

一、错误原因分析 #

1. 证书信任失败：旧Orderer节点（orderer.example.com）无法验证新Orderer节点（orderer.example1.com）的身份，日志中x509: certificate signed by unknown authority说明旧Orderer的MSP信任根没有包含新Orderer1Org的CA证书，导致无法识别新节点的证书合法性。
2. 配置更新错误：你的操作中存在两处关键问题：
   • 错误地将Orderer组织（Orderer1Org）添加到了Application组（步骤4），Application组是Peer组织的专属区域，Orderer组织属于Orderer组，这一步完全多余且可能干扰权限验证。
   • 配置更新流程不规范：仅通过jq修改了JSON配置，但没有使用configtxlator工具生成合法的配置更新信封并完成签名提交，导致修改的配置没有真正生效到系统通道中。
3. 集群身份验证权限不足：新Orderer节点拉取区块时被拒绝（FORBIDDEN），本质是因为旧Orderer无法信任新节点的身份，同时系统通道中Orderer组的权限策略没有正确包含新组织的身份。

二、分步修复方案 #

1. 补全Orderer节点的信任根证书 #

所有现存的Orderer节点（orderer.example.com、orderer2.example.com等）需要信任新Orderer1Org的CA证书，操作如下：

• 将新组织的CA证书从crypto-config/ordererOrganizations/example1.com/msp/cacerts/ca.example1.com-cert.pem复制到每个旧Orderer节点的MSP信任目录：

  # 以orderer.example.com为例，其他节点同理
  cp crypto-config/ordererOrganizations/example1.com/msp/cacerts/ca.example1.com-cert.pem crypto-config/ordererOrganizations/example.com/orderers/orderer.example.com/msp/cacerts/
  

• 重启所有旧Orderer节点，让新的信任根生效。

2. 修正系统通道配置更新流程 #

重新执行规范的配置更新步骤，跳过错误的步骤4：

步骤1：拉取当前系统通道配置

在CLI容器中执行：

export CHANNEL_NAME=byfn-sys-channel
peer channel fetch config config_block.pb -o orderer.example.com:7050 -c $CHANNEL_NAME --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem

步骤2：将配置块转成JSON格式

configtxlator proto_decode --input config_block.pb --type common.Block | jq .data.data[0].payload.data.config > config.json

步骤3：添加新Orderer组织到Orderer组

使用jq将Orderer1Org的MSP定义合并到Orderer组：

# 先确保orderer1org.json是正确生成的MSP配置（通过configtxgen生成）
jq -s '.[0] * {"channel_group":{"groups":{"Orderer":{"groups": {"Orderer1MSP":.[1]}}}}}' config.json orderer1org.json > modified_config.json

注意：这里的组名要和你的MSP ID一致（Orderer1MSP），而非组织名称Orderer1Org。

步骤4：添加新组织到SampleConsortium

jq -s '.[0] * {"channel_group":{"groups":{"Consortiums":{"groups":{"SampleConsortium":{"groups": {"Orderer1MSP":.[1]}}}}}}}' modified_config.json orderer1org.json > modified_config1.json

步骤5：添加新Orderer节点到Consenters

cert=`base64 ../crypto/ordererOrganizations/example1.com/orderers/orderer.example1.com/tls/server.crt | sed ':a;N;$!ba;s/\n//g'`
cat modified_config1.json | jq '.channel_group.groups.Orderer.values.ConsensusType.value.metadata.consenters += [{"client_tls_cert": "'$cert'", "host": "orderer.example1.com", "port": 7050, "server_tls_cert": "'$cert'"}] ' > modified_config2.json

步骤6：生成配置更新信封

将原始配置和修改后的配置转成proto格式，计算差异并生成更新信封：

# 转原始配置为proto
configtxlator proto_encode --input config.json --type common.Config --output config.pb
# 转修改后的配置为proto
configtxlator proto_encode --input modified_config2.json --type common.Config --output modified_config.pb
# 计算配置差异
configtxlator compute_update --channel_id $CHANNEL_NAME --original config.pb --updated modified_config.pb --output config_update.pb
# 转差异为JSON
configtxlator proto_decode --input config_update.pb --type common.ConfigUpdate | jq . > config_update.json
# 封装成完整的配置更新交易
echo '{"payload":{"header":{"channel_header":{"channel_id":"'$CHANNEL_NAME'", "type":2}},"data":{"config_update":'$(cat config_update.json)'}}}' | jq . > config_update_in_envelope.json
# 转成proto格式的交易信封
configtxlator proto_encode --input config_update_in_envelope.json --type common.Envelope --output config_update_in_envelope.pb

步骤7：签名并提交配置更新

需要由Orderer组织的管理员签名（比如OrdererOrg的Admin和Orderer1Org的Admin），然后提交：

# 导入OrdererOrg Admin身份
export CORE_PEER_LOCALMSPID="OrdererMSP"
export CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
export CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/users/Admin@example.com/msp

# 签名配置更新
peer channel signconfigtx -f config_update_in_envelope.pb

# 切换到Orderer1Org Admin身份（根据你的加密材料路径调整）
export CORE_PEER_LOCALMSPID="Orderer1MSP"
export CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example1.com/orderers/orderer.example1.com/msp/tlscacerts/tlsca.example1.com-cert.pem
export CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example1.com/users/Admin@example1.com/msp

# 再次签名（根据通道策略要求的签名数量调整）
peer channel signconfigtx -f config_update_in_envelope.pb

# 提交配置更新
peer channel update -f config_update_in_envelope.pb -c $CHANNEL_NAME -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem

3. 修正新Orderer节点的启动配置 #

确保新Orderer节点的orderer.yaml配置正确：

• General.LocalMSPID设置为Orderer1MSP
• General.LocalMSPDir指向容器内的/var/hyperledger/orderer/msp（对应宿主机的crypto-config/ordererOrganizations/example1.com/orderers/orderer.example1.com/msp）
• General.TLS.Enabled设为true，并正确配置TLS证书路径
• General.BootstrapFile指向系统通道的创世块（可从旧Orderer节点复制）

4. 重新启动新Orderer节点 #

完成上述配置后，重新启动新Orderer节点，此时旧Orderer节点应该能验证新节点的身份，新节点也能正常拉取系统通道的区块。

内容的提问来源于stack exchange，提问作者Chintan Rajvir