Hyperledger Fabric msp structure

The following is a directory and file structure, the directory and files were created by default by peer.

the focus here is the msp directory. Here are the observations:

1. admincert.pem and peer.pem (the signcerts) are the same file.
2. config.yaml file contains things almost hardcoded.
3. key.pem is the private key to admincert.pem



Here are more detailed structures in terms of the various certificates for an org and the node in the org.

The following chart shows the various certs for an organization. There should be ca, tlsca and msp. ca and tlsca should be consist of a cert and its private key. The msp should contain its admin cert, ca cert and tlscacert. The ca cert and tlscacert under msp should be the same as in ca and tlsca. All these certs organized just to make sure that the msp directory contains necessary files which can be distributed. The ca and tlsca directory also contains the private key which should not be distributed. Also notice that the ca/ca.ordererorg-cert.pem is the same file as in msp/cacerts/ca.ordererorg-cert.pem (green boxed), and tlsca/tlsca.ordererorg-cert.pem is the same file as in msp/tlscacerts/tlsca.orderorg-cert.pem (red boxed)

the followingchart shows the various certs for a node within an organization.

1. There are two top directories, msp and tls
2. msp contains materials which a node (orderer or peer) msp configuration should point to. This directory also contains the organization ca certs
3. signcerts is the signing cert for the node, the keystore direcotry contains the private key for the signing cert.
4. tls contains the tls cert and key,  tls/ca.crt is the same file as in organization's tlsca cert. Notice that tlsca file contained in two different directories even though they are the same file (red boxed).

Any thing that labeled ca will be the same as in the organization's certificates.

fabric-ca working flow

Once a Fabric CA is setting up,  with the initial admin and password set to be tongli and tonglipw,  then admin can then do the following:


1. enroll a new users:

fabric-ca-client enroll --id.name admin2 -u https://tongli:tonglipw@u1804:7054 --tls.certfiles $(pwd)/cakeys/ca.org1-cert.pem

Notice that the cert pem file at the end has to be the ca certificate

2. Once a user is enrolled, the admin can register the user which will provide a password for the user:

fabric-ca-client register --id.name admin2  --id.attrs 'hf.Revoker=true,admin=true:ecert'   -u https://tongli:tonglipw@u1804:7054 --tls.certfiles $(pwd)/cakeys/ca.org1-cert.pem

3. You can also add affiliation by doing the following:

   a) enroll a new user:
fabric-ca-client enroll --id.name admin -u https://tongli:tonglipw@u1804:7054 --tls.certfiles $(pwd)/cakeys/ca.org1-cert.pem

   b) register the new user
fabric-ca-client register --id.name admin  --id.attrs 'hf.Revoker=true,admin=true:ecert' -u https://tongli:tonglipw@u1804:7054 --tls.certfiles $(pwd)/cakeys/ca.org1-cert.pem

   c) now add the new affiliation
fabric-ca-client affiliation add org1 -u https://admin:qxuPwzKYVFAn@u1804:7054 --tls.certfiles $(pwd)/cakeys/ca.org1-cert.pem

   d) nested affiliation just need to use dot, for example
fabric-ca-client affiliation add org1.department1.department1 -u https://admin:qxuPwzKYVFAn@u1804:7054 --tls.certfiles $(pwd)/cakeys/ca.org1-cert.pem


 One can enroll many ids, the difference for user, peer, orderer is how these id get registered. When register the id, you will need to specify a type for example:

export FABRIC_CA_CLIENT_HOME=$HOME/fabric-ca/clients/admin
fabric-ca-client register --id.name client1 --id.type client \

  --id.affiliation bu1.department1.Team1 

The created user signcerts should be named <id>@<org name>-cert.pem

 Otherwise, gosdk can not find the certificate, the access will fail. 

Customize VSCode colors

Click on settings (the wheel icon at the bottom left), which will open up the Settings on the right hand side, then select Workbench->Appearance, find the link says Edit in settings.json, basically paste the following then save.

   "workbench.colorCustomizations": {
        "sideBar.background": "#424d66",
        "sideBar.foreground": "#ffffff",
        "sideBar.dropBackground": "#c0aeae",
        "list.hoverForeground": "#ffffff",
        "list.hoverBackground": "#2825df",
        "gitDecoration.modifiedResourceForeground": "#ffffff",
        "gitDecoration.untrackedResourceForeground": "#ffffff",
        "gitDecoration.addedResourceForeground": "#ffffff",
        "list.errorForeground": "#ffffff",
        "list.inactiveSelectionBackground": "#ff2200",
        "list.inactiveSelectionForeground": "#ffffff",
        "list.activeSelectionForeground": "#ffffff",
        "list.activeSelectionBackground": "#ff2200"
    }

If you like to change the color scheme globally, then you will need to do the following:

Click on settings, select User -> Workbench -> Appearance, then find

Color Customizations section on the right, click on Edit in settings.json, then add the

same section above in the file. 

What are the Digital Signatures

The actually signing probably depends on what kind of certificate it is. this is a useful read.

A digital certificate consists of three things:

• A public key.
• Certificate information. ("Identity" information about the user, such as name, user ID, and so on.)
• One or more digital signatures.

Typically the "one of more digital signatures" part is done by listing an set of encrypted hashes of the certificate. So when you want to sign a certificate, you would compute the hash of the certificate, encrypt it using your private signing key, and add it to the list of digital signatures.

 So in a sense, that the certificate is a production of a private key applied to a bunch of information. So whoever receive that certificate will be able to see that person's public key, identity information, then will be able to use the public key to digest the digital signature to make sure that the hash come out of the decrypted digital signature match the certificate part of identity part of the information. so that you know this is real.

How to create cds file

Assume that your chaincode is in a directory named node, and use the following command to generate the cds file.

1. Cd to the directory which is the parent directory of the node directory
2. Run the following command:

docker run --rm --name peer --entrypoint peer -v $(pwd):/mychaincode hyperledger/fabric-peer chaincode package -n mycc -p /mychaincode/node -l node -v 1.0.0 /mychaincode/test.cds

This creates a file named test.cds in the current directory named mycc with version 1.0.0

Setup dev environment for k8s operator

The process is to setup k8s operator dev environment

1. Install docker, kubectl, golang and mercurial etc. using the method from each product
2. Setup git config if you have not:

    git config --global user.email "your email address here"
    git config --global user.name "Tong Li"  

3. Add the following to the end of your .profile:

    export PATH=$PATH:/usr/local/go/bin
    export GOROOT=/usr/local/go
    export GOBIN=$GOROOT/bin
    export GOPATH=~/hl
    export GO111MODULE=on

    The above assumes that your golang is installed in to /usr/local/go directory and you have
    a directory in your home named hl

4. To be able to create an operator, you will need to first create a directory under $GOPATH, the run the operator creation command:

   mkdir $GOPATH/myproject
   cd $GOPATH/myproject
   operator-sdk new myfirst

Commands to check if the cert and private key match

openssl pkey -in privateKey.key -pubout -outform pem | sha256sum
openssl x509 -in certificate.crt -pubkey -noout -outform pem | sha256sum