I'm getting this error when i am trying to create a channel by running .
peer channel create -o orderer.aj.io:7050 -c channel1 -f /config/channel1.tx
Here are my logs ------------
2019-10-21 05:50:13.950 UTC [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized
Error: got unexpected status: FORBIDDEN -- implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Writers' sub-policies to be satisfied: permission denied
What this error means is that the user you are using to create the channel does not have 'Write' permissions, in other words is not an Admin.
In most cases this happens when you use the peers cryptographic material to create the channel instead of the Admins (check where the CORE_PEER_MSPCONFIGPATH environment variable points).
As another user mentioned in another post: there is a new feature in 1.4.3 which allows you to specify an OU for admin rather than explicitly putting certificates in the admincerts folder.
In your crypto-config, you set EnableNodeOUs: true and this automatically enables OUs for all supported roles.
You'll see something like
NodeOUs:
Enable: true
ClientOUIdentifier:
Certificate: cacerts/ca.sampleorg-cert.pem
OrganizationalUnitIdentifier: client
PeerOUIdentifier:
Certificate: cacerts/ca.sampleorg-cert.pem
OrganizationalUnitIdentifier: peer
AdminOUIdentifier:
Certificate: cacerts/ca.sampleorg-cert.pem
OrganizationalUnitIdentifier: admin
OrdererOUIdentifier:
Certificate: cacerts/ca.sampleorg-cert.pem
OrganizationalUnitIdentifier: orderer
in the msp/config.yaml file ( in your case in crypto-config/peerorganisation/org1.example.com/msp/crypto.yaml).
Note the AdminOUIdentifier field. This means that any cert issued by the CA for your org which contains an OU=admin is now considered an admin. The certificate generated for the admin user under your org MSP is also generated with OU=admin (e.g. Subject: C=US, ST=California, L=San Francisco, OU=admin, CN=Admin#sampleorg ).
Another reason could be that in your configtx.yaml you haven't set properly your policies for each section(that was my problem).
Check the configtx.yaml file from the first-network sample and try to set them accordingly
Related
I'm trying Fabric v2.2 and keeps failed to join a peer to channel because of some policies problem (I guess). To get MSPs of orderers and peers, I used CAs of an orderer organization and a peer organization (there is one peer organization).
fabric-ca-client register -d --id.name ${PEERS[$i]} --id.secret ${PEER_ADMIN_PWS[$i]} --id.type peer -u https://$CA_NODE:7054
…
fabric-ca-client register -d --id.name $ORG_ADMIN_ID --id.secret $ORG_ADMIN_PW --id.type admin -u https://$CA_NODE:7054
….
fabric-ca-client register -d --id.name ${ORDERERS[$i]} --id.secret ${ORDERER_ADMIN_PWS[$i]} --id.type orderer -u https://$CA_NODE:7054
…
fabric-ca-client enroll -d -u https://${NODES[$i]}:${NODE_ADMIN_PWS[$i]}#$CA_NODE:7054
I think MSPs were okay because the network was up well.
Then, I launched a CLI container and create a channel called identitych. I think it worked well because I checked the identitych directory had been created under chains directory of all orderers.
After that, when I proposed to join a peer to a channel with the following command, the orderer could not deliver a block to a peer because of the permission denied and a peer could not retrieve a block from the orderer because of FORBIDDEN problem.
peer channel join -b /channel-artifacts/identitych.block
My configtx.yaml file looks like:
Organizations:
- &BPLOrdererOrg
Name: BPLOrdererMSP
ID: BPLOrdererMSP
MSPDir: ./orderers/org-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/org-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')"
NodeOUs is enabled by placing config.yaml on msp directory of each orderer and peer.
# config.yaml
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"
Repeatedly, the orderer prints the following warning:
2020-08-20 11:35:08.041 UTC [comm.grpc.server] 1 -> INFO 0c3 streaming call completed grpc.service=orderer.AtomicBroadcast grpc.method=Deliver grpc.peer_address=172.24.0.11:42642 grpc.code=OK grpc.call_duration=792.5µs
2020-08-20 11:35:15.176 UTC [common.deliver] deliverBlocks -> WARN 0c4 [channel: identitych] Client 172.24.0.8:60236 is not authorized: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Readers' sub-policies to be satisfied: permission denied
At the same time, a peer repeatedly prints the following warning too:
2020-08-20 11:34:28.604 UTC [peer.blocksprovider] DeliverBlocks -> WARN 02b Got error while attempting to receive blocks: received bad status FORBIDDEN from orderer channel=identitych orderer-address=orderer0.common.bpl:7050
2020-08-20 11:34:28.604 UTC [peer.blocksprovider] func1 -> WARN 02c Encountered an error reading from deliver stream: EOF channel=identitych orderer-address=orderer0.common.bpl:7050
I found a similar question and answer (link) and I'm curious about the following quote:
Check for the Reader policies that you have defined in your configtx.yaml this error is generated because of the policy mismatch. You have defined some specific user type(admin, peer, client) in your Reader policies but this specific user type is not passed into certificates that you have generated for your peer.
I agree with that my problem is because of the policy mismatch, but I don't understand the following mention:
but this specific user type is not passed into certificates that you have generated for your peer.
How can I solve my issue? Thanks, in advance.
It looks like you've not enabled NodeOUs for the MSP definitions included in the channel configuration.
NodeOUs is enabled by placing config.yaml on msp directory of each orderer and peer.
This will enable NodeOU support in the 'local MSP' of the peer and orderer, but for channel operations, like invoking the Deliver API, it is the channel MSP definition which is utilized.
Make sure that you have placed your config.yaml in the MSP directory referenced by your configtx.yaml (for instance, in your case under ./peers/org-msp) before generating your genesis block for the orderer system channel.
Additional notes:
You can confirm that it is NodeOU related by changing the Readers policy in your configtx.yaml to refer to member for your peer org, like you have for the orderer org. If things work with the member policy, then this is definitely NodeOU related.
You could also turn up debugging for the policy evaluation by setting FABRIC_LOGGING_SPEC=info:cauthdsl=debug:policies=debug:msp=debug. This is generally too verbose for normal operation, but will give you a more clear audit trail of exactly what's causing the failure.
I am trying to add a new Orderer Organization to RAFT based existing ordering service. I am using the first-network from fabric-samples as the base network. While generating crypto-material, I have modified to generate crypto-material for 1 more orderer organization. The crypto-config.yaml looks like:
OrdererOrgs:
# ---------------------------------------------------------------------------
# Orderer
# ---------------------------------------------------------------------------
- Name: Orderer
Domain: example.com
EnableNodeOUs: true
# ---------------------------------------------------------------------------
# "Specs" - See PeerOrgs below for complete description
# ---------------------------------------------------------------------------
Specs:
- Hostname: orderer
- Hostname: orderer2
- Hostname: orderer3
- Hostname: orderer4
- Hostname: orderer5
- Name: Orderer1
Domain: example1.com
EnableNodeOUs: true
Specs:
- Hostname: orderer
- Hostname: orderer2
- Hostname: orderer3
# ---------------------------------------------------------------------------
# "PeerOrgs" - Definition of organizations managing peer nodes
# ---------------------------------------------------------------------------
PeerOrgs:
# ---------------------------------------------------------------------------
# Org1
# ---------------------------------------------------------------------------
- Name: Org1
Domain: org1.example.com
EnableNodeOUs: true
Template:
Count: 2
# Start: 5
# Hostname: {{.Prefix}}{{.Index}} # default
# ---------------------------------------------------------------------------
# "Users"
# ---------------------------------------------------------------------------
# Count: The number of user accounts _in addition_ to Admin
# ---------------------------------------------------------------------------
Users:
Count: 1
# ---------------------------------------------------------------------------
# Org2: See "Org1" for full specification
# ---------------------------------------------------------------------------
- Name: Org2
Domain: org2.example.com
EnableNodeOUs: true
Template:
Count: 2
Users:
Count: 1
Also, the configtx.yaml for creating new Orderer organization's MSP in JSON format is given as:
Organizations:
- &Orderer1Org
# DefaultOrg defines the organization which is used in the sampleconfig
# of the fabric.git development environment
Name: Orderer1Org
# ID to load the MSP definition as
ID: Orderer1MSP
MSPDir: ../crypto-config/ordererOrganizations/example1.com/msp
# Policies defines the set of policies at this level of the config tree
# For organization policies, their canonical path is usually
# /Channel/<Application|Orderer>/<OrgName>/<PolicyName>
Policies:
Readers:
Type: Signature
Rule: "OR('Orderer1MSP.member')"
Writers:
Type: Signature
Rule: "OR('Orderer1MSP.member')"
Admins:
Type: Signature
Rule: "OR('Orderer1MSP.admin')"
Then I boot up the the network using byfn.sh. Now I use the cli container to modify the system channel configuration in following steps:
First I add the organization's JSON to the Orderer group as follows and submit channel update:
jq -s '.[0] * {"channel_group":{"groups":{"Orderer":{"groups": {"Orderer1Org":.[1]}}}}}' config.json orderer1org.json > modified_config.json
Then I add organization's JSON to the Consortium group as follows and submit channel update:
jq -s '.[0] * {"channel_group":{"groups":{"Consortiums":{"groups":{"SampleConsortium":{"groups": {"Orderer1MSP":.[1]}}}}}}}' config1.json orderer1org.json > modified_config1.json
Then I add organization's orderer1 TLS certificates to Consenters section and submit channel update:
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
Then I update the system channel configuration's Application group with new Orderer Org's JSON:
jq -s '.[0] * {"channel_group":{"groups":{"Application":{"groups": {"Orderer1Org":.[1]}}}}}' config.json orderer1org.json > modified_config.json
Then I start one of the orderers in the new organization (orderer.example1.com) but the container is failing with following error:
2020-04-09 13:09:05.600 UTC [orderer.common.cluster.replication] fetchLastBlockSeq -> WARN 0e8 Received status:FORBIDDEN from orderer.example.com:7050: forbidden pulling the cha
nnel
2020-04-09 13:09:05.600 UTC [orderer.common.cluster.replication] func1 -> WARN 0e9 Received error of type 'forbidden pulling the channel' from {orderer.example.com:7050 [certs]}
The orderer.example.com logs throw this error:
2020-04-09 13:28:59.338 UTC [cauthdsl] deduplicate -> ERRO a3c Principal deserialization failure (the supplied identity is not valid: x509: certificate signed by unknown authorit
y) for identity 0
2020-04-09 13:28:59.338 UTC [cauthdsl] deduplicate -> ERRO a3d Principal deserialization failure (the supplied identity is not valid: x509: certificate signed by unknown authorit
y) for identity 0
2020-04-09 13:28:59.339 UTC [cauthdsl] deduplicate -> ERRO a3e Principal deserialization failure (the supplied identity is not valid: x509: certificate signed by unknown authorit
y) for identity 0
2020-04-09 13:28:59.340 UTC [cauthdsl] deduplicate -> ERRO a3f Principal deserialization failure (the supplied identity is not valid: x509: certificate signed by unknown authorit
y) for identity 0
2020-04-09 13:28:59.340 UTC [common.deliver] deliverBlocks -> WARN a40 [channel: byfn-sys-channel] Client authorization revoked for deliver request from 172.25.0.15:36196: implic
it policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Readers' sub-policies to be satisfied: permission denied
2020-04-09 13:28:59.341 UTC [comm.grpc.server] 1 -> INFO a41 streaming call completed grpc.service=orderer.AtomicBroadcast grpc.method=Deliver grpc.peer_address=172.25.0.15:36196
grpc.peer_subject="CN=orderer.example1.com,L=San Francisco,ST=California,C=US" grpc.code=OK grpc.call_duration=4.992078ms
I was able to extend the first-network by adding a new Orderer Organization as follows:
Start the first-network through the byfn.sh script in the fabric-samples repo in the etcdraft mode.
I generated crypto-material like described in the crypto-config.yaml in the question above.
Use the configtxgen tool to print the new orderer organization's MSP into JSON format.
Mount or docker cp this JSON file to the running cli container.
Set the environment inside the cli container corresponding to existing ordering node. Import the latest system-channel configuration. Decode it to JSON format.
Edit the system channel configuration block's Orderer section to add the new orderer organization's MSP as follows:
jq -s '.[0] * {"channel_group":{"groups":{"Orderer":{"groups": {"Orderer1Org":.[1]}}}}}' config.json orderer1org.json > config1.json
Edit the system channel configuration block's Consortiums section to add the new orderer organization's MSP as follows:
jq -s '.[0] * {"channel_group":{"groups":{"Consortiums":{"groups":{"SampleConsortium":{"groups": {"Orderer1MSP":.[1]}}}}}}}' config1.json orderer1org.json > config2.json
Edit the system channel configuration block's Consenters section to add the TLS credentials for the new orderer organization's orderer.example1.com node as follows:
cert=`base64 ../crypto/ordererOrganizations/example1.com/orderers/orderer.example1.com/tls/server.crt | sed ':a;N;$!ba;s/\n//g'`
cat config2.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_config.json
Encode the block, find delta, create channel update transaction, encode it as protobuf envelope and submit the channel update transaction.
Fetch the latest system channel configuration block.
Start one of the orderers (the one who was added to consenters list previously) using this latest fetched system channel configuration block as it's genesis.block file.
Perform docker exec into the cli container. Using the environment of an existing orderer node, fetch the latest system channel configuration.
Edit the system channel configuration block to add the new orderer's endpoint in the OrdererAddresses section as follows:
cat config.json | jq '.channel_group.values.OrdererAddresses.value.addresses += ["orderer.example1.com:7050"] ' > modified_config.json
Encode the block, find delta, create channel update transaction, encode it as protobuf envelope and get the block signed by Orderer1Org admin to satify the mod_policy for /Channel/OrdererAddresses resource which is set to Admins policy. This implicit meta policy expects the signature of MAJORITY Admins at that level of update. So, as the number of orderer organizations are 2 now, we need both the organization's admins to sign this system channel update transaction. Set the environment corresponding to Orderer1Org admin and run the following command:
peer channel signconfigtx -f ordorg_update_in_envelope.pb
Set the environment back to OrdererOrg admin and submit the channel update transaction. The peer channel update will automatically sign the transaction on behalf of OrdererOrg admin.
peer channel update -f ordorg_update_in_envelope.pb -c $CHANNEL_NAME -o orderer.example.com:7050 --tls true --cafile $ORDERER_CA
For updating any application channel, just replace the step 7 by updating the application channel configuration block's Application section to add the new orderer organization's MSP there.
Hope this helps!
I followed above sequence of steps to add new Orderer Organization into existing network, but channel (i.e updating config change to orderer channel) update throw error like below,
2020-09-29 00:53:49.794 UTC [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized
Error: got unexpected status: BAD_REQUEST -- error applying config update to existing channel 'e2e-orderer-syschan': error authorizing update: error validating DeltaSet: policy for [Value] /Channel/OrdererAddresses not satisfied: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Admins' sub-policies to be satisfied
I modified-json blocks by using below setup calls (tried mix/match combination of this below json change steps)
jq -s '.[0] * {"channel_group":{"groups":{"Application":{"groups": {"'${KL_NEW_ORDERER_NAME}'":.[1]}}}}}' config.json ${KL_NEW_ORDERER_NAME}.json > modified-config.json
jq -s '.[0] * {"channel_group":{"groups":{"Orderer":{"groups": {"'${KL_NEW_ORDERER_NAME}'":.[1]}}}}}' modified-config.json ${KL_NEW_ORDERER_NAME}.json > modified-config1.json
jq -s '.[0] * {"channel_group":{"groups":{"Consortiums":{"groups":{"'${KL_CONSORTIUM_NAME}'":{"groups": {"Orderermk01MSP":.[1]}}}}}}}' modified-config1.json ${KL_NEW_ORDERER_NAME}.json > modified-config2.json
LENGTH=$(jq '.channel_group.values.OrdererAddresses.value.addresses | length' modified-config2.json)
jq '.channel_group.values.OrdererAddresses.value.addresses['${LENGTH}'] |= "'${KL_NEW_ORDERER_URL}'"' modified-config2.json > modified-config3.json
cert=`base64 /hl-material/mk01-orderer/crypto-config/ordererOrganizations/${KL_DOMAIN}/orderers/orderer.mk01.${KL_DOMAIN}/tls/server.crt | sed ':a;N;$!ba;s/\n//g'`
cat modified-config3.json | jq '.channel_group.groups.Orderer.values.ConsensusType.value.metadata.consenters += [{"client_tls_cert": "'$cert'", "host": "raft0.mk01.'${KL_DOMAIN}'", "port": 32050, "server_tls_cert": "'$cert'"}] ' > modified-config4.json
My network setup based on HLF 2.2 LTS with 5 raft nodes under K8s cluster.
I have successful setup with multi channel, multiple peer organization on 2.2 LTS (know how to get this in dynamic way without bringdown any network). But now looking for scaling orderer organization into multiple cluster/orgs dynamically. Is any tip or update needed on above steps ? Thanks again
Mariya
I am migrating from kafka to raft, When I have changed state from "NORMAL" to "STATE_MAINTENANCE" and created the final expected envelope as per the procedure.
Note: We are using BYFN script
HF version: 1.4.3
My CLI pointed to Org1MSP, I signed config update transaction, later I changed CLI pointing to Org2MSP and signed, finally submitted the new channel config update to the orderer.After submission, getting a following error message.
Error on CLI: "Error: got unexpected status: BAD_REQUEST -- error applying config update to existing channel 'mychannel': 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"
Orderer log: "[channel: mychannel] Rejecting broadcast of config message from 172.21.0.13:51078 because of error: error applying config update to existing channel 'mychannel': 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"
Please let me know if I am doing something wrong.
Thanks in advance.
By default, cryptogen tool generate orderer admin user certificate with OU as client for 1.4.3 fabric version.
For peer admin user, it generates certificate with OU as admin which is correct(expected). In case of orderer, its creating wrong OU(Organization Unit) as client. We need to add the following part crypto-config.yaml in the orderer section.
CA:
OrganizationalUnit: admin
Once you added above part, recreate certificate and check orderer certificate OU as admin by following command
openssl x509 -in certificate.crt -text
AFAIK, hyperledger fabric 1.4.4 allow "NodeOUs" by creating a config.yaml file inside of a msp directory.
I am trying to join the network with local peer msp. But the network always return below error.
Error: proposal failed (err: bad proposal response 500: access denied for [JoinChain][myorg]: [Failed verifying that proposal's creator satisfies local MSP principal during channelless check policy with policy [Admins]: [The identity is not an admin under this MSP [MYORG]: The identity does not contain OU [ADMIN], MSP: [MYORG]]])
Also the structure of my peer's local msp directory have
msp
`- admincerts
`- cacerts
`- ca-cert.pem
`- signcerts
`- signcert.pem
`- keystore
`- secret
`- config.yaml
The contents of msp/config.yaml is like below.
NodeOUs:
Enable: true
ClientOUIdentifier:
Certificate: cacerts/ca-cert.pem
OrganizationalUnitIdentifier: client
PeerOUIdentifier:
Certificate: cacerts/ca-cert.pem
OrganizationalUnitIdentifier: peer
AdminOUIdentifier:
Certificate: cacerts/ca-cert.pem
OrganizationalUnitIdentifier: admin
OrdererOUIdentifier:
Certificate: cacerts/ca-cert.pem
OrganizationalUnitIdentifier: orderer
My guess is NodeOUs is worked because there is no problem booting up the peer without admincerts. So I think I need to configure channel join policies but I cannot find out any policy references.
Check for organization policies in your configtx.yaml which would be quite similar to this:
1. For orderer:
Readers:
Type: Signature
Rule: "OR('ordererMSP.member')"
Writers:
Type: Signature
Rule: "OR('ordererMSP.member')"
Admins:
Type: Signature
Rule: "OR('ordererMSP.member')"
2. For MYORG:
Readers:
Type: Signature
Rule: "OR('MYORGMsp.admin', 'MYORGMsp.peer', 'MYORGMsp.client')"
Writers:
Type: Signature
Rule: "OR('MYORGMsp.admin', 'MYORGMsp.client')"
Admins:
Type: Signature
Rule: "OR('MYORGMsp.admin','MYORGMsp.client')"
Now because the policies for orderer are generic so the genesis block creation works well. But the problem starts while peers try to join channel as the policies for the peer orgs are specific to user types which are either admin, peer or client.
So to resolve this you have to pass OU as either admin, peer, client or orderer to your certificates while enrolling them with Fabric-CA. Then only the certificate will be valid for doing particular operations using those certificates. Here is an example for generating admin certificate:
fabric-ca-client enroll --caname ca.example.com --csr.names C=SG,ST=Singapore,L=Singapore,O=$ORG_NAME,OU=admin -m admin -u http://admin:adminpw#localhost:$PORT
Check that the configtx.yaml you used has (at least):
Capabilities:
Channel: &ChannelCapabilities
V1_4_3: true
V1_1: true
In the client that you are using to join the peer, run (check the certificate path):
openssl x509 -text -noout -in $CORE_PEER_MSPCONFIGPATH/signcerts/signcert.pem
Check that OU includes admin.
You can also check that the certificate is signed by myorg's CA:
openssl verify -CAfile path-to-myorg-msp-as-specified-in-configtx-yaml/cacerts/ca-cert.pem $CORE_PEER_MSPCONFIGPATH/signcerts/signcert.pem
More information here: https://hyperledger-fabric.readthedocs.io/en/release-1.4/msp.html#identity-classification
I am getting below error when I network up. I have not changed anything in the first network code.
Error creating channelconfig bundle: initializing channelconfig
failed: could not create channel Consortiums sub-group config: setting
up the MSP manager failed: admin 0 is invalid: The identity is not
valid under this MSP [Org1MSP]: could not validate identity's OUs:
none of the identity's organizational units [[0xc420418960]] are in
MSP Org1MSP orderer.example.com | panic: Error creating
channelconfig bundle: initializing channelconfig failed: could not
create channel Consortiums sub-group config: setting up the MSP
manager failed: admin 0 is invalid: The identity is not valid under
this MSP [Org1MSP]: could not validate identity's OUs: none of the
identity's organizational units [[0xc420418960]] are in MSP Org1MSP
I think the answer to the question is that you use --id.type client while registering admin with CA, and if it doesnt work just put the config.yml file in the msp of every organisation with the contenet similar to
NodeOUs:
Enable: true
ClientOUIdentifier:
Certificate: cacerts/org2-ca-cert.pem
OrganizationalUnitIdentifier: client
PeerOUIdentifier:
Certificate: cacerts/org2-ca-cert.pem
OrganizationalUnitIdentifier: peer
i haven't tried id.type admin it might also work!