Generating Certificates (Crypto Materials)using Certificate Authority in Hyperledger Fabric
In this story, we are going to create all the necessary certificates for the Hyperledger fabric network using certificate authority.
Git Repo: https://github.com/adhavpavan/GenerateCertificateUsingCA-HyperledgerFabric.git
Create the docker-compose-ca.yaml file with the following configuration.
Create a folder structure like below, Currently, we have nothing inside the organization folder.
We need to create a folder structure like below for each organization.
Organization Level Structure
1) Peer Organization
2) Orderer Organization
3) User Structure
4) MSP Structure
Generally, the process of creating a certificate are
1) Enrollment
2) Register
Enrollment is the process by which a user requests and obtains a digital certificate from a given CA. Registration is usually done by a Registrar, telling a CA to issue the digital certificate.
- An admin (registrar) is enrolled in the CA. Then the admin receives the signing key and certificate for this admin.
- The admin then registers user1 into the CA with proper information. The CA returns with a secret.
- This secret is then used to enroll user1 to the CA. The result is the signing key and certificate for user1.
Let's start a certificate authority service. As we created already docker-compose-ca.yaml . We have mapped the volume in docker-compose the file.
volumes:
- ./organizations/fabric-ca/org1:/etc/hyperledger/fabric-ca-server
There are four env variables provided. Please make sure that you have provided all of them.- FABRIC_CA_HOME=/etc/hyperledger/fabric-ca-server
- FABRIC_CA_SERVER_CA_NAME=ca-org1
- FABRIC_CA_SERVER_TLS_ENABLED=true
- FABRIC_CA_SERVER_PORT=7054
Run the following command
docker compose -f docker-compose-cli up
When we start the CA container, we can see the following detailed logs. for more details please go through the below log.
Please make sure that ca container is running by running docker ps , you could see following output for ca service
When CA service is up and running , we can see following folder structure in organization folder which we already mapped in docker-compose-ca.yaml file
Step 1: Enroll CA Admin
make the directory by running below commandmkdir -p organizations/peerOrganizations/org1.example.com/
fabric-ca-client enroll -u https://admin:adminpw@localhost:7054 — caname ca-org1 — tls.certfiles ${PWD}/organizations/fabric-ca/org1/tls-cert.pem
Once we enroll Admin we get the following MPS for admin. Please crosscheck by going to specific folder. (In my case its:/home/pavan/.fabric-ca-client/msp)
Organizational Units
In order to configure the list of Organizational Units that valid members of this MSP should include in their X.509 certificate, the config.yaml file needs to specify the organizational unit (OU, for short) identifiers. You can find an example below:
OrganizationalUnitIdentifiers:
- Certificate: "cacerts/cacert1.pem"
OrganizationalUnitIdentifier: "commercial"
- Certificate: "cacerts/cacert2.pem"
OrganizationalUnitIdentifier: "administrators"The above example declares two organizational unit identifiers: commercial and administrators. An MSP identity is valid if it carries at least one of these organizational unit identifiers. The Certificate field refers to the CA or intermediate CA certificate path under which identities, having that specific OU, should be validated. The path is relative to the MSP root folder and cannot be empty.
Identity Classification
The default MSP implementation allows organizations to further classify identities into clients, admins, peers, and orderers based on the OUs of their x509 certificates.
- An identity should be classified as a client if it transacts on the network.
- An identity should be classified as an admin if it handles administrative tasks such as joining a peer to a channel or signing a channel configuration update transaction.
- An identity should be classified as a peer if it endorses or commits transactions.
- An identity should be classified as an orderer if belongs to an ordering node.
In order to define the clients, admins, peers, and orderers of a given MSP, the config.yaml the file needs to be set appropriately. You can find an example NodeOU section of the config.yaml file below:
NodeOUs:
Enable: true
ClientOUIdentifier:
Certificate: "cacerts/cacert.pem"
OrganizationalUnitIdentifier: "client"
AdminOUIdentifier:
Certificate: "cacerts/cacert.pem"
OrganizationalUnitIdentifier: "admin"
PeerOUIdentifier:
Certificate: "cacerts/cacert.pem"
OrganizationalUnitIdentifier: "peer"
OrdererOUIdentifier:
Certificate: "cacerts/cacert.pem"
OrganizationalUnitIdentifier: "orderer"Identity classification is enabled when NodeOUs.Enable is set to true. Then the client (admin, peer, orderer) organizational unit identifier is defined by setting the properties of the NodeOUs.ClientOUIdentifier (NodeOUs.AdminOUIdentifier, NodeOUs.PeerOUIdentifier, NodeOUs.OrdererOUIdentifier) key:
OrganizationalUnitIdentifier: Is the OU value that the x509 certificate needs to contain to be considered a client (admin, peer, orderer respectively). If this field is empty, then the classification is not applied.Certificate: Set this to the path of the CA or intermediate CA certificate under which client (peer, admin or orderer) identities should be validated. The field is relative to the MSP root folder. This field is optional. You can leave this field blank and allow the certificate to be validated under any CA defined in the MSP configuration.
Notice that if the NodeOUs.ClientOUIdentifier section (NodeOUs.AdminOUIdentifier, NodeOUs.PeerOUIdentifier, NodeOUs.OrdererOUIdentifier) is missing, then the classification is not applied. If NodeOUs.Enable is set to true and no classification keys are defined, then identity classification is assumed to be disabled.
Identities can use organizational units to be classified as either a client, an admin, a peer, or an orderer. The four classifications are mutually exclusive. The 1.1 channel capability needs to be enabled before identities can be classified as clients or peers. The 1.4.3 channel capability needs to be enabled for identities to be classified as an admin or orderer.
Classification allows identities to be classified as admins (and conduct administrator actions) without the certificate being stored in the admincerts folder of the MSP. Instead, the admincerts folder can remain empty and administrators can be created by enrolling identities with the admin OU. Certificates in the admincerts folder will still grant the role of administrator to their bearer, provided that they possess the client or admin OU.
Note: The above part is taken from official doc for more details.
We have to make config.yaml file at organizations/peerOrganizations/org1.example.com/msp/config.yaml and pest the following code.
NodeOUs:
Enable: true
ClientOUIdentifier:
Certificate: "cacerts/cacert.pem"
OrganizationalUnitIdentifier: "client"
AdminOUIdentifier:
Certificate: "cacerts/cacert.pem"
OrganizationalUnitIdentifier: "admin"
PeerOUIdentifier:
Certificate: "cacerts/cacert.pem"
OrganizationalUnitIdentifier: "peer"
OrdererOUIdentifier:
Certificate: "cacerts/cacert.pem"
OrganizationalUnitIdentifier: "orderer" STEP 2: Register peer0
fabric-ca-client register — caname ca-org1 — id.name peer0 — id.secret peer0pw — id.type peer — id.attrs ‘“hf.Registrar.Roles=peer”’ — tls.certfiles ${PWD}/organizations/fabric-ca/org1/tls-cert.pem
At each step please make sure that necessary certificates are getting generated. when we run these commands, we can see the generated file location mentioned at the terminal/shell/cmd line.
STEP 3: Register user
fabric-ca-client register — caname ca-org1 — id.name user1 — id.secret user1pw — id.type client — id.attrs ‘“hf.Registrar.Roles=client”’ — tls.certfiles ${PWD}/organizations/fabric-ca/org1/tls-cert.pem
STEP 3: Register the org admin
fabric-ca-client register — caname ca-org1 — id.name org1admin — id.secret org1adminpw — id.type admin — id.attrs ‘“hf.Registrar.Roles=admin”’ — tls.certfiles ${PWD}/organizations/fabric-ca/org1/tls-cert.pem
STEP 4: Make the following directory
mkdir -p organizations/peerOrganizations/org1.example.com/peers
mkdir -p organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com
STEP 5: Generate the peer0 MSP
fabric-ca-client enroll -u https://peer0:peer0pw@localhost:7054 — caname ca-org1 -M ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp — csr.hosts peer0.org1.example.com — tls.certfiles ${PWD}/organizations/fabric-ca/org1/tls-cert.pem
STEP 6: Copy config file to newly generated peer MSP folder
cp ${PWD}/organizations/peerOrganizations/org1.example.com/msp/config.yaml ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp/config.yaml
STEP 7: Generate the peer0-tls certificates
fabric-ca-client enroll -u https://peer0:peer0pw@localhost:7054 — caname ca-org1 -M ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls — enrollment.profile tls — csr.hosts peer0.org1.example.com — csr.hosts localhost — tls.certfiles ${PWD}/organizations/fabric-ca/org1/tls-cert.pem
Whatever the tlscerts, signcerts,keystore created we have to move like below for tls
cp ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/tlscacerts/* ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt
cp ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/signcerts/* ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/server.crt
cp ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/keystore/* ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/server.key
mkdir ${PWD}/organizations/peerOrganizations/org1.example.com/msp/tlscacerts
cp ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/tlscacerts/* ${PWD}/organizations/peerOrganizations/org1.example.com/msp/tlscacerts/ca.crt
mkdir ${PWD}/organizations/peerOrganizations/org1.example.com/tlsca
cp ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/tlscacerts/* ${PWD}/organizations/peerOrganizations/org1.example.com/tlsca/tlsca.org1.example.com-cert.pem
mkdir ${PWD}/organizations/peerOrganizations/org1.example.com/ca
cp ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp/cacerts/* ${PWD}/organizations/peerOrganizations/org1.example.com/ca/ca.org1.example.com-cert.pem
STEP 8: Generating users certificates
Make the following directories.
mkdir -p organizations/peerOrganizations/org1.example.com/users
mkdir -p organizations/peerOrganizations/org1.example.com/users/User1@org1.example.com
STEP 9: Generate the user MSP
fabric-ca-client enroll -u https://user1:user1pw@localhost:7054 — caname ca-org1 -M ${PWD}/organizations/peerOrganizations/org1.example.com/users/User1@org1.example.com/msp — tls.certfiles ${PWD}/organizations/fabric-ca/org1/tls-cert.pem
STEP 10: Admin User
mkdir -p organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com
STEP 11: Generate the org admin MSP
fabric-ca-client enroll -u https://org1admin:org1adminpw@localhost:7054 — caname ca-org1 -M ${PWD}/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp — tls.certfiles ${PWD}/organizations/fabric-ca/org1/tls-cert.pem
STEP 12: Copy the config.yaml file to newly created MSP folder
cp ${PWD}/organizations/peerOrganizations/org1.example.com/msp/config.yaml ${PWD}/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp/config.yaml
This is the process for creating crypto materials for org1, you can follow the same process for Org2 and orderer as well.
