setting up the MSP manager failed: administrators must be declared when no admin ou classification is set.
CA Server seems fine. I register and enroll caadmin, orgadmin, ordereradmin. I create the genesis.block with orgadmin. orgadmin has admin in OU. orderer has OU=orderer.
It seems to use the config.yaml, as it gives a WARN on Failed loading ClientOU certificate. (Just a warning and not required, per the docs).
But even though I set the AdminOUIdentifier:
# Certificate: "cacerts/cacert.pem"
OrganizationalUnitIdentifier: "admin"
and the OrgAdmin has OU=admin in the subject, it errors and says no admin ou is set.
What am I missing?
The OU definition needs to be set like you are doing using config.yaml file. You need to define the OUs for every MSP in your channel, before creating the network. Then you start the network, such that the local MSPs (the MSP configurations of nodes: peers and orderers) also get this config.yaml in their MSP directories respectively.
This way, the NodeOUs will be enabled in the channel and the local MSPs of the nodes will also respect the same configuration.
If the NodeOUs are not set, then while creating the node containers, in the MSP directory that you mount inside the respective nodes, must have an admincerts sub-folder which will contain the certificate issued by the CA of that organization (or at least is a valid certificate in the chain of trust for that organization's MSP).
NOTE: If admincerts have been configured, i.e. the NodeOUs are disabled, then the Hyperledger Fabric network, will recognize only the identity of that organization holding the certificate present in the admincerts directory as the admin of that organization.
Related
I created a test network which has 2 orgs (each with one peer), 1 orderer in kubernetes using BAF. Orgs are joined in the channel called testchannel. Orderer msp, peer msp and tls certs expired within 1 day. Before it expired, I renewed all the certs using dcm tool and kept it in my local. First I updated the orderer tls cert in system channel and in application channel from orderer cli, by fetching the channel config, decoded, updated renewed orderer tls certs under consenters, encoded and updated the channel config using peer channel update command. I received a successfully submitted message.
Later replaced orderer msp, peer msp and tls certs in the vault and restarted all the services. When I checked the orderer logs, it didn't show any expiry error.
Now my network's previous certificate expired. Now it is using renewed certs. I am able to invoke and query transactions.
Now I want to add a new org called org3 to the existing (testchannel).
I created a new org (org3). When I tried to join that org to the channel, during peer channel update it failed. It shows the following error,
Error: got unexpected status: BAD_REQUEST -- error applying config update to existing channel 'testchannel': error authorizing update: error validating DeltaSet: policy for [Group] /Channel/Application not satisfied: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 2 of the 'Admins' sub-policies to be satisfied
This error is because of wrong admin certs. Then only I found that during certificate renewal, I updated only orderer tls certs. But the channel config also contains each org's admin certs and cacerts. Now the channel config contains expired certs. But the orgs and vault contain renewed certs.
This is the cause for the above mentioned error.
Can anyone suggest a way to resolve this? How can we update org's admin certificate in the channel config which has expired certificate?
Thanks in advance......
I've created a network based on 2 organizations under one two CA's (one normal, and one for TLS certificates). There's one orderer and one peer per organization.
I run the network as binaries on separate virtual machines.
After I create identities for organizations, I add the signcert directory from the CA admin to their respective msp directories as admincerts. I then enroll the identities on their respective machines, and add the admincerts directory. I create the ordererchannel genesis block and run the orderer binary. Next I generate mychannel.tx sign it with the peer's identity and submit the channel creation transaction (as far as I know, admin privilages are needed to successfully run peer channel create). Then, with the same identity, I try to join my peer to mychannel with peer channel join,and I get this error:
Error: proposal failed (err: bad proposal response 500: access denied for [JoinChain][mychannel]: [Failed verifying that proposal's creator satisfies local MSP principal during channelless check policy with policy [Admins]: [This identity is not an admin]])
Which is weird, because I could create the channel without problems, so the identity I'm using must be an admin. This happens on both peers. I would appreciate some input on the issue.
JoinChannel checks that the submitter is an admin of the peer itself. Peer admin(s) is(are) stores in local MSP admincerts directory.
I want 4 intermediate CAs for a peer organization: ICA1, ICA2, ICA3 and ICA4 - one for every Node OU (peer, orderer, admin and client).
Let's say if I place ICA1 as the cacerts attribute in the Peer Node OU of the channel configuration, then will a peer identity under a different ICA (ICA2, ICA3 or ICA4), be able to satisfy a policy which says signature of "OrgMSP.peer"?
If yes, then how can I make sure that only the set of roles under a specific department can satisfy a policy given by OrgMSP.<role>? I do not wish to create an MSP definition for every department or team in the organization. So, is it achievable without that?
If no, then can I also specify a group of ICAs in the Node OU configuration of the channel for a particular OU so that I can leverage very complex policies like "Signature of one-of 'OrgMSP.peer'" and let's say that here, cacerts property for the peer OU will be ICA1 and ICA3. Is this achievable?
When you specify the nodeOU configuration, you may simply supply the OU name corresponding to the role (it sounds like this is what you've done), or you may specify the OU name and an issuing certificate. This could be a root CA, or an intermediate CA, but in either case, in order to satisfy that role, the certificate must have both the OU specified and be issued by the specified CA.
Note: Each role/certificate pair informs the MSP of a valid issuer for certificates satisfying a role. So, if you have CA1, CA2, ICA1, and ICA2, you may specify a given role twice, once for CA1 and once for ICA2. Then only certificates (directly) issued by either CA1 or ICA2 may satisfy the role.
If you look in the sample MSP configuration, you can see that certificate may be specified, but is omitted by default.
You can see more details about how this certificate is used in the actual proto documentation.
I have below queries with regards to client/user identities created by enrollment process for nodejs client. When I try to enroll identities then fabric-ca issue certificates for that particular user. Certificate issued to that client has below properties.
Certificate Information:
Common Name: admin
Organization Unit: client
Valid From: May 6, 2020
Valid To: May 6, 2021
Issuer: fabric-ca-server, Hyperledger
Now when I try to use the same identity to install and instantiate chaincode or interact with fabric runtime via TestAPI it throws below error :
2020-05-05 18:35:06.670 UTC [protoutils] ValidateProposalMessage -> WARN 0e4 channel [ichannel]: MSP error: the supplied identity is not valid: x509: certificate signed by unknown authority
I have created crypto certificates for all organizations using cryptogen tool. These certificates have been issued by the certificate authority defined in network-config.yaml file.
I suspect that the difference in the certificate issuer it's causing identity issue. Please let me know if my understanding is correct.
If yes then how I can ensure that these nodejs client certificates are being used by the same certificate authority defined in network-config.yaml file.
I was able to resolve this issue by updating Certificate Authorities environment variables inside the docker-compose file. Earlier they were not getting picked from /etc/hyperledger/fabric-ca-server-config/ location.I did update path for below environment variables of all certificate Authorities before regenerating crypto configurations and restarting the whole network:
FABRIC_CA_SERVER_CA_KEYFILE
FABRIC_CA_SERVER_CA_CERTFILE
Note: TLS configs were disabled inside the network.
This has worked for me.
From Fabric MSP ,
admincert:
1.a folder admincerts to include PEM files each corresponding to an administrator certificate
signcerts:
a folder signcerts to include a PEM file with the node’s X.509 certificate
There are really two "types" of MSPs:
An MSP which is used as a signing identity
For the default MSP type (X509-based), the signing identity uses the crypto material in the keystore (private key) and signcerts (X509 public key which matches the keystore private key). Peers and orderers use their "local MSP" for signing; examples would be peers signing endorsement responses and orderers signing blocks (deliver responses)
An MSP which is used to verify signatures / identities
In this case, when a node needs to verify the signature (e.g. a peer verifying the signature of an endorsement proposal from a client), it will extract the MSPID from the creator field in the message it receives, look to see if it has a copy of the MSP for that MSPID.
If the role requires MEMBER, it then uses the "cacerts" / "intermediatecerts" content to verify that the identity was indeed issued by that MSP. It then uses the public key which is also in the creator field to validate the signature.
In the case where an ADMIN role is required, it actually checks to make sure that the creator public key is an exact match for one of the X509 public certs in the "admincerts" folder.
NOTE: There is technically no difference between an "admin" cert and a "member" cert. An identity becomes an "ADMIN" role by simply adding the public certificate to the "admincerts" folder of the MSP.
NOTE: The MSPs for all members of a channel are distributed to all the peers that are part of a channel via config blocks. The orderer also has the MSPs for all members of each channel / consortium as well.
The admin certificates are used to administer the peer (installing/instantiating chaincode, creating channels, etc) and the signcerts are for the endorsing function. They are independent to preserve a separation of concerns.