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上，由其来动态签发证书。
