[Fabric]-First-Network (crypto-config.yaml详解)

[Fabric]-First-Network (crypto-config.yaml详解)

文章目录

• • • 1. 简介
    • 2. 具体配置信息
    • • （1）OrdererOrgs
      • （2）PeerOrgs
    • 3. 使用

参考：配置文件
很感谢大佬的文章，茅塞顿开，下面我又看了点书写的.
希望对大家有一点点的帮助。不对的地方希望指正。

1. 简介

用于生成相关组织的私钥和证书

fabric网络中有两种类型的公私钥和证书

• 给节点之间通讯安全而准备的TLS证书
• 用户登录和权限控制的用户证书

2. 具体配置信息

主要分为两大块：OrdererOrgs、PeerOrgs

# 排序节点组织的定于
OrdererOrgs:
 
  - Name: Orderer
    #组织的域名
    Domain: example.com
    Specs:
      - Hostname: orderer
        CommonName: orderer.test.com
      # - Hostname: orderer2
      # - Hostname: orderer3
      # - Hostname: orderer4
      - Hostname: orderer5
        CommonName: orderer5.test.com

# peer节点的组织的定义
PeerOrgs:

  - Name: Org1
    Domain: org1.example.com
    ## 如果设置了 EnableNodeOUs ，就在msp下生成config.yaml文件
    EnableNodeOUs: true
    # Specs:
    #   - Hostname: foo # implicitly "foo.org1.example.com"
    #     CommonName: foo27.org5.example.com # overrides Hostname-based FQDN set above
    #   - Hostname: bar
    #   - Hostname: baz
    Template:
      Count: 2
    Users:
      Count: 1
  - Name: Org2
    Domain: org2.example.com
    EnableNodeOUs: true

    Template:
      Count: 2
    Users:
      Count: 1

（1）OrdererOrgs

排序节点的组织的定义，在定义排序节点时，会同时指定节点名称，节点域名以及指定一个规范（Specs）。

（2）PeerOrgs

peer节点的组织的定义，在定义peer节点时，与排序节点一样类似的配置。

peer节点的配置由两种方案，一种是通过规范列表指定，一种是通过模板创建的方式实现。

1. Template

# 组织名称
- Name: Org1
# 域名
    Domain: org1.example.com
# 允许通过该模板定义创建 0->count-1 个组织节点
    Template: 
      Count: 2
# 除了admin以外的创建用户，其中count定义代表创建的用户数量
    Users:
      Count: 1

2. Specs

 - Name: Org1
    Domain: org1.example.com
    Specs:
      # 指定了节点目录和文件名。生成的就是foo27.org5.example.com
      - Hostname: foo 
        CommonName: foo27.org5.example.com 
      # 不指定默认就是“{{.HostName}}.{{.Domain}}”
      # 比如：bar.org1.example.com
      - Hostname: bar
      - Hostname: baz

默认选择第一种就行，而且这两种方案不冲突，可以同时定义，但是要注意名称不能冲突。

3. 使用

Fabric使用了cryptogen工具用来调用上面的配置文件生成私钥和证书

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

执行完以后，会在当前目录生成一个 crypto-config 目录，当然也可以在命令中添加 --output 选项来指定输出的目录。在这个目录下就会根据 Orderer 和Peer 各自生成两个文件夹：

• ordererOrganizations
• peerOrganizations

它们分别代表着orderer和peer的组织及对应目录下的证书文件。

每个组织下都有ca，tlsca，msp，orderers（或者peers），users等5个文件，下面通过tree命令的输出结果，分别解释一下各个目录的作用。

• 目录结构

