蝸牛講-fabric原理之證書生成


 

蝸牛講技術,滿滿的都是乾貨,你值得關注。算法


 

以前咱們講了經過微信

./byfn.sh  generate

的做用是 用於生成fabric網絡中的組件公私鑰證書信息以及初始的交易信息。若是隻是要生成相關證書信息,也能夠直接使用fabric提供的cryptogen 工具完成這一步工做,命令以下:網絡

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

具體是怎麼生成的,由crypto-config.yaml配置文件決定。咱們將詳細介紹是如何產生證書文件,已經生成了哪些證書文件。數據結構

 

讀取crypto-config.yaml配置信息dom

 

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裏所的網絡節點)post

 

解析PeerOrgs區塊鏈

 

假如當前的一個PeerOrgs配置以下:ui

 - 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相關的證書信息,過程和節點徹底相似,這裏就不累贅描述了。

 


 

覆蓋完整的區塊鏈知識體系,從入門到源碼,這裏有真正想要的區塊鏈技術,歡迎你們關注微信號:蝸牛講技術。掃下面的二維碼

相關文章
相關標籤/搜索