蜗牛讲-fabric原理之证书生成

---

 

蜗牛讲技术，满满的都是干货，你值得关注。

---

 

以前咱们讲了经过

./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

 

生成证书和公私钥

 

1. 生成节点的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 文件

    

2. 生成tls的证书。同上面的ca证书，只不过tls证书中的common name为 tlsca, 而上面的ca证书中的common name为ca

    

3. 把ca下的证书和tls证书导入到crypto-config/peerOrganizations/org2.example.com/msp/cacerts和crypto-config/peerOrganizations/org2.example.com/msp/tlscacerts下

    

4. 若是设置了EnableNodeOUs，就在msp下生成config.yaml文件 

5. 根据配置的节点信息，为每个节点建立本地的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文件获得。

    

6. 根据配置的yaml:Users下的yaml:Count 的数目，来为每一个用户生成用户信息，生成的内容和步骤和3.5彻底一致。用户名的生成规则为：从1开始循环递增到Count, 每一个用户名为："User" + index + @ + Domain , 例子中就为：User1@org2.example.com。默认会有一个admin用户。

    

7. 把用户下的signcerts 做为admincerts copy到org1.example.com/msp/admincerts和org1.example.com/peers/{CommonName}/admincerts下。

    

到此，节点相关的全部证书信息已经生成。接下来是生成orderer相关的证书信息，过程和节点彻底相似，这里就不累赘描述了。

 

---

 

覆盖完整的区块链知识体系，从入门到源码，这里有真正想要的区块链技术，欢迎你们关注微信号：蜗牛讲技术。扫下面的二维码