Hyperledger Fabric提供了一个用开生成相关证书的模块，叫做cryptogen。这个工具会根据用户指定的配置文件生成相关的证书

在使用cryptogen生成证书之前，我们首先要了解Fabric的架构和管理逻辑。从高层次来说，Fabric的参与者被称为组织Org，所有组织会共同维护一个用来排序节点的集群称为orderer，各个组织内部会维护若干台peer节点，用于接受客户端请求和记账。
除此之外，每类节点都可以包含若干用户，必须有一个Admin用户，每个节点和用户

在通信时，节点之间可以设置通过TLS加密，这就需要TLS的证书，因此Fabric的证书分为两类MSP和TLS。

Orderer类型
  -  联盟（这里称为联盟是因为Orderer由多个组织合作共同维护的排序节点集群，便于理解）

Peer类型
  -  组织1
  -  组织2
  -  组织3
    -  peer节点
      -  peer0节点
      -  peer1节点
          - msp 
          - tls
    -  用户
      -  Admin
      -  User1
          - msp 
          - tls

生成证书

配置文件

cryptogen提供了下面的命令，用来生成配置模板

cryptogen showtemplate

修改配置文件为下面的内容，其中指定了Order类型的联盟名称jianshu.com，Peer类型指定了有两个组织，分别为org1.jianshu.com和org2.jianshu.com,两个组织分别有2个peer节点和3/2个用户。

OrdererOrgs:
    - Name: Orderer
      Domain: jianshu.com
      Specs:
            - Hostname: orderer
      Template:
            Count: 2
PeerOrgs:
    - Name: Org1
      Domain: org1.jianshu.com
      Template:
            Count: 2
      Users:
            Count: 3
    - Name: Org2
      Domain: org2.jianshu.com
      Template:
          Count: 2
      Users:
          Count: 2

生成证书

使用下面的命令可以根据配置文件生成证书文件

cryptogen generate --config=crypto-config.yaml --output ./crypto-config

证书结构

进入crypto-config文件夹，使用tree -L 2可以查看目录的结构

├── ordererOrganizations
│   └── jianshu.com
│       ├── ca
│       ├── msp
│       ├── orderers
│       ├── tlsca
│       └── users
└── peerOrganizations
    ├── org1.jianshu.com
    │   ├── ca
    │   ├── msp
    │   ├── peers
    │   ├── tlsca
    │   └── users
    └── org2.jianshu.com
        ├── ca
        ├── msp
        ├── peers
        ├── tlsca
        └── users

从上面的结构来说，内部主要根据节点类型来划分，Orderer类型保护一个联盟，Peer类型有两个组织。

证书详解

由于Orderer类型的联盟和Peer类型的组织内的证书结构是一样的，我们org1.jianshu.com为例，了解其内部的结构。首先，使用tree命令打印出这个文件夹下的内容，-L后面的数字可以调整层次。

├── org1.jianshu.com
│   ├── ca
│   │   ├── ca.org1.jianshu.com-cert.pem
│   │   └── 965e1493f4_sk
│   ├── tlsca
│   │   ├── 2312a9c0380eb48d343_sk
│   │   └── tlsca.org1.jianshu.com-cert.pem
│   ├── msp
│   │   ├── admincerts
│   │   ├── cacerts
│   │   └── tlscacerts
│   ├── peers
│   │   ├── peer0.org1.jianshu.com
│   │   └── peer1.org1.jianshu.com
│   └── users
│       ├── Admin@org1.jianshu.com
│       ├── User1@org1.jianshu.com
│       ├── User2@org1.jianshu.com
│       └── User3@org1.jianshu.com

• 对于一个组织来说，其有两类根证书，一类是用户根证书，一类是用来TLS通信的根证书，分别在ca和tlsca文件夹内部。
• msp文件夹是组织的身份文件，内部包含了Admin证书admincerts，组织根证书cacerts和tls的根证书tlscacerts
• peers中包含了组织org1.jianshu.com各个peer节点的相关认证文件
• users中包含了组织org2.jianshu.com各个用户的相关认证文件

ca和tlsca

下面我们以ca为例，验证一下根证书。ca内部以_sk结尾的是组织org1.jianshu.com的私钥，pem是组织org1.jianshu.com的自签名根证书。

查看根证书信息

openssl x509 -in root.crt -text | less

验证证书与私钥匹配

下面是一个验证脚本，参数1是证书，参数2是私钥，保存为certcheck.sh，修改权限后可以执行

#!/bin/bash
if [[ "$1" = "" || "$2" = "" ]]; then
    echo "certCheck.sh  certfile keyfile"  
    exit 0;
