I have setup Multiple Organization on different machines.
Machine 1
-> peer0.org1.example.com
-> ca.org1.example.com
-> orderer.example.com
Machine 2
-> peer0.org2.example.com
-> peer0.org3.example.com
I have created a channel which is shared by all three organization.
Now the issue is When I try to access the data from Org 2 and Org 3, it gives me below error message
UNKNOWN: access denied: channel [mychannel] creator org [Org2MSP]
On other hands, If I tried to execute the same query through CLI, the transaction gets executed successfully without any error
My question is: Can we setup one CA for multiple Organization. if yes, How to resolve access denied issue?
To answer your primary question: Is it possible for 1 ca server to contain more then 1 root identity. The answer is yes Multiple CAs. This solution uses one 1 fabric-ca-server to serve more then 1 root identity. In Hyperledger fabric the root identity is used as the root Identity 1 organization.
But should you use this kind of architecture? To answer this question we have to know the role of the fabric-ca-server and how identity is handled within the blockchain network(Hyperledger specific.)
To validate identity within the blockchain network and in between the different components (peers, orderders, clients). HLF(Hyperledger Fabric) uses the abstract concept of an MSP (Membership Service Provider). In the current implementation of HLF it uses X509 certificate to construct this identity. It is import to know that the only requirements is that of X509 certificates. You do not need a fabric-ca-server. To construct the MSP fabric needs a specific structure on disk of MSP certificates to construct the identity. All components need (some part) of this structure.
The fabric-ca-server is used to create the X509 certificate needed for the MSP structure. For instance this is used when you want to enroll an extra peer , orderer, client etc... To get all this material in general you can use fabric-ca-client or the SDK. The client is able to export this material in the correct folder structure used by the default MSP.
So should you use 1 fabric-ca-server for multiple organization? My answer would be no. What you want is that all the organization are independent of each other and that 1 ORG can not construct an identity for another ORG. If you use 1 server to contain multiple identities this also means that the private-key material is stored on 1 server, and thus you can create identities for all organizations.
So the next question How to resolve access denied is actually a different question. This is most likely due to incorrect configuration of the environment variables that HLF uses to point to specific parts inside of an MSP folder structure. So you need to see what kind of environments variables are used inside the CLI and use the same inside your other container (if you want to have to same identity).
TL;DR; fabric-ca-server is used to create X509 certificates that can be used to construct an MSP. The MSP is what is the actual identity inside of HLF, best practice is to use 1 root-ca for every organization.
Related
I have question related to cryptogen and hyperledger fabric network setup. I want to explain my workflow. I wanna know this procedure can be used for production
1. I have 2organisation org1,org2.In which each organisation consist two peers,only one ordered for
both organisation and 2 fabric-ca server.
2. Generating the all the key pairs using the cryptogen tool using the crypto-config.yaml.
3. Generating genesis block and channel transaction using the configtx tool with configtx.yaml.
4. (Important Note:)I am using the CA private key and certificate ca.org1.example.com-cert.pem, which is generated using the cryptogen tool in my network docker yaml file to setup the fabric ca.
5. After setup all i am running the network its works fine.
6. I am enrolling and registering the admin and user from the outside using the fabricnodesdk.
here its good practice to use the cryptogen generate ca private key and certificate to setup and run the CA server in production. If this not good practice, Is there any other way i can implement it. Please your suggestion would be helpful for me.
Hyperledger Fabric docs suggest not to use cryptogen tool for production environment
Reason: it’s a tool and all crypto materials are generated on the fly with 10 years validity and you cannot control further with fabric-CA like revoke, reenroll, etc because fabric-ca will not have a copy in the database
Traditional way: generating crypto material with fabric-CA by registering and enrolling an identity with 1-year validity
But if you take my opinion, I have used cryptogen tool 2 years back in one production environment. There is no harm to use cryptogen tool in production unless you will need to interact with CA to make changes to the identities. It depends on the use case in our usecase we do not need to keep changing the identities it was fixed forever it was a typical usecase
But later and now I have been using fabric-CA and custom CA to
generate crypto materials leveraging more possibilities
I find it a dirty way to do it. Your Fabric-CA is working and your orderers and peers are of course working because their certificates are correct and have been suitably signed by the CA. But the fact is that the identities corresponding to the orderers, peers and clients that you generated via cryptogen have not been registered in the Fabric-CA database, so you can neither manage nor revoke those identities and their corresponding certificates via your Fabric-CA in the future.
My advice (for production environments, of course): Don't be lazy; take care of a good proper fabric-ca-server-config.yaml and fabric-ca-client-config.yaml configuration; launch safely your Fabric-CA; and script your initial identity registration, certificate enrollment and MSP/TLS folder structure creation.
I am a newbie to Hyperledger Fabric. I came across a very confusing part of fabric.
Cryptogen is used to generate certs and keys for users and admin in an organisation.
Talking specifically about fabcar,
A very similar thing is the done by:
enrolling an admin
enrolling and registering a user identity using CA, in fabcar chaincode.
Things got more confusing when I saw CA server creating a bootstrap
'admin' identity while starting of the container itself.
So what exactly is happening?
What is the flow?
What is the difference between these admins created again and again?
I see, CA server container has a volume mounted, pointing back to the crypto-config folder which already have certs and keys generated by cryptogen.
Why are we again creating bootstrap identity on fabric-ca-server start using -b flag? We already have admin certs and keys generated for admin by cryptogen and those are already mounted on the fabric ca server container.
Why are we again enrolling an admin in fabcar chaincode, we already have certs and keys for admin, don't we(from the volumes mounted on fabric ca server container)?
Why are we both registering and enrolling a new user in fabcar chaincode, we already have certs and keys for one user(in fabcar), don't we(from the volumes mounted on fabric ca server container)?
Similar existing answers is not what I am looking for. I want an in-depth insight.
Thanks.
Okay, so after digging around for continuous 1 week I found exact answer to the question.
First, I would like to lay down exact flow and structure of fabric samples applications.
Fabcar and Commercial Paper are two different applications being
provided by fabric as a part of fabric sample.
Fabcar uses first-network and Commercial Paper uses basic-network.
Fabcar has its chaincodes in chaincode folder while Commercial Paper has its chaincodes in contract folder within the two organisations.
After chaincodes are installed by administrators (don't confuse this admin with CA admin, this is simply a developer who is managing channel) using peer chaincode install and peer chaincode instantiate the contract becomes available to all the components of the respective channels.
Now we need to have certain application that will be invoking contracts known to the channel. Both Fabcar and Commercial Paper have their different applications in their respective application folders.
Applications can interact with our channel or say underlying fabric layer through a gateway.
The Hyperledger Fabric SDK provides a gateway abstraction so that
applications can focus on application logic while delegating network
interaction to the gateway. Gateways and wallets make it
straightforward to write Hyperledger Fabric applications. Find here in the docs
Our applications require some identity to be able to use underlying fabric layer. This identity's authenticity is checked by gateway before allowing access to the network.
Fabric uses concept of keys and signed certificates to perform this authentication.
Diving into a different concept here, fabric provides two kind of certification architectures (architecture might not be the correct word),
cryptogen - generally used for developement or testing purposes to generate keys and certificates
Certificate Authority - not a new concept, used by fabric to generate certificates. Any CA server requires to have admin to allow generating certificates.
While bringing up the server itself, this bootstrap identity is created using fabric-ca-server start with a -b option with username:password parameter.
Coming back to fabric, before starting any network (basic-network or first-network) fabric asks us to generate cryto-config.
Commercial Paper uses certificates and keys generated by this previously generated crypto-config by cryptogen to generate identities for the application.
Fabcar uses CA to generate certificates and keys. Admin was registered already when we brought up our CA server container in Fabcar. We simply gave him certs and keys on enrollment. New user require both registration and enrollment (done using CA admin identity).
The private and public key are first generated locally and the public
key is then sent to the CA which returns an encoded certificate for
use by the application. These three credentials are then stored in the
wallet, allowing us to act as an administrator for the CA. Find here in the docs
So it's not by design of fabric why Fabcar used CA and why Commercial-Paper used cryptogen, it's simply by choice.
I'll end my answer, quoting exact statement from the fabric documentation.
When we created the network, an admin user literally called admin
was created as the registrar for the certificate authority (CA).
Our first step is to generate the private key, public key, and X.509
certificate for admin using the enroll.js program. This process uses
a Certificate Signing Request (CSR) — the private and public key are
first generated locally and the public key is then sent to the CA
which returns an encoded certificate for use by the application.
These three credentials are then stored in the wallet, allowing us
to act as an administrator for the CA. We will subsequently register
and enroll a new application user which will be used by our
application to interact with the blockchain. Find here in the docs
addToWallet.js is the program that Isabella is going to use to load
her identity into her wallet, and issue.js will use this identity to
create commercial paper 00001 on behalf of MagnetoCorp by invoking
papercontract. Find here in the docs
Any corrections from experts are very welcome. These are my deductions from code observation.
I don't know what fabcar does, but maybe I can clarify some Hyperledger Fabric concepts to you.
cryptogen is a development tool using for generating all the (MSP and TLS related) cryptographic stuff you need initially for your development Fabric network.
For more serious deployments, you use Fabric-CA instead. Fabric-CA is a Certification Authority that maintains a database of the identities registered for your organization and allow your registered actors to enroll their certificates. You can also update identities, revoke identities and certificates, etc.
And then you have to distinguish a CA administrator from a organization administrator. You first enroll the CA administrator, otherwise you cannot register identities. And a organization admin is simply an identity with role admin for the organization.
Normally, the enrolled CA administrator generates all the identities. After that, later, in other place, the organization administrator (or any other identity) enrolls its certificate by specifying the user and password declared during registration.
Some Theory: cryptogen is just a tool written in golang and what it does is it will create a self-signed root ca and some signed certificates(org admin, users, entities)
Now when you start CA, if you want to use the same cert and key generated by cryptogen then you will use below command
fabric-ca-server start -b myorgadmin:myorgpw -d
ELSE if you do not want to use cryptogen generated certificates then you can use below command and you should forget about cryptogen generated certificates because they no longer use and you have to generate by yourself
fabric-ca-server init -b myorgadmin:myorgpw
DIFFERENCE is init command
Bootstrap CA server credentials are in order to authenticate for future
purposes
Ex: If you want to register a new user then you need to authenticate
with credentials
In future, you can use cryptogen generated user certificates or you can register different users by authenticating CA server
I am reading hyperledger fabric read the docs and I am confused how local MSPs of the users allow the user side to authenticate itself in its transactions.
explain the meaning of this paragraph
Node local MSPs define the permissions for that node (who the peer admins are, for example). The local MSPs of the users allow the user side to authenticate itself in its transactions as a member of a channel (e.g. in chaincode transactions), or as the owner of a specific role into the system (an org admin, for example, in configuration transactions).
but we use x.509 certificate to authenticate the users right ?
You bring up a very good point in terms of the overloaded use / meaning of the term MSP as well as the "file / folder" structure used to hold cryptographic material for the various entities in Fabric.
Fabric currently supports two types of MSP: X509 and Identity Mixer. The default is to use X509 which means that you validate that users are part of an organization by ensuring that their X509 certificates were issued by the root/intermediate CAs defined in the organization's MSP (which typically ends up stored as part of each channel's config).
So broadly speaking, an organization's MSP defines the mechanism for validating identities (based on the issuer present in the MSP definition) and defining how to determine the "role" of those identities (for example admins are explicitly defined by having their certs in the admins folder and in 1.4.3 and later optionally by a specific OU in the cert).
A "local" MSP holds the actual crypto material issued by an organization's MSP. In the case of a peer, this includes the key pair (found under keystore and signcerts) used to sign endorsements as well as the information needed to determine administrator's for the peer itself. In the case of ordering nodes, the key pair is used for signing blocks. For clients / users, the key pair is used to sign transactions.
To your point, a client really does not need the MSP structure ... you really just need the signing / enrollment key pair and the MSPID ... but unfortunately the MSP concept is also carried over to clients even though most of the material in an MSP structure is not required for signing transactions.
In Two Org setup in which each Org has its own CA for issuing certs, then how Orderering nodes identifies that particular request is coming from a known Org identity.
It attempts to match the identity with each of the available MSP's and whichever had passed, verifies the identity to belong to that MSP.
This can be verified by looking at docker logs of orderer.
In all of the fabric examples and documentation, usually there is a unique private certificate authority issuing certificates for each organization.
However, playing around with the code base, I do not see a limitation that different orgs need to each have different Root CAs.
Is there an issue with having the same Root CA for multiple organizations? Can the subject fields in the certificates be sufficient to use for identity verification in different fabric workflows?
If you want to ensure that one organization does not masquerade as another, there must be something unique about the certificates that are issued by or for an organization. Of course the easiest way to handle this is to have a separate root CA per organization. It's also possible to have a common root but have different intermediate CAs for each organization.
But given your question is about basically using a single fabric-ca to issue certificates for multiple organizations, this is possible using the Organization Unit (OU) identifier feature introduced in v1.1 and later. Basically, you can differentiate organizations using an OU in the issued certificates. With Fabric CA v1.1 and later, you can create different affiliations for each organization and when certificates are issued, the OU will be set to the affiliation associated with the identity during the registration process. You can either trust a single admin to properly register identities for multiple organizations, or you can create an hierarchical set of admins (meaning create multiple CA admins but assign each a different affiliation as admins can only register users under their own affiliation).
Then within your MSP definitions, you can using the config.yaml file to specify the OU with which to associate the MSP. For example, if you look at https://github.com/hyperledger/fabric/blob/release-1.1/sampleconfig/msp/config.yaml, then
OrganizationalUnitIdentifiers:
- Certificate: "cacerts/cacert.pem"
OrganizationalUnitIdentifier: "COP"
means that this org is identified by the root CA PLUS having OU=COP in the certificates. This would also mean that the affiliation within fabric-ca would be "COP" as well