1. Error
To update my channel config (called identitych), I fetched, translated, modified, and re-encoded channel config file by following the guide in the official document.
At the last step, I tried to submit my channel config update with the following command.
peer channel update -f config_update_in_envelope.pb -c identitych -o orderer1.common.bpl:7050 --tls --cafile /orderers/admin-ca/msp/tlscacerts/ca-cert.pem
But, I failed with the following error.
2021-09-02 12:52:53.987 UTC [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized
Error: got unexpected status: BAD_REQUEST -- error applying config update to existing channel 'identitych': error authorizing update: error validating DeltaSet: policy for [Value] /Channel/Orderer/ConsensusType not satisfied: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Admins' sub-policies to be satisfied
Error message from the logs recorded by orderer1.common.bpl is like below. I could not find any relevant error messages except this message.
2021-09-02 12:52:53.993 UTC [orderer.common.broadcast] ProcessMessage -> WARN 54f6 [channel: identitych] Rejecting broadcast of config message from 10.0.1.104:54556 because of error: error applying config update to existing channel 'identitych': error authorizing update: error validating DeltaSet: policy for [Value] /Channel/Orderer/ConsensusType not satisfied: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Admins' sub-policies to be satisfied
2021-09-02 12:52:53.993 UTC [comm.grpc.server] 1 -> INFO 54f7 streaming call completed grpc.service=orderer.AtomicBroadcast grpc.method=Broadcast grpc.peer_address=10.0.1.104:54556 grpc.code=OK grpc.call_duration=2.028426ms
2. My setting
To use peer update command, I used a cli docker container, which had been created by the following command:
docker container run -it --rm --name cli \
--log-driver json-file --log-opt max-size=1g --log-opt max-file=1 \
-e GOPATH=/opt/gopath \
-e CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock \
-e FABRIC_LOGGING_SPEC=INFO \
-e CORE_PEER_ID=cli \
-e CORE_PEER_ADDRESS=peer3.identity.common.bpl:7051 \
-e CORE_PEER_LOCALMSPID=BPLMSP \
-e CORE_PEER_MSPCONFIGPATH=/peers/admin-org/msp \
-e CORE_PEER_TLS_ENABLED=true \
-e CORE_PEER_TLS_KEY_FILE=/peers/peer3.identity.common.bpl/tls/keystore/key.pem \
-e CORE_PEER_TLS_CERT_FILE=/peers/peer3.identity.common.bpl/tls/signcerts/cert.pem \
-e CORE_PEER_TLS_ROOTCERT_FILE=/peers/peer3.identity.common.bpl/tls/tlscacerts/ca-cert.pem \
-w="/peers" \
-v /var/run/:/host/var/run/ \
-v "$(pwd)"/peers:/peers \
-v "$(pwd)"/channel-artifacts:/channel-artifacts \
-v "$(pwd)"/chaincodes:/chaincodes \
-v "$(pwd)"/orderers:/orderers \
-v "$(pwd)"/scripts:/scripts \
--network $NETWORK \
hyperledger/fabric-tools:$VERSION /bin/bash
As you can see in the above script, this cli container starts with necessary environment variable settings(such as CORE_PEER_TLS_...) to connect the target peer. Also, CORE_PEER_MSPCONFIGPATH pointed the admin user's msp directory.
By following the answer of the previous question in stackoverflow, I checked my admin user's cert is correct.
At the root location of my admin user's msp directory, config.yaml had been placed and its content is like below:
NodeOUs:
Enable: true
ClientOUIdentifier:
Certificate: "cacerts/cacert.pem"
OrganizationalUnitIdentifier: "client"
AdminOUIdentifier:
Certificate: "cacerts/cacert.pem"
OrganizationalUnitIdentifier: "admin"
PeerOUIdentifier:
Certificate: "cacerts/cacert.pem"
OrganizationalUnitIdentifier: "peer"
OrdererOUIdentifier:
Certificate: "cacerts/cacert.pem"
OrganizationalUnitIdentifier: "orderer"
So, its OU setting looks correct.
Then, I checked my admin user's signcerts/cert.pem using openssl command.
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
...
Signature Algorithm: ecdsa-with-SHA256
Issuer: C=KR, ST=Daejeon, O=bigpicturelabs, CN=ca.peer.common.bpl
Validity
Not Before: Sep 2 12:47:00 2021 GMT
Not After : Sep 4 04:51:00 2035 GMT
Subject: C=KR, ST=Daejeon, O=bigpicturelabs, OU=admin, CN=bpl-peer-admin
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
...
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
...
1.2.3.4.5.6.7.8.1:
{"attrs":{"hf.Affiliation":"","hf.EnrollmentID":"bpl-peer-admin","hf.Type":"admin"}}
...
From Subject section, I could confirm that its OU value had been set correctly as admin and CN also had been set correctly. So far, everything looks like good.
Then, I validated my admin user's cert against the root certificate extracted from the channel config. The way to do it was introduced at the above question in stackoverflow. And, again, I got the correct answer.
> openssl verify -CAfile root.pem ./admin-org/msp/signcerts/cert.pem
./admin-org/msp/signcerts/cert.pem: OK
Then, finally, I checked the configtx.yaml content.
Organizations:
- &BPLOrdererOrg
Name: BPLOrdererMSP
ID: BPLOrdererMSP
MSPDir: ./orderers/admin-ca/msp
Policies:
Readers:
Type: Signature
Rule: "OR('BPLOrdererMSP.member')"
Writers:
Type: Signature
Rule: "OR('BPLOrdererMSP.member')"
Admins:
Type: Signature
Rule: "OR('BPLOrdererMSP.admin')"
OrdererEndpoints:
- orderer0.common.bpl:7050
- &BPLOrg
Name: BPLMSP
ID: BPLMSP
MSPDir: ./peers/admin-ca/msp
Policies:
Readers:
Type: Signature
Rule: "OR('BPLMSP.admin', 'BPLMSP.peer', 'BPLMSP.client')"
Writers:
Type: Signature
Rule: "OR('BPLMSP.admin', 'BPLMSP.client')"
Admins:
Type: Signature
Rule: "OR('BPLMSP.admin')"
Endorsement:
Type: Signature
Rule: "OR('BPLMSP.peer')"
AnchorPeers:
- Host: peer0.identity.common.bpl
Port: 7051
Capabilities:
Channel: &ChannelCapabilities
V2_0: true
Orderer: &OrdererCapabilities
V2_0: true
Application: &ApplicationCapabilities
V2_0: true
Application: &ApplicationDefaults
Organizations:
Policies:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
LifecycleEndorsement:
Type: ImplicitMeta
Rule: "MAJORITY Endorsement"
Endorsement:
Type: ImplicitMeta
Rule: "MAJORITY Endorsement"
Capabilities:
<<: *ApplicationCapabilities
Orderer: &OrdererDefaults
OrdererType: etcdraft
EtcdRaft:
Consenters:
- Host: orderer0.common.bpl
Port: 7050
ClientTLSCert: ./orderers/orderer0.common.bpl/tls/signcerts/cert.pem
ServerTLSCert: ./orderers/orderer0.common.bpl/tls/signcerts/cert.pem
- Host: orderer1.common.bpl
Port: 7050
ClientTLSCert: ./orderers/orderer1.common.bpl/tls/signcerts/cert.pem
ServerTLSCert: ./orderers/orderer1.common.bpl/tls/signcerts/cert.pem
- Host: orderer2.common.bpl
Port: 7050
ClientTLSCert: ./orderers/orderer2.common.bpl/tls/signcerts/cert.pem
ServerTLSCert: ./orderers/orderer2.common.bpl/tls/signcerts/cert.pem
BatchTimeout: 0.5s
BatchSize:
MaxMessageCount: 100
AbsoluteMaxBytes: 99 MB
PreferredMaxBytes: 512 KB
Organizations:
Policies:
...
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
...
Channel: &ChannelDefaults
Policies:
...
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
Capabilities:
<<: *ChannelCapabilities
...
Again, I could not find any problem from my configuration file.
3. Question
Is there any point that I'm missing? Where should I investigate to solve this problem?
Thanks.
