Generating crypto material in production environments — Fabric CA

Blockchain technology has moved on and it’s becoming more and more to hear: “I don’t want to implement just a proof of concept; I want to go to production”.

Photo by FLY:D on Unsplash

Furthermore, the blockchain platform that day by day is more relevant and more used by is Hyperledger Fabric. This is due to its principal characteristics like the privacy between the different participants, the consensus mechanism, the implementation of the logic business, etc. In this article, we will focus on another of its particularities: identity management.

As you will know, in the platform the diverse entities that take part in the network (orderers, peers, users, etc.) are represented by X509 certificates. These types of certificates, nowadays, are the standard used in Public Key Infrastructure.

When a Hyperledger Fabric infrastructure is created, there are native tools that generate all the certificates required by all the identities participating in the use case. However, when going to production is the main requirement, the community recommends not to use them. To that, it is desirable to create Certificate Authorities to issue all those identities.

A Certificate Authority is a trusted entity that is responsible for issuing and revoking a specific type of certificate using digital signature.

So, when you are designing a Hyperledger Fabric-based network for a production environment you may have two alternatives:

1. If the organization has its own Certificate Authority, it can be used to issue all the certificates.
2. In case there isn’t the Certificate Authority it is possible to create a Hyperledger Fabric CA.

Fabric CA is a tool through which you can generate certificates. Let say you have 10 users then, 10 certificates get generated for 10 users. You can add additional information called as attributes in certificates. So this information is propagated to the system. Chaincodes (Smart Contracts in Blockchain) can read this data and perform different operations As this information is within certificates you can’t modify it which makes process secure.

You can generate certificates by specifying the username, password and affiliations which is called as Enrollment. With these certificates you have to sign each and every request. Some data of the certificates will be stored inside the ledger through which you can know who actually execute the operation.

Fabric CA Architecture

Initializing Fabric-CA Server

You can start with initializing Fabric CA Server. This provides an opportunity for you to generate a default configuration file that can be reviewed and customized before starting the server.

fabric-ca-server init -b admin:adminpw

Here, -b specifies the name and password for a bootstrap identity. The fabric-ca-server init command generates a default configuration file named fabric-ca-server-config.yaml in the server’s home directory as shown below:

Starting the Fabric-CA Server

If earlier the Fabric-CA server is not initialized, it will initialize itself when started for the first time that will generate the ca-cert.pem and ca-key.pem files.

fabric-ca-server start -b admin:adminpw

Now, the Fabric CA server should be up and running listening on port 7054.

Enrolling the bootstrap identity

Now, run fabric-ca-client enroll command to enroll the identity. For example, following command enrolls an identity whose ID is admin and password is adminpw by calling Fabric CA server that is running locally at 7054 port.

fabric-ca-client enroll -u http://admin:adminpw@localhost:7054

The enroll command stores an enrollment certificate (ECert), corresponding private key and CA certificate chain PEM files in the subdirectories of the Fabric CA client’s msp directory. You can even configure identity ID and password in the fabric-ca-server-config.yaml file.

Registering a new identity

The identity performing the register request must be currently enrolled, and must also have the proper authority to register the type of the identity that is being registered. If the invoker’s identity has the hf.Registrar.Roles attribute with a value of peer, app, user, the invoker can register identities of type peer, app and user.

fabric-ca-client register --id.name admin1 --id.affiliation org1.department1 --id.attrs 'hf.Revoker=true,admin=true:ecert' --id.type user

The command above uses the admin identity’s credentials to register a new user with an enrollment id of “admin1”, an affiliation of “org1.department1”, an attribute named “hf.Revoker” with a value of “true”, and an attribute named “admin” with a value of “true”. The “:ecert” suffix means that by default the “admin” attribute and its value will be inserted into the user’s enrollment certificate, which can then be used to make access control decisions.

Registering a new identity will print the password, also known as the enrollment secret. This password is required to enroll the identity.

Enrolling a peer identity

Now that you have successfully registered a peer identity, you may now enroll the peer given the enrollment ID and secret (i.e. the password from the previous section).

fabric-ca-client enroll -u http://peer1:<password>@localhost:7054

Congrats! Finally, you are able to setup your own CA Server for the enrollment and signing of new identities required for your application.

References:

1. https://medium.com/knoldus