I am a bit confused about the consensus-based network administration.
In my understanding of hyperledger fabric, the CA server is a single point of administration. Even though it is possible to create organization-specific CA servers, there should be one main CA to verify the chain of trust.
For example, the one who administers the CA server can create the required number of identities to break the consensus.
Please clarify if I am wrong.
Thanks & Regards,
Akhil KM
#Akhil KM
CA server is not a complete administration in the fabric network
it is just giving certificates and the MSP is the complete administration and that to not to the whole consortium. Each entity can have different MSP means different CA's can issue certificates. One org can have more than one CA
CA in the fabric is exactly equivalent to normal CA in current all public-key cryptography like how browsers show us secure https by trusting the certificate
In fabric or in website world CA will never become an administrator. CA will have an administrator (To operate CA :) )
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 working in a company where we are using the hyperledger fabric to build our application. we have been using the fabric CA till now. Now for the production phase we are planning to move to third party ca provider.
I have read the documentation of the Fabric CA (https://hyperledger-fabric-ca.readthedocs.io/en/release-1.4/) for understanding how it works. I have been looking in the Stackoverflow Fabric tag (https://stackoverflow.com/questions/tagged/hyperledger-fabric) if i could find some relevant solution but i wasn't able to find it.
Yes you can use other ca providers, as long as they give the x.509 certificates you can use them. In the end what the fabric CA does is:
registration of identities, or connects to LDAP as the user registry
issuance of Enrollment Certificates (ECerts)
certificate renewal and revocation
You can use other providers such as hashicorp vault.
https://learn.hashicorp.com/vault/secrets-management/sm-pki-engine
What are the functions of the Fabric CA Server and Fabric CA Client?
What are the Roles of the Fabric CA Server and Fabric CA Client?
Thanks
Fabric CA provides features such as:
Registration of identities with roles like peer, user or application, or connects to an existing LDAP as the user registry to fetch identities of the mentioned roles.
Issuance of Enrollment Certificates (ECerts) for signing and identifying
Issuance of Transaction Certificates (TCerts), providing both anonymity and unlinkability when transacting on a Hyperledger Fabric blockchain (not yet available in v1.0)
Certificate renewal (by re-enrollment) and revocation (using Certificate Revocation Lists feature of PKI)
You need to setup the Fabric CA server to host one or more Certification Authorities (Fabric CA) for your Fabric Network (based on the MSPs What is the difference between MSP and Fabric CA?)
using the following Command Line Options:
http://hyperledger-fabric-ca.readthedocs.io/en/latest/servercli.html
The client is just the component that provides an interface to the server component. However, you can skip using the fabric-ca-client and use the REST API of the Fabric Server and do all the functionalities mentioned above. The fabric-ca-client is just a nice wrapper to the ugly REST calls.
You can explore the functionalities of the Fabric CA client using either one of the following:
REST API (https://github.com/hyperledger/fabric-ca/blob/master/swagger/swagger-fabric-ca.json)
http://hyperledger-fabric-ca.readthedocs.io/en/latest/clientcli.html
Fabric CA SDK Clients (Node, Java, etc) for the language you are developing your app in.
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.