Playground for Hyperledger-证书密钥

上一章我们使用现有的脚本创建并运行了一个区块链，但我们并不知道其背后运行的原理和方式，接下来我们从头开始看看它都做了些什么。

首先把运行中的区块链停止，并恢复原样：

> $ ./byfn.sh -m down

crypto-config

首先，在一个区块链创建之前，我们需要先生成对应各个节点的证书和密钥，我们将使用cryptogen工具来生成各种网络实体的加密材料（x509证书）。这些证书是身份的代表，它们允许在我们的网络实体进行交流和交易时进行签名/验证身份验证。

在first-network文件夹之下，有一个crypto-config.yaml文件，内容如下：

OrdererOrgs:

-Name:Orderer

Domain:example.com

Specs:

-Hostname:orderer

PeerOrgs:

-Name:Org1

Domain:org1.example.comabove

Template:

Count:2

Users:

Count:1

-Name:Org2

Domain:org2.example.com

Template:

Count:2

Users:

Count:1

这里OrdererOrgs里面包含的是共识节点信息，配置文件中只配置了1个共识节点，就是，如果我们要配置多个，那么需要改为：

OrdererOrgs:

-Name:Orderer

Domain:example.com

Template:

Count:3

这里Count: 3表示的就是将有3个orderer节点，现在我们将其改为3个。

PeerOrgs表示的是组织的个数，Template的Count表示组织中自动生成节点的个数。自动生成的节点将自动以peer0、peer1、peer2…这样的命名方式命名。当然，也可以用Specs来指定节点的命名。Users的Count表示该组织中除了admin用户，其他用户的数量。

接下来我们将运行cryptogen工具，生成的证书和密钥将被保存到名为crypto-config的文件夹中。

之前我们从https://goo.gl/byy2Qj 已经下载了cryptogen工具，回到上级目录，可以发现有个bin文件夹，文件夹中有我们需要的configtxgen可执行文件，执行命令：

> $ ../bin/cryptogen generate --config=./crypto-config.yaml

可以看到在crypto-config文件夹中会多出ordererOrganizations和peerOrganizations两个文件夹，里面分别又包含ca、msp、orderers、tlsca、users、peers等文件夹。

crypto-config文件夹中存放了所有节点所需的证书和密钥

仔细分析，里面有很多重复的文件，应该是在生产部署的时候需要把不同的证书文件放到不同的节点中。例如：

//Order-CA证书

ordererOrganizations/example.com/ca/ca.example.com-cert.pem

ordererOrganizations/example.com/msp/cacerts/ca.example.com-cert.pem

ordererOrganizations/example.com/orderers/ordererX.example.com/msp/cacerts/ca.example.com-cert.pem

ordererOrganizations/example.com/users/Admin@example.com/msp/cacerts/ca.example.com-cert.pem

//Order-CA-TLS证书

ordererOrganizations/example.com/tlsca/tlsca.example.com-cert.pem

ordererOrganizations/example.com/msp/tlscacerts/tlsca.example.com-cert.pem

ordererOrganizations/example.com/orderers/ordererX.example.com/msp/tlscacerts/tlsca.example.com-cert.pem

ordererOrganizations/example.com/orderers/ordererX.example.com/tls/ca.crt

ordererOrganizations/example.com/users/Admin@example.com/msp/tlscacerts/tlsca.example.com-cert.pem

//Order-Admin用户证书

ordererOrganizations/example.com/msp/admincerts/Admin@example.com-cert.pem

ordererOrganizations/example.com/orderers/ordererX.example.com/msp/admincerts/Admin@example.com-cert.pem

ordererOrganizations/example.com/users/Admin@example.com/msp/admincerts/Admin@example.com-cert.pem

ordererOrganizations/example.com/users/Admin@example.com/msp/signcerts/Admin@example.com-cert.pem

//Org1证书

peerOrganizations/org1.example.com/ca/ca.org1.example.com-cert.pem

peerOrganizations/org1.example.com/msp/cacerts/ca.org1.example.com-cert.pem

peerOrganizations/org1.example.com/peers/peerX.org1.example.com/msp/cacerts/ca.org1.example.com-cert.pem

peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp/cacerts/ca.org1.example.com-cert.pem

//Org2证书

peerOrganizations/org2.example.com/ca/ca.org2.example.com-cert.pem

peerOrganizations/org2.example.com/msp/cacerts/ca.org2.example.com-cert.pem

peerOrganizations/org2.example.com/peers/peerX.org2.example.com/msp/cacerts/ca.org1.example.com-cert.pem

peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp/cacerts/ca.org1.example.com-cert.pem

//Org1-TLS证书

peerOrganizations/org1.example.com/tlsca/tlsca.org1.example.com-cert.pem

peerOrganizations/org1.example.com/msp/tlscacerts/tlsca.org1.example.com-cert.pem

peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp/tlscacerts/tlsca.org1.example.com-cert.pem

//Org2-TLS证书

peerOrganizations/org2.example.com/tlsca/tlsca.org2.example.com-cert.pem

peerOrganizations/org2.example.com/msp/tlscacerts/tlsca.org2.example.com-cert.pem

peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp/tlscacerts/tlsca.org1.example.com-cert.pem

//Org1-Amin用户证书

peerOrganizations/org1.example.com/msp/admincerts/Admin@org1.example.com-cert.pem

peerOrganizations/org1.example.com/peers/peerX.org1.example.com/msp/admincerts/Admin@org1.example.com-cert.pem

peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp/admincerts/Admin@org1.example.com-cert.pem

peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp/signcerts/Admin@org1.example.com-cert.pem

其中ordererX表示order0、1、2都一样，peerX表示peer0、1都一样。其中还有一些单独的文件：

