cryptogen — Generating crypto material in Hyperledger Fabric during Dev/Testing

Overview

One of the most asked questions on Hyperledger Fabric is about identity. A permissioned blockchain requires that an entity, be it a client, an administrator or a network component, must be first identified and permissioned before accessing a consortium network. Hyperledger Fabric uses several concepts like organization, membership service providers, digital certificate, which makes the understanding of the whole picture a little challenging for new learners. Here in this article again we will go through a utility named cryptogen which helps in generating crypto material with minimum network setup.

cryptogen

This command is executed for all orderer and peer organizations.

We can see how cryptogen works: with this command and configuration files, we can build the directory structure of crypto material shown below.

cryptogen generate --config=<configuration_file> --output=<output_directory>

To add more peers to the network we have the option to use the extend command to generate crypto material for newly added peers.

cryptogen extend --input=<crypto-config directory> --config=<configuration_file>

Configuration File

We will now take a look at the configuration file — crypto-config.yaml, which tell cryptogen how to generate the crypto material shown above. These configuration files are self-explanatory. For sake of completeness we put them here.

For orderer organization. The result is one orderer with name acme.com. One Admin user is generated by default.

crypto-config.yaml

For peer organization (here we see acme). The result is one peer (Count 1 in Template) and the name is by default acme.com. One Admin user is generated by default. The Count 2 in Users means two users will be generated as well.

output folder — orderer

Here are a quick summary for all these components

• ca/: a directory holding crypto material for CA of acme (orderer/peer)
• peers/: a directory holding a list of peers under acme, and each peer has its own crypto material, of both identity and TLS
• users/: a directory holding a list of network users under Org1, and each peer has its own crypto material, of both identity and TLS
• tlsca/: a directory holding the TLS CA
• msp/: it is the material joining a consortium network

output folder — peer

CA Certificate

We first take a look at the CA of acme. It is this CA issuing identity (certificate) to all entities within acme.

From the directory we see a private secret key and a certificate. We will inspect the subject and issuer of the certificate.

It is a self-signed certificate (subject == issuer). It is a typical design for non-production environments, as we allow a new self-signed certificate as the CA to issue identity for the whole organization. This is what cryptogen can provide, and this is also its limitation.

Conclusion

Cryptogen by far is the simplest way for us to generate crypto material for typical network designs. No matter how many orderers we are to deploy (one for Solo, five for Raft, etc) in orderer organization, how many peers needed for each peer organization, or how many client users needed in each organization, we can specify the requirement in the configuration files and generate the material with a simple command.

This is also where the limitation lies. From Hyperledger Fabric documentation, we learn that cryptogen is good for generating crypto material for testing purposes, and would normally not be used in production operation. There are several considerations.

In cryptogen, material is generated once based on configuration file, but in real life we may need more peers or more clients after deployment. Although it is still doable, as we can generate the new entities with CA’s private key, it is not as simple as running cryptogen on a configuration file.

If you are just creating for testing, the above should not be your concern, and cryptogen is good enough. Otherwise, you can take another approach: bring up a CA server and generate the crypto material for entities with this CA according to your desired network design. This is the second way to generate crypto material for a consortium network.