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.
Related
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.
In the Hyperledger Fabric test network registration script*, the TLS certs and keys are copied from the Peer's MSP to the parent Organization's MSP (lines 63-71):
cp ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/tlscacerts/* ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt
cp ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/signcerts/* ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/server.crt
cp ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/keystore/* ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/server.key
mkdir -p ${PWD}/organizations/peerOrganizations/org1.example.com/msp/tlscacerts
cp ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/tlscacerts/* ${PWD}/organizations/peerOrganizations/org1.example.com/msp/tlscacerts/ca.crt
mkdir -p ${PWD}/organizations/peerOrganizations/org1.example.com/tlsca
cp ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/tlscacerts/* ${PWD}/organizations/peerOrganizations/org1.example.com/tlsca/tlsca.org1.example.com-cert.pem
Does this mean that the Organization uses the same TLS and certs and keys as the Peer?
If you add a second peer to the organization, would they (both peers and parent organization) all use the same TLS key+cert?
*This script is used when the Fabric-CA is used instead of cryptogen to generate the necessary certificates.
Actually a peer organization MSP holds three elements
Organization Admin Certification under /admincerts
CA Certification or the certification of Certification Authority that will be in charge of issuing and signing all the certifications (peer, user ... ) under this organization under /cacerts
TLSCA Certification which is like CA Certification but used to sign all the TLS certification (peer, user ...) under this organization under /tlscacerts
Whereas a peer MSP holds five elements
The precedent three elements that represent the authorities that signed its own certifications ( /cacerts and /tlscacerts ) and the authority whith the right to perform operations ( /admincerts )
Its own public key which is under /signcerts
Its own private key that goes with its public key which is under /keystore
So to answer your question NO: organization and peer don't have the same MSP. Each peer has its own MSP( aka a couple public and private key which represent his unique identity and the CA certs that signed it )
And the organization has only the CA certs that signed every node identity in that organization.
So when you create another peer under this Org ( with cryptogen tool for example ), this peer will hold in its MSP his own unique identity but the same CA certs then the other peer.
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.
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.
I'm studying the architecture of Hyperledger Fabric. I'm curious that how the endorsing peer can verify the origination of a transaction locally.
According to the documentation, when the submitting client send a transaction to endorsing peers, each endorsing peer verifies the client's signature. As far as I know, the signature is the message encrypted by the client's private key. To verify the signature, the endorsing peer needs the client's public key.
So, my question is that, from where the endorsing peer gets the client's public key? I guess that the public key is inside the genesis block for the channel which is generated by configtxgen tool because all peers on the same channel have this genesis block. Is it correct? Or does a transaction contain the client's public key(a.k.a the client's certificate) like the https connection? (But, according to the documentation, there is no room for the client's public key on the message format.)
Thanks, in advance.
No, the genesis block doesn't have public keys of network nodes, only of root CAs and intermediate CAs.
Inside the transaction, the identity of the client is encoded.
Fabric v1.0 comes only with identities based on x509 certificates.
The public key is inside the certificate.
The signature doesn't contain the certificate. It's just the signature itself.
The certificate is included in the SignatureHeader of the transaction (in the creator field) which is, part of the transaction.
https://github.com/hyperledger/fabric/blob/d9c320297bd2a4eff2eb253ce84dc431ef860972/protos/common/common.proto#L113-L119
message SignatureHeader {
// Creator of the message, specified as a certificate chain
bytes creator = 1;
// Arbitrary number that may only be used once. Can be used to detect replay attacks.
bytes nonce = 2;
}