//Order-CA的私钥

ordererOrganizations/example.com/ca/xxxx_sk

//Order-CA-TLS的私钥

ordererOrganizations/example.com/tlsca/xxxx_sk

//OrderX的私钥

ordererOrganizations/example.com/orderers/ordererX.example.com/msp/keystore/xxxx_sk

//OrderX的证书

ordererOrganizations/example.com/orderers/ordererX.example.com/msp/signcerts/ordererX.example.com-cert.pem

//Orderer admin用户的私钥

ordererOrganizations/example.com/users/Admin@example.com/msp/keystore/3e82a8d7b28d29673070cae73700d2a5bc2d3b2d17ef54e24b1e32a42c22a6f0_sk

//Org1的私钥

peerOrganizations/org1.example.com/ca/xxxx_sk

//Org2的私钥

peerOrganizations/org2.example.com/ca/xxxx_sk

//Org1-TLS的私钥

peerOrganizations/org1.example.com/tlsca/xxxx_sk

//Org2-TLS的私钥

peerOrganizations/org2.example.com/tlsca/xxxx_sk

//Org1-Peer0的私钥

peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp/keystore/xxxx_sk

//Org1-Peer0的证书

peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp/signcerts/peer0.org1.example.com-cert.pem

//Org1-Admin的私钥

peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp/keystore/236cc791991aecf802e068fddb30806bedbcae6df1b5f7795778e666782d4306_sk

由此可见，Order有节点证书和用户证书，根证书和私钥放在ca文件夹，每个Order自己的证书和私钥放在自己的目录中。Org也有节点证书和用户证书，根证书和私钥放在ca文件夹，每个Peer自己的证书和私钥放在自己的目录中。

当区块链运行时，每个实体使用自己的私钥对事件进行签名，使用其他实体的证书（公钥）来对其他实体签名的内容进行验证。

configtx

接下来，我们需要使用configtxgen工具来生成区块链的初始块等基础数据，首先我们需要用到configtx.yaml文件：

Profiles:

TwoOrgsOrdererGenesis:

Orderer:

Organizations:

-*OrdererOrg

Consortiums:

SampleConsortium:

Organizations:

-*Org1

-*Org2

TwoOrgsChannel:

Consortium:SampleConsortium

Application:

Organizations:

-*Org1

-*Org2

Organizations:

-&OrdererOrg

Name:OrdererOrg

ID:OrdererMSP

MSPDir:crypto-config/ordererOrganizations/example.com/msp

-&Org1

Name:Org1MSP

ID:Org1MSP

MSPDir:crypto-config/peerOrganizations/org1.example.com/msp

AnchorPeers:

-Host:peer0.org1.example.com

Port:7051

-&Org2

Name:Org2MSP

ID:Org2MSP

MSPDir:crypto-config/peerOrganizations/org2.example.com/msp

AnchorPeers:

-Host:peer0.org2.example.com

Port:7051

Orderer:&OrdererDefaults

# Available types are "solo" and "kafka"

OrdererType:solo

Addresses:

-orderer.example.com:7050

BatchTimeout:2s

BatchSize:

MaxMessageCount:10

AbsoluteMaxBytes:99MB

PreferredMaxBytes:512KB

Kafka:

Brokers:

-127.0.0.1:9092

Organizations:

Application:&ApplicationDefaults

Organizations:

Profiles模块定义了我们的组织关系，TwoOrgsOrdererGenesis的信息会编码到创世块，TwoOrgsChannel的信息会编码到channel配置交易文件中。

Organizations模块定义了Order和每个Org的名字和MSP证书路径，用于今后的验证。MSP中的每个Org的根证书都会存储到创世块中，为以后使用。并且Org中还定义了AnchorPeers，AnchorPeers节点要求网络能跨组织通信，这些信息都会被编码在创世块中。

接下来是Orderer模块，OrdererType是共识算法，solo用于单节点共识，kafka用于paxos共识。BatchTimeout是生成区块的最大时间间隔，BatchSize.MaxMessageCount是每个区块能包含的交易数量，Kafka.Brokers定义了order节点所使用的kafka节点列表。

由于我们有3个Order节点，需要对Orderer模块稍作修改：

Addresses:

-orderer0.example.com:7050

-orderer1.example.com:7050

-orderer2.example.com:7050

下面我们生成创世块：

> $exportFABRIC_CFG_PATH=$PWD

> $ ../bin/configtxgen -profile TwoOrgsOrdererGenesis -outputBlock ./channel-artifacts/genesis.block

channel-artifacts目录下会多一个文件。

再创建channel的配置交易文件，它用户创建channel时广播到所有Orderer节点：

> $exportCHANNEL_NAME=mychannel

> $ ../bin/configtxgen -profile TwoOrgsChannel -outputCreateChannelTx ./channel-artifacts/channel.tx -channelID $CHANNEL_NAME

为mychannel创建Org1、Org2的Anchor Peer节点所需的配置文件：

> $ ../bin/configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./channel-artifacts/Org1MSPanchors.tx -channelID $CHANNEL_NAME -asOrg Org1MSP

> $ ../bin/configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./channel-artifacts/Org2MSPanchors.tx -channelID $CHANNEL_NAME -asOrg Org2MSP

经过上面的步骤，我们的channel-artifacts文件夹中就包含了、、、四个文件。

我们可以通过下面的命令来查看生产的块和channel信息是否正确：

> $ ../bin/configtxgen -inspectBlock ./channel-artifacts/genesis.block

> $ ../bin/configtxgen -inspectChannelCreateTx ./channel-artifacts/channel.tx

我们上面做的所有事情，其实就等价于byfn.sh文件中的方法。

准备工作差不多了，下一章我们将开始启动网络~