Admin & users created by "CA" vs Admin & users created by "cryptogen" in Hyperledger Fabric

Question

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:

  1. enrolling an admin
  2. 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.

Answer 1

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.