Background:
Fabric documentation says that MSP optionally might have a folder with Intermediate CAs (ICA) as shown below.
Question:
What is the purpose of having this folder? From what I understand each ICA cert is signed with root CA cert, and root CA cert is added to MSP configuration. So it seems that even if fabric MSP does not have folder with ICA it anyway has means to validate the incoming request (because it has root cert.)
I may assume that having ICA might be used not for validation but for some configuration and giving different roles to identities signed by different ICAs, but it is vague for me how exactly it can be used.
Documentation:
Here is related part of Hyperledger Fabric documentation:
Intermediate CAs: This folder contains a list of X.509 certificates of
the Intermediate CAs trusted by this organization. Each certificate
must be signed by one of the Root CAs in the MSP or by an Intermediate
CA whose issuing CA chain ultimately leads back to a trusted Root CA.
An intermediate CA may represent a different subdivision of the
organization (like ORG1-MANUFACTURING and ORG1-DISTRIBUTION do for
ORG1), or the organization itself (as may be the case if a commercial
CA is leveraged for the organization’s identity management). In the
latter case intermediate CAs can be used to represent organization
subdivisions. Here you may find more information on best practices for
MSP configuration. Notice, that it is possible to have a functioning
network that does not have an Intermediate CA, in which case this
folder would be empty.
Like the Root CA folder, this folder defines the CAs from which
certificates must be issued to be considered members of the
organization.
One of the primary reasons that I can think of setting up an intermediate CA is to protect your root of trust. Your organization or sub organization may be allocated a certificate of identity that you want to protect dearly. So, you safe guard it by deriving/generating one or more intermediate certificates and setting up the corresponding CAs so that your root certificate can stay in a safe zone (say DMZ) and you can stil obtain the benefits of verification & signing using your intermediate certificates and CAs. Verification would still remain unaffected as your intermediate certs and CAs chain to the single root of trust from where it was issued.
Related
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.
I am trying to get an intermediate CA and use that to generate all the certs for a particular organization. I am currently using fabric-sample as a base reference.
Currently crypto-config.yaml, creates a root CA for each org and than use that to generate all certs for that org.
How can I change the crypto-config.yaml file, so that
either, it generate root CA and intermediate CA also for each org
and use that as signing CA for peer and admin certs.
or, it takes an already created root CA cert and key for each org, and than generate intermediate CA and use that as signing CA for peer and admin certs.
Then I will use docker-compose-e2e-template to start intermediate CA and all peers and orderer.
Is this approach is fine? If not, what is the easiest way to achieve the intermediate CA and use this CA to generate all peers and admin cert?
Thanks for any help!!
cryptogen is really just a tool for creating the crypto material for basic test networks and is really designed to be independent of of Fabric CA (although it's possible to start a Fabric CA using the root cert pair generated for each organization).
If you actually want to set up Fabric CA with root and intermediate CA's, I'd recommend using Fabric CA directly. Of course this means that you'll need to distribute / bootstrap all of your peer and admin certs yourself as well.
I'd recommend reading https://hyperledger-fabric-ca.readthedocs.io/en/release-1.2/users-guide.html#enrolling-an-intermediate-ca which explains how to set up intermediate CAs by pointing them at an already established root CA.
You can then follow https://hyperledger-fabric-ca.readthedocs.io/en/release-1.2/users-guide.html#registering-a-new-identity to enroll your admin identities against the intermediate CA and https://hyperledger-fabric-ca.readthedocs.io/en/release-1.2/users-guide.html#enrolling-a-peer-identity for enrolling your peer identity.
Note that you will need to add the admin public key to the admincerts folder of the MSP for the appropriate peer(s).
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
I went through documentation on fabric-ca
http://hyperledger-fabric-ca.readthedocs.io/en/latest/users-guide.html
I have below questions
1.When will be fabric-ca come into picture in hyperperledger for user authentication or in msp certs generation or in both
Can we use some other third party CA in place of fabric-ca
What should be the things to be kept in mind if we use some third party CA.
Is there any sample to understand it more(already went through balance-transfer)
fabric-ca comes into the picture for both authentication and MSP certs generation. The /enroll API requires basic authentication, and assuming success, will issue an enrollment certificate and populate the appropriate MSP directories.
You have the following choices when it comes to using a CA with fabric:
a) Use fabric CA to function as a root CA and/or intermediate CA.
b) Start fabric CA with an intermediate signing certificate which you
get from an external CA.
c) Don't use fabric CA at all and use an external CA completely.
With a & b, the fabric CA server can function as its own user registry,
or it can talk to an LDAP server as the user registry.
3) When using a 3rd party CA (#c above), you will need to think about
how you want to do access control in chaincode. One option is based
on the OU (Organizational Units) that a user's certificate has, which
means the 3rd party CA will need to be able to restrict which OU
values are issued to which users. When using the fabric CA server
to issue certificates, you can use Attribute-Based Access Control
(ABAC) to perform access control for chaincode.
4) There is a sample which is not merged yet at https://gerrit.hyperledger.org/r/#/c/13213/.
See the README.md for a description of how to run the sample and
an overview of how it works.
openssl：
void SSL_CTX_set_verify_depth(SSL_CTX *ctx,int depth);
depth:
level 0:peer certificate
what is the meaning of peer authentication？
Take a look at here: https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_verify.html
The depth parameter is about the limiting the length of a chain of certificates that one is willing to accept. Peer authentication, on the other hand, is a more generic concept that is about authenticating the parties involved in the communication, otherwise known as "peer". Relying on public key infrastructures and certificates is one way to achieve authentication but there could be other means too.
Back to OpenSSL (and SSL in general), the authentication is based on the so-called "chain of trust", which means that the software trust certain entities, often times big Certificate Authorities (CAs) whose certificates are typically distributed and installed alongside with the software, who in turn sign the certificates (vouch for) of some intermediate CAs, who in turn does the same for the "peer" (the last entity of the chain), which typically is the server that the software attempts to connect to. Since the software trust some root CAs, and the intermediate CAs present certificates signed by those trusted root CAs, these intermediate CAs are trusted as well, and because the intermediate CAs are trusted, the "peer" can be authenticated now as it presents certificate signed by the intermediate CAs.
Now due to different security concerns and resource limits, the length of a certificate chain ("depth") cannot go arbitrarily long. If I'm not wrong, the default limit of OpenSSL is 100. Other SSL implementations might choose a different number based on their targeted platforms and application scenarios.
SSL_CTX_set_verify_depth() is used to impose a user-desired limit on the chain verification procedure, so that any certificates presented in the chain above the limit would be ignored. The level 0, 1, 2 used in the documentation refers to the position of certificates in the chain, where level 0 is the peer (the end entity), level 1 is possibly a certificate of a CA that signed the level 0 certificate, level 2 is a certificate of another higher level CA that signed the level 1 CA certificate, so on and so forth.
Another related concept can be found as the pathLen option of the basic constraints extension of X.509 version 3 certificates. This is often times used by higher level CAs to limit the length of a chain that can be formed by certificates issued by lower level CAs.
Hope this helps.