Question

我已经使用cryptogen生成了证书。

并使用openssl检查了生成的证书，发现该证书缺少可用于区分对等角色和客户端角色的信息。我相信admin是可以区分的，因为管理证书是用区块链编写的，但是没有有关客户端和对等方的信息。

Certificate:
    Data:
        Version: 3 (0x2)
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: C = US, ST = California, L = San Francisco, O = test.com, CN = ca.test.com
        Validity
            Not Before: Sep 19 01:49:00 2019 GMT
            Not After : Sep 16 01:49:00 2029 GMT
        Subject: C = US, ST = California, L = San Francisco, CN = User1@test.com
...

Certificate:
    Data:
        Version: 3 (0x2)
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: C = US, ST = California, L = San Francisco, O = test.com, CN = ca.test.com
        Validity
            Not Before: Sep 19 01:49:00 2019 GMT
            Not After : Sep 16 01:49:00 2029 GMT
        Subject: C = US, ST = California, L = San Francisco, CN = p0.test.com
...

（我所看到的唯一区别是主题的CN，密钥和ID相关的内容）

我想知道的原因是，尽管无法区分它们的角色，但是由于加入频道时CSCC失败，因此无法使用客户端的MSP来支持节点设置。

Error: proposal failed (err: bad proposal response 500: access denied for [JoinChain][testc]: [Failed verifying that proposal's creator satisfies local MSP principal during channelless check policy with policy [Admins]: [This identity is not an admin]])

（其他拥有MSP的同行成功加入了频道btw）

因此角色系统按预期工作，但是CSCC实际上是如何认识证书角色的？有隐藏的机制吗？

Answer 1

我的答案基于Fabric 1.4.3及更高版本。

您看到的特定错误意味着您没有使用被视为对等方的管理员的身份（密钥/证书对）来调用JoinChannel API。在1.4.3之前的版本中，管理员是通过将证书显式地放入对等方的本地MSP目录中的 admincerts 文件夹中来定义的。在1.4.3及更高版本中，您还可以通过通用名称中的特定 OU 来识别管理员（更多信息，请参见下文）。

因此，您需要使用对等管理员来调用JoinChannel API。使用 cryptogen 时，将在 users 目录中创建一个管理员用户。调用JoinChannel时，应使用此身份。

有关MSP角色及其定义的详细信息：

有5种可能的角色：

管理员
对等
客户
订购者
成员

要使用对等，客户端和订购者角色，您需要启用"identity classification" feature。使用基于文件夹的MSP结构时，可以通过在MSP目录根目录的 config.yaml 文件中设置启用“ NodeOUs”来实现：

NodeOUs:
  Enable: true
  ClientOUIdentifier:
    Certificate: cacerts/ca.sampleorg-cert.pem
    OrganizationalUnitIdentifier: client
  PeerOUIdentifier:
    Certificate: cacerts/ca.sampleorg-cert.pem
    OrganizationalUnitIdentifier: peer
  AdminOUIdentifier:
    Certificate: cacerts/ca.sampleorg-cert.pem
    OrganizationalUnitIdentifier: admin
  OrdererOUIdentifier:
    Certificate: cacerts/ca.sampleorg-cert.pem
    OrganizationalUnitIdentifier: orderer

这定义了如何通过X509证书的CommonName属性中存在的 OU 区分MSP角色。上面的示例表明，由 cacerts / ca.sampleorg-cert.pem 颁发的具有 OU = client 的任何证书都将被标识为客户端， OU = peer < / em>等。从1.4.3版本开始，还为管理员提供了一个OU，因此您不再需要将证书明确放置在MSP目录的 admincerts 文件夹中。

使用 cryptogen 时，可以通过在 crypto-config.yaml 文件中将 EnableNodeOUs 设置为true并运行 cryptogen生成--config crypto-config.yaml 。例如，这将为对等组织启用NodeOU：

PeerOrgs:
  - Name: org1
    Domain: org1.example.com
    EnableNodeOUs: true
    Template:
      Count: 2
      SANS:
         - "localhost"
         - "127.0.0.1"
         - "{{.Hostname}}-{{.Domain}}"
    Users:
      Count: 1

Answer 2

它非常简单，没有任何复杂或隐藏的机制，正如您所知，它是一个PKI。

每个实体对等方，订购者都有其自己的MSP

所以MSP中有什么

.
├── admincerts
├── cacerts
├── keystore
├── signcerts
└── tlscacerts

如您所见，每个对等方都将由于本地MSP而产生信任，在对等方MSP的上述结构中，我们具有 admincerts ，因此我们提及的任何对等方都将假定该身份为管理员，则您需要签名创建频道，加入频道或使用管理员凭据

安装链代码交易

如果您更改凭据，对等方将抱怨。

cacerts 的相同方式：对等方将假定cacerts文件夹中存在的任何rootCA证书链，它将接受来自客户端的任何具有该ca身份的请求

来到您的客户和同行：

嘿，在注册身份时，您会以属性的形式提及角色，该身份用于许多用例，当您使用 fabric-ca < / strong>而不是cryptogenen工具

检查this

Answer 3

管理员的证书存储在admincerts的{{1}}目录中。如果可以验证交易的签名，则可以说交易的发送者是msp。简而言之，Fabric从不是证书本身而是msp来了解证书角色。

Answer 4

这是超级账本结构平台自行处理的事情。我们只需要处理基于客户端证书的Hyperledger Fabric支持属性的证书。因此您可以通过其属性来识别其他证书。

在Fabric网络中，每个组件都有其自己的标识。这意味着每个组件都有其自己的证书，该证书由面料自行处理。

如何区分Hyperledger Fabric中`cryptogen`生成的客户端和对等证书？

4 个答案: