蝸牛講技術，滿滿的都是干貨，你值得關注。
之前我們講了通過
./byfn.sh generate的作用是 用於生成fabric網絡中的組件公私鑰證書信息以及初始的交易信息。如果只是要生成相關證書信息，也可以直接使用fabric提供的cryptogen 工具完成這一步工作，命令如下：
cryptogen generate --config=./crypto-config.yaml
具體是怎么生成的，由crypto-config.yaml配置文件決定。我們將詳細介紹是如何產生證書文件，已經生成了哪些證書文件。
讀取crypto-config.yaml配置信息
cryptogen工具會讀取 crypto-config.yaml中的所有配置，把內容解析到名為 OrdererOrgs和 PeerOrgs的數據結構中，其實這兩個對應的就是crypto-config.yaml 中的兩個根節點或是一級節點（這里是把yaml看成和xml一樣的文件格式），這兩個的類型為OrgSpec，類型的定義如下：
type OrgSpec struct {
Name string `yaml:"Name"`
Domain string `yaml:"Domain"`
EnableNodeOUs bool `yaml:"EnableNodeOUs"`
CA NodeSpec `yaml:"CA"`
Template NodeTemplate `yaml:"Template"`
Specs []NodeSpec `yaml:"Specs"`
Users UsersSpec `yaml:"Users"`
}
這里也可以看出OrdererOrgs和 PeerOrgs是由哪些子節點組成的（這里說的節點是 文件內容里的標簽節點，而不是fabric里所的網絡節點）
解析PeerOrgs
假如當前的一個PeerOrgs配置如下：
- Name: Org2
Domain: org2.example.com
EnableNodeOUs: true
Template:
Count: 2
Users:
Count: 1-
根據Template的count數量（這個count決定了這個org2.example.com的域名下有多少個節點），生成相應數量的hostname, 並把 這些hostname信息放在specs下，可以看成會生成如下格式，以yaml文件格式表示：
- Name: Org2
Domain: org2.example.com
EnableNodeOUs: true
Template:
Count: 2
Users:
Count: 1
Specs:
-Hostname:peer0
-Hostname:peer1
-
處理yaml:Specs節點的配置
1. 首先會根據提供的模板
"{{.Hostname}}.{{.Domain}}"生成兩個CommonName ：
peer0.org2.example.com
peer1.org2.example.com。
2. 之后處理SAN (Subject Alternative Names), SAN是一個可選配置，主要是用於指定要生成的X509中的一個或是多個SAN，可以為hostname, commonname 或是IP地址形式。處理規則是：如果有指定CommonName, 就用指定的CommonName為解析模板，否則就是用默認的CommonName解析模板，數據源為hostName和 Domain, 這個例子中就為 peer0 (peer1)和 org2.example.com。 默認的解析模板為：
"{{.Hostname}}.{{.Domain}}"例子中由於沒有指明CommonName,所以直接用默認模板，解析結果為：
peer0.org2.example.com
peer1.org2.example.com
3. 之后是拼接SANS，根據上面的解析結果，默認設置的SANS為hostname和 CommonName, 也就是peer0(peer1)和peer0.org2.example.com (peer1. org2.example.com)。如果配置文件上有指定其他的CommonName,就把這兩個加入到指定的CommonName中，一起作為SANS，在生成正式的時候使用。
下面是一個完整的Specs的示例,配置的時候可以參考
Specs:
- Hostname: foo # implicitly "foo.org1.example.com"
CommonName: foo27.org5.example.com
SANS:
- "bar.{{.Domain}}"
- "altfoo.{{.Domain}}"
- "{{.Hostname}}.org6.net"
- 172.16.10.31
- Hostname: bar
- Hostname: baz
-
處理yaml:CA 的配置。如果沒有指定ca配置，默認的ca的hostname為ca, 其它處理過程和yaml:Specs完全一致。
下面是CA配置的一個完整示例：
CA:
Hostname: ca # implicitly ca.org1.example.com
Country: US
Province: California
Locality: San Francisco
OrganizationalUnit: Hyperledger Fabric
StreetAddress: address for org # default nil
PostalCode: postalCode for org # default nil
生成證書和公私鑰
-
生成節點的CA證書。創建 crypto-config/peerOrganizations/{domain}/ca 目錄，例子中為org.example.com。根據yaml:CA的配置，使用fabric的加密服務提供程序(bccsp)，生成P256的橢圓加密算法的私鑰和公鑰，然后使用ca中指定的 country, province，common name等信息生成包含公鑰信息的ca.org2.example.com-cert.pem 文件
-
生成tls的證書。同上面的ca證書，只不過tls證書中的common name為 tlsca, 而上面的ca證書中的common name為ca
-
把ca下的證書和tls證書導入到crypto-config/peerOrganizations/org2.example.com/msp/cacerts和crypto-config/peerOrganizations/org2.example.com/msp/tlscacerts下
-
如果設置了EnableNodeOUs，就在msp下生成config.yaml文件
-
根據配置的節點信息，為每一個節點創建本地的msp, 包括兩部分：
第一部分為創建peers/{commonName}/msp 。例子中的就為：peers/peer0.org2.example.com/msp
peers/peer1.org2.example.com/msp
這部分證書都是通過csp產生一個keystore私鑰，然后使用這個私鑰對應的公鑰生成admincerts，cacerts，signcerts 的證書。而cacerts下的證書和peerOrganizations/{domain}/ca下ca.{domain}-cert.pem是完全一樣的。tlscacerts 下的證書也和{domain}下其他的tlscacerts文件夾下的證書完全一致。
第二部分是生成peers/{commonName}/tls目錄下的公私鑰證書,例子中為：peers/peer0.org2.example.com/tls
peers/peer1.org2.example.com/tls
這部分證書是重新生成的。包含一個ca證書，一個公鑰證書和一個私鑰證書。如果節點類型為 client，就生成客戶端的公鑰證書和私鑰證書，如果節點類型為orderer或是peer類型，就生成服務端相關的證書。私鑰存在serer.key內。ca.crt是把證書內容通過x509.ParseCertificate轉換得到，而server.crt是通過把寫入了證書內容的pem文件直接重命名成crt文件得到。
-
根據配置的yaml:Users下的yaml:Count 的數目，來為每個用戶生成用戶信息，生成的內容和步驟和3.5完全一致。用戶名的生成規則為：從1開始循環遞增到Count, 每個用戶名為："User" + index + @ + Domain , 例子中就為：User1@org2.example.com。默認會有一個admin用戶。
-
把用戶下的signcerts 作為admincerts copy到org1.example.com/msp/admincerts和org1.example.com/peers/{CommonName}/admincerts下。
到此，節點相關的所有證書信息已經生成。接下來是生成orderer相關的證書信息，過程和節點完全類似，這里就不累贅描述了。
覆蓋完整的區塊鏈知識體系，從入門到源碼，這里有真正想要的區塊鏈技術，歡迎大家關注微信號：蝸牛講技術。掃下面的二維碼