else
    #certModuleMd5=`openssl x509 -noout -modulus -in $1 | openssl md5`
    #privateModuleMd5=`openssl rsa -noout -modulus -in $2 | openssl md5`


        #if [  "$certModuleMd5" = "$privateModuleMd5" ] ; then
        #        echo "ok"
    #else
    #   echo "not ok"
        #fi
        value=`openssl x509 -text -noout -in $1  | grep "Public Key Algorithm:" | awk  -F ':'  'BEGIN {}  {print $2} END {}'`

        if [ "$value" = " rsaEncryption" ] ; then
                echo $value

                requestModuleMd5=`openssl x509 -modulus -in $1 | grep Modulus | openssl md5`
                privateModuleMd5=`openssl rsa -noout -modulus -in $2 | openssl md5`

        else
                `openssl ec -in $2 -pubout -out ecpubkey.pem `
                privateModuleMd5=`cat ecpubkey.pem | openssl md5`
                requestModuleMd5=`openssl x509 -in $1  -pubkey  -noout | openssl md5`

        fi
        if [  "$requestModuleMd5" = "$privateModuleMd5" ] ; then
                echo "ok"
        fi


fi

执行下面命令，输出ok说明私钥和证书是匹配的

./certcheck.sh peerOrganizations/org1.jianshu.com/ca/ca.org1.jianshu.com-cert.pem peerOrganizations/org1.jianshu.com/ca/fab24049c802a9bfcd056753c1175fe369f728c531315f106aeb11965e1493f4_sk 
read EC key
writing EC key
ok

msp文件夹

msp文件夹中分别保存了组织org1.jianshu.com的相关根证书

├── msp
│   ├── admincerts   [Admin用户的证书]
│   │   └── Admin@org1.jianshu.com-cert.pem
│   ├── cacerts   [ca的根证书]
│   │   └── ca.org1.jianshu.com-cert.pem
│   └── tlscacerts   [tlsca的根证书]
│       └── tlsca.org1.jianshu.com-cert.pem

ca.org1.jianshu.com-cert.pem与tlsca.org1.jianshu.com-cert.pem分别与ca和tlsca下的同名文件内容一样， 可以通过md5sum命令查看。

# ca下
md5sum ca/ca.org1.jianshu.com-cert.pem 
00067a1e3e1ec302e7c3e66433bc73ed  ca/ca.org1.jianshu.com-cert.pem
# msp/cacerts下
md5sum msp/cacerts/ca.org1.jianshu.com-cert.pem 
00067a1e3e1ec302e7c3e66433bc73ed  msp/cacerts/ca.org1.jianshu.com-cert.pem

至于admincerts的Admin@org1.jianshu.com-cert.pem文件也是Admin用户的证书，与Admin@org1.jianshu.com里面的证书一样。

peers文件夹

peers文件夹内有两个peer节点，分别是peer0.org1.jianshu.com和peer1.org1.jianshu.com，先以peer0为例说内部的结构

├── peer0.org1.jianshu.com
│   ├── msp
│   │   ├── admincerts    [组织Org1的Admin用户证书]
│   │   │   └── Admin@org1.jianshu.com-cert.pem
│   │   ├── cacerts        [组织Org1的CA根证书]
│   │   │   └── ca.org1.jianshu.com-cert.pem
│   │   ├── keystore    [组织Org1的peer0节点的证书的私钥]
│   │   │   └── eba279fe94e117473da7eee00_sk
│   │   ├── signcerts    [组织Org1的peer0节点的证书，由组织Org1的CA根证书签发]
│   │   │   └── peer0.org1.jianshu.com-cert.pem
│   │   └── tlscacerts    [组织Org1的tls的根证书]
│   │       └── tlsca.org1.jianshu.com-cert.pem
│   └── tls
│       ├── ca.crt   [组织Org1的tls的根证书，与tlscacerts下的一样]
│       ├── server.crt   [由组织Org1的tls的根证书签发的用于tls通信的证书]
│       └── server.key [由组织Org1的tls的根证书签发的用于tls通信的证书的私钥]

• 在上面的结构中，signcerts是peer节点peer0的证书，keystore是与这个证书对应的私钥;具体可以使用之前的脚本进行验证
• 其他都是peer0所属的组织Org1的相关证书。
• tls文件夹下是peer0进行tls通信时使用的证书server.crt和私钥server.key,而ca.crt是组织Org1的tls根证书

users文件夹

users文件夹内部结构与peers文件夹一致，主要包含了每个用户的msp证书和私钥，tls通信使用的证书和私钥。

每个组织都有自己的msp根证书和tls根证书，每个组织都包含若干的peer节点和user用户，他们自己的证书都是通过相对应类型的根证书签发的。而且，从文件夹的结构，我们也可以看出，每个证书都可以从文件名称看出是何种证书。

在下一节中，我们将会启动Fabric-CA的服务器，并将其绑定到组织org1.jianshu.com上，由其来动态签发证书。