hyperledger
peer: error validating proposal: access denied: channel [] creator org unknown, creator is malformed
Description
https://stackoverflow.com/questions/76480170/validating-proposal-access-denied-channel-creator-org-unknown-creator-is-m
Seems to be a newly introduced thing, maybe an additional field in the channel config is missing? Basically, I followed the procedure here:
https://hyperledgendary.github.io/unstable-fabric-docs/create_channel/create_channel_test_net.html#step-two-create-the-application-channel
2023-08-10 07:00:27.002 UTC 0001 INFO [channelCmd] InitCmdFactory -> Endorser and orderer connections initialized Error: proposal failed (err: rpc error: code = Unknown desc = error validating proposal: access denied: channel [] creator org unknown, creator is malformed)
The output indicates, setup of TLS and so on is ok?
Steps to reproduce
$ podman run --rm --env-file=peercli.env -v $(pwd):/opt docker.io/hyperledger/fabric-tools peer channel join -o orderer.example.com:7050 -b /opt/channel-artifacts/blue.pb 2023-08-10 07:00:27.002 UTC 0001 INFO [channelCmd] InitCmdFactory -> Endorser and orderer connections initialized Error: proposal failed (err: rpc error: code = Unknown desc = error validating proposal: access denied: channel [] creator org unknown, creator is malformed)
error description seems to be coming from:
https://github.com/hyperledger/fabric/blob/aa81271b8d4d7ade43cbbf2eb09b435896c12273/core/endorser/msgvalidation.go#L173
I found the issue by myself, pretty annoying:
https://hyperledger-fabric.readthedocs.io/en/release-2.5/channel_update_tutorial.html?highlight=anchor%20peer#fetch-the-configuration
tells how to fetch the configuration:
`
you can issue all of these commands at once
export PATH=${PWD}/../bin:$PATH export FABRIC_CFG_PATH=${PWD}/../config/ export CORE_PEER_TLS_ENABLED=true export CORE_PEER_LOCALMSPID="Org1MSP" export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org1.example.com/users/[email protected]/msp export CORE_PEER_ADDRESS=localhost:7051 ` the culprit is CORE_PEER_LOCALMSPID, because the quotation marks will be escaped and not removed, as you can see in orderer logfile:
[policies] SignatureSetToValidIdentities -> invalid identity error="MSP \"BlueOrgMSP\" is not defined on channel" identity="(mspid=\"BlueOrgMSP\" ...)
Two possibilities to fix:
- change the documentation only (at least the documentation would be correct)
- change the way configuration elements are read and strip (single and double) quotation marks if exist.
I am facing similar issue when I update an API client (developed in NodeJS) that is running perfectly fine with fabric-network library to fabric-gateway, pointing to the same network/peer.
The network is running Fabric v. 2.5.3.
When I try to run a getState transaction in a chaincode instantiated in a channel named ´ch´ I am getting this error:
Error: 9 FAILED_PRECONDITION: evaluate call to endorser returned error: error validating proposal: access denied: channel [ch] creator org unknown, creator is malformed.
Checking the peer logs it seems to be something related to PEM decoding while trying to decode this serialized-identity. The strange thing is that all PEMs (certificate and private key) configured (both in client and in peer) are from the same user and all with the same content:
WARN [endorser] Validate -> access denied channel=chbadges txID=654c86ca error="could not decode the PEM structure" errorVerbose="could not decode the PEM structure\ngithub.com/hyperledger/fabric/msp.(*bccspmsp).deserializeIdentityInternal\n\t/msp/mspimpl.go:401\ngithub.com/hyperledger/fabric/msp.(*bccspmsp).DeserializeIdentity\n\t/msp/mspimpl.go:393\ngithub.com/hyperledger/fabric/msp/cache.(*cachedMSP).DeserializeIdentity\n\t/msp/cache/cache.go:74\ngithub.com/hyperledger/fabric/msp.(*mspManagerImpl).DeserializeIdentity\n\t/msp/mspmgrimpl.go:98\ngithub.com/hyperledger/fabric/core/endorser.(*UnpackedProposal).Validate\n\t/core/endorser/msgvalidation.go:170\ngithub.com/hyperledger/fabric/core/endorser.(*Endorser).preProcess\n\t/core/endorser/endorser.go:258\ngithub.com/hyperledger/fabric/core/endorser.(*Endorser).ProcessProposal\n\t/core/endorser/endorser.go:335\ngithub.com/hyperledger/fabric/internal/pkg/gateway.(*EndorserServerAdapter).ProcessProposal\n\t/internal/pkg/gateway/gateway.go:41\ngithub.com/hyperledger/fabric/internal/pkg/gateway.(*Server).Evaluate.func1\n\t/internal/pkg/gateway/evaluate.go:64\nruntime.goexit\n\t/usr/local/go/src/runtime/asm_amd64.s:1598" identity="serialized-identity=0a076d6170614d535012c404fbefbef8110620d08445320520201313efbefbe3082021a308201c0a003020102021100df205ac8acbabbee0c7a16f73e5633a8300a06082a8648ce3d0403023073310b3009060355040613025553311330110603550408130a43616c69666f726e6961311630140603550407130d53616e204672616e636973636f31193017060355040a13106d6170612e6578616d706c652e636f6d311c301a0603550403131363612e6d6170612e6578616d706c652e636f6d301e170d3233303732383139333430305a170d3333303732353139333430305a305b310b3009060355040613025553311330110603550408130a43616c69666f726e6961311630140603550407130d53616e204672616e636973636f311f301d06035504030c1641646d696e406d6170612e6578616d706c652e636f6d3059301306072a8648ce3d020106082a8648ce3d03010703420004a86f0436339404d346f75bde017aff5adef6be66dbd45864d3937257c17a2262bacb740205bf64b2c40c97669a9b1eff17d709b337906d00a71f5e0a32265fb1a34d304b300e0603551d0f0101ff040403020780300c0603551d130101ff04023000302b0603551d2304243022802052ddf850507df06c35eda09a9dba5b5aa3f4ad51e538a30dfc25698cf691523a300a06082a8648ce3d0403020348003045022100b72a6a80d764f8708276fd5281fa4fb2b928d52a23b43b997eca5ec7eb41ae7e0220074159ebe648dc7f2cabbb97e079848ec439757bfbe0667e411c9f3ad5ab3e2840fbefbef8434308445320520201313efbefb"
I have already checked the CORE_PEER_LOCALMSPID and CORE_PEER_MSPCONFIGPATH environment variables in peer container and they are accurate too.
In the API client side, the credentials (both user certificate PEM, private key and mspID) are exactly the same ones configured into the peer's crypto-path and environment.
So I can say that I don't have a clue anymore where it might have a misconfiguration or what exactly to debug, look or check.
Ok, I have figured out what was wrong: I was trying to keep compatibility with the "old" JSON "wallet" format.
Passing the credentials as a Buffer instead of a string into the identity property to the gateway's connect function solves the problem.
Here is the code snippet for those who want to keep the compatibility back with the "User.id" JSON wallet file format (assuming 2 env vars: one to configure the wallet path and another the identity name to be used to transact, plus using more or less the same code structure used into asset-transfer-basic/application-gateway-typescript sample):
const walletPath = process.env.WALLET_PATH || '/opt/node/wallet';
const identity = process.env.IDENTITY || 'Admin';
const walletFile = fs.readFileSync(`${walletPath}/${identity}.id`, 'utf8');
const wallet = JSON.parse(walletFile);
const newIdentity: any = async () => {
const mspId = wallet.mspId;
const credentials = Buffer.from(wallet.credentials.certificate); // here is the "gotcha"
return { mspId, credentials };
}
const newSigner: any = async () => {
const privateKey = crypto.createPrivateKey(wallet.credentials.privateKey);
return signers.newPrivateKeySigner(privateKey);
}
Seems to be a newly introduced thing, maybe an additional field in the channel config is missing? Basically, I followed the procedure here:
https://hyperledgendary.github.io/unstable-fabric-docs/create_channel/create_channel_test_net.html#step-two-create-the-application-channel
Hello @rlfnb , I tried, but couldn't recreate issue, with fabric v2.5.6 using fabric-samples. I see its script still uses double quotes for CORE_PEER_LOCALMSPID
If this bug already fixed, @denyeart please close the issue and let me know if I can contribute on any good first issue.
I've updated the rest of the doc tutorials to remove the double quotes for CORE_PEER_LOCALMSPID, see https://github.com/hyperledger/fabric/pull/4841