crypto-config
├── ordererOrganizations  ## 组织配置
│   └── example.com       ## 组织根域名 
│       ├── ca                  ## 存放组织根证书以及私钥
│       │   ├── 4c08c6dc603f08dac6dd490491ac7de077a954bc28150b8ad5b87b78cb8ed5c0_sk  ## 私钥
│       │   └── ca.example.com-cert.pem
│       ├── msp           ## 存放该组织身份信息
│       │   ├── admincerts  ## 组织管理员
│       │   │   └── Admin@example.com-cert.pem  ## 管理员身份验证证书，被根证书签名
│       │   ├── cacerts  ## 组织的根证书
│       │   │   └── ca.example.com-cert.pem  ## 组织的根证书，与ca中的一致
│       ├── config.yaml  ## 配置文件中加了 EnableNodeOUs 参数生成的config.yaml文件，记录 OrganizationalUnitIdentitifiers 信息，包括根证书位置和ID信息 
│       │   └── tlscacerts  ## 用于TLS的CA证书
│       │       └── tlsca.example.com-cert.pem  ## 用于TLS的CA证书，自签名
│       ├── orderers  ## 存放所有 Orderer 的身份信息
│       │   └── orderer.example.com
│       │       ├── msp
│       │       │   ├── admincerts  ## 组织管理员的身份验证证书，与 msp.admincerts 保持一致
│       │       │   │   └── Admin@example.com-cert.pem  ## orderer被给予这些证书来确认交易签名是否为管理员签名
│       │       │   ├── cacerts  ## 存放组织根证书，与CA目录里一致
│       │       │   │   └── ca.example.com-cert.pem
│       │       │   ├── keystore  ## 本节点的身份私钥，用来签名
│       │       │   │   └── 34fe6b5e8cd256a6fc23bc6ff70819f4a3cd2df1b228599e826efed92617a61f_sk
│       │       │   ├── signcerts  ## 验证本节点签名的证书，被根证书签名
│       │       │   │   └── orderer.example.com-cert.pem
│       │       │   └── tlscacerts  ## TLS连接用的身份z书，与 msp.tlscacerts 保持一致
│       │       │       └── tlsca.example.com-cert.pem
│       │       └── tls  ## TLS的相关信息
│       │           ├── ca.crt   ## 组织的根证书
│       │           ├── server.crt   ## 验证本节点签名的证书，被根证书签名
│       │           └── server.key   ## 本节点的身份私钥，用来签名
│       ├── tlsca  ## 存放tls相关的证书和私钥
│       │   ├── e20de2f55b528a5150a897f5647e09fe20bea62b7b9dcab5e5abc59bf66a5b10_sk
│       │   └── tlsca.example.com-cert.pem
│       └── users  ## 存放属于该组织的用户的实体
│           └── Admin@example.com  ## 管理员用户的信息，其中包括msp证书和tls证书两类
│               ├── msp
│               │   ├── admincerts   ## 组织管理员的身份验证证书，与 msp.admincerts 保持一致
│               │   │   └── Admin@example.com-cert.pem
│               │   ├── cacerts  ## 存放组织根证书，与CA目录里一致
│               │   │   └── ca.example.com-cert.pem
│               │   ├── keystore  ## 本用户的身份私钥，用来签名
│               │   │   └── 1718d4afba538037e0adc508de9c13274753b800c09badf1fa64be46d828eb94_sk
│               │   ├── signcerts ## 验证本用户的身份验证证书，被根证书签名，要被某个Orderer认可，则必须放到该 Orderer 的msp/admincerts目录下，因此上面ordere的 msp/admincerts目录下的证书应该要是从这里复制一份过去
│               │   │   └── Admin@example.com-cert.pem
│               │   └── tlscacerts  ## TLS连接用的身份z书，与 msp.tlscacerts 保持一致
│               │       └── tlsca.example.com-cert.pem
│               └── tls  ## TLS的相关信息
│                   ├── ca.crt
│                   ├── client.crt  ## 管理员身份验证证书，被根证书签名
│                   └── client.key  ## 管理员的身份私钥，用来签名

└── peerOrganizations  ## peer组织
    └── org1.example.com  ## 第一个组织的所有身份z书
        ├── ca ## 存放私钥与组织根证书
        │   ├── bad4233ca8315ab62e24bcc0c4f02f0fce954be488b461c3037278d0facad870_sk
        │   └── ca.org1.example.com-cert.pem
        ├── msp ## msp信息与order组织类似
        │   ├── admincerts
        │   │   └── Admin@org1.example.com-cert.pem
        │   ├── cacerts
        │   │   └── ca.org1.example.com-cert.pem
        │   ├── config.yaml
        │   └── tlscacerts
        │       └── tlsca.org1.example.com-cert.pem
        ├── peers
        │   └── peer0.org1.example.com
        │       ├── msp
        │       │   ├── admincerts
        │       │   │   └── Admin@org1.example.com-cert.pem
        │       │   ├── cacerts
        │       │   │   └── ca.org1.example.com-cert.pem
        │       │   ├── config.yaml
        │       │   ├── keystore
        │       │   │   └── e4441bca94a8c89345aa166858657e691c28eb236938018cf4f13d1d9661b66c_sk
        │       │   ├── signcerts
        │       │   │   └── peer0.org1.example.com-cert.pem
        │       │   └── tlscacerts
        │       │       └── tlsca.org1.example.com-cert.pem
        │       └── tls
        │           ├── ca.crt
        │           ├── server.crt
        │           └── server.key
        ├── tlsca
        │   ├── c399a9854b0100e3c6eaadd8a8760f94af180c25576b2c0668896968a2e9b9b4_sk
        │   └── tlsca.org1.example.com-cert.pem
        └── users
            ├── Admin@org1.example.com
            │   ├── msp
            │   │   ├── admincerts
            │   │   │   └── Admin@org1.example.com-cert.pem
            │   │   ├── cacerts
            │   │   │   └── ca.org1.example.com-cert.pem
            │   │   ├── keystore
            │   │   │   └── d1ccedf3f161d0309930ae514b12d0c528ef2153112e9503fed811fba302ef31_sk
            │   │   ├── signcerts
            │   │   │   └── Admin@org1.example.com-cert.pem
            │   │   └── tlscacerts
            │   │       └── tlsca.org1.example.com-cert.pem
            │   └── tls
            │       ├── ca.crt
            │       ├── client.crt
            │       └── client.key
            └── User1@org1.example.com
                ├── msp
                │   ├── admincerts
                │   │   └── User1@org1.example.com-cert.pem
                │   ├── cacerts
                │   │   └── ca.org1.example.com-cert.pem
                │   ├── keystore
                │   │   └── 3cbf4656b8f98907827b0126375a381433b5d93cfe6a2c2e9be0265fbc4b6003_sk
                │   ├── signcerts
                │   │   └── User1@org1.example.com-cert.pem
                │   └── tlscacerts
                │       └── tlsca.org1.example.com-cert.pem
                └── tls
                    ├── ca.crt
                    ├── client.crt
                    └── client.key

• 在一个组织内部（orderer的example.com，peer的org1.example.com，或peer的org2.example.com），所有的admincerts是一样的。admin的私钥在Users的Admin文件夹下
• 在一个组织内部，所有的cacerts是一样的，ca的私钥在ca文件夹下
• 在一个组织内部，所有的tlscacerts是一样的，且和tls文件夹下的ca.crt文件一样。tlsca的私钥在tlsca文件夹下