在Hyperledger Fabric中生成加密材料的两种方法：Cryptogen和CA Server

总览 (Overview)

One of the most asked questions on Hyperledger Fabric is about identity. A permissioned blockchain requires that an entity, be it a client, an administrator or a network component, must be first identified and permissioned before accessing a consortium network. Hyperledger Fabric uses several concepts like organization, membership service providers, digital certificate, which makes the understanding of the whole picture a little challenging for new learners. Here in this article again I try to elaborate these concepts through analyzing Test Network, a network example in fabric material, and the two different ways to generate the crypto material for these entities. I hope to give you another perspective on this topic.

Hyperledger Fabric上最常见的问题之一是关于身份。 获得许可的区块链要求在访问联盟网络之前必须首先标识和许可一个实体，无论是客户端，管理员还是网络组件。 Hyperledger Fabric使用了多个概念，例如组织，会员服务提供商，数字证书，这使新学员对整体情况的理解有些挑战。 在本文中，我再次尝试通过分析测试网络(结构材料中的网络示例)以及为这些实体生成加密材料的两种不同方式来详细阐述这些概念。 我希望能给您关于该主题的另一种观点。

组织和会员服务提供商 (Organization and Membership Service Provider)

Hyperledger Fabric is always chosen to build a consortium network to address a business problem. The participants are usually business entities in this case. An example is a trade finance platform, where participants are mainly the banks, plus some governance or regulatory bodies. Hyperledger Fabric uses organizations to represent these participating entities. In the trade finance platform, each bank is an organization. A governance body is also another organization. This is how we understand organization from a business perspective.

始终选择Hyperledger Fabric来建立联盟网络来解决业务问题。 在这种情况下，参与者通常是企业实体。 一个例子是贸易融资平台，其中参与者主要是银行，再加上一些治理或监管机构。 Hyperledger Fabric使用组织来代表这些参与实体。 在贸易融资平台中，每个银行都是一个组织。 治理机构也是另一个组织。 这就是我们从业务角度理解组织的方式。

In Hyperledger Fabric, each organization is characterized by its Membership Service Provider (MSP). On one side, MSP creates credential material to all entities within an organization. On the other side, MSP represents the organization to participate in a consortium network. Technically the consortium network is formed by the MSP of all organizations. They trust one another when the MSPs are functioning well.

在Hyperledger Fabric中，每个组织都有其成员资格服务提供商(MSP)的特征。 一方面，MSP为组织内的所有实体创建凭据材料。 另一方面，MSP代表参与联盟网络的组织。 从技术上讲，联盟网络由所有组织的MSP组成。 当MSP运作良好时，他们彼此信任。

MSP is implemented in Public Key Infrastructure (PKI). In a typical PKI environment each entity is holding a private key and a digital certificate (certificate) containing the public key and relevant information about this entity. This certificate is signed and issued by a Certificate Authority (CA) and becomes the identity of this entity.

MSP在公钥基础结构(PKI)中实现。 在典型的PKI环境中，每个实体都持有一个私钥和一个数字证书(证书)，其中包含该实体的公钥和相关信息。 该证书由证书颁发机构(CA)签名和颁发，并成为该实体的身份。

When an entity signs a message with its private key, it produces a signature on that message. Everyone who obtain this message, signature and the signer’s certificate, can

当实体使用其私钥对消息签名时，它将在该消息上生成签名。 每个获得此消息，签名和签名者证书的人都可以

• tell that only the private key owner can create this signature (through public key from certificate)
  告诉只有私钥所有者才能创建此签名(通过证书中的公钥)
• know the identity of the private key owner (through information recorded in the certificate)
  知道私钥所有者的身份(通过证书中记录的信息)
• trust that the signer is the one claimed in the certificate (through verifying CA’s signature on the certificate, with the assumption that CA’s certificate is trusted).
  相信签名者是证书中要求保护的签名者(通过验证CA在证书上的签名，并假设CA的证书受信任)。

This signing and verification process happens everywhere in a consortium network. Each organization knows the MSP of other organizations in a consortium network, and trust of this consortium network is built up from a “who’s who” perspective. As an example, here is a part of a transaction showing the endorsement, and we can see those information mentioned above.

这个签名和验证过程发生在联盟网络中的任何地方。 每个组织都知道联盟网络中其他组织的MSP，并且从“谁是谁”的角度建立对这个联盟网络的信任。 例如，这是表示认可的交易的一部分，我们可以看到上面提到的那些信息。

In this transaction two endorsements are included. Each endorsement contains

在此交易中包括两个背书。 每个背书都包含

• endorser: the certificate (identity) of endorser in base64

  背书人 ：base64中背书人的证书(身份)

• signature: produced by that endorser against the message in proposal response payload (collapsed).

  签名 ：由该背书者针对提案响应有效负载中的消息生成(已折叠)。

Everyone in the consortium can verify that it is the endorser in the certificate signing this proposal response, and therefore this endorsement is accepted.

联盟中的每个人都可以验证它是否是签署此提议响应的证书中的背书人，因此可以接受该背书。

测试网络 (Test Network)

It is always too abstract if just reading the material without examples. Here we use Test Network from fabric samples as an example. Similar to First Network in previous releases, Test Network comes with a well-designed script in fabric v2.0. It is a three-organization design, with one orderer organization and two peer organizations.

如果只阅读没有示例的材料，那总是太抽象了。 这里我们以来自织物样品的测试网络为例。 与先前版本中的First Network相似，Test Network在Fabric v2.0中带有经过精心设计的脚本。 它是一个具有三个组织的设计，具有一个订购者组织和两个对等组织。

Test Network: Organization and entities inside each organization

测试网络：每个组织内的组织和实体

In general the structure of an organization includes

通常，组织的结构包括

• MSP, or we use the term Identity CA (or simply CA) representing it
  MSP，或者我们用术语“身份CA”(或简称为CA)来表示它
• Network components, either orderers or peers
  网络组件(订购者或对等者)
• Network users, who represent the actual human or client application acting on the network
  网络用户，代表实际在网络上运行的人工或客户端应用程序

We use network components and network users separately if the discussion is specific to each of them. If something applies to both network components and network users, we will use the term entities of an organization.

如果讨论是针对网络组件和网络用户的，则我们将分别使用它们。 如果某些内容同时适用于网络组件和网络用户，我们将使用组织的实体一词。

CA is responsible for handling the identity of all entities within an organization. Each entity obtains a credential (crypto material) from CA. The credential includes a private key and a digital certificate representing this entity. The security is maintained as long as the entity is keeping the private key safe.

CA负责处理组织内所有实体的身份。 每个实体都从CA获得证书(加密材料)。 该凭证包括私钥和代表该实体的数字证书。 只要实体保持私钥的安全就可以维持安全性。

While the main purpose of CA is on identity area (prove an entity is what it claims to be), we will encounter another set of crypto material for another purpose. In Hyperledger Fabric communication between components are also secured by TLS, for example, client application to peers, cluster communication between orderers, etc. Although this article is more focused on identity, we will also take a look on TLS, but you should always see them as two separate systems for different purposes.

虽然CA的主要目的是在身份区域(证明一个实体就是它所声称的身份)，但出于另一目的，我们将遇到另一组加密材料。 在Hyperledger Fabric中，组件之间的通信也受TLS保护，例如，客户端应用程序与对等方之间的通信，订购者之间的集群通信等。尽管本文更加关注身份，但我们还将介绍TLS，但您应该始终看到将它们作为两个用于不同目的的独立系统。

关于加密资料目录结构的注释 (A Note about Directory Structure of Crypto Material)

For those who have gained some experience in First Network in the previous releases or Test Network in v2.0, you may have noticed that the crypto material is always stored in a fixed directory structure.

对于那些在先前版本中的First Network或v2.0中的Test Network中具有一定经验的人，您可能已经注意到，加密资料始终存储在固定的目录结构中。

We will examine the directory in detail, but I wish to point out that there is not a must to follow such a data structure. If we trace back a bit history, at the beginning we are using cryptogen (more detail in next session) to create the crypto material, and docker-compose to bring up network components. Inside the docker-compose configuration files directories are mapped to each network component. For example, crypto material for peer0.org1.example.com is correctly installed in this peer through docker-compose files.

我们将详细检查目录，但我想指出，没有必要遵循这种数据结构。 如果我们追溯一点历史，一开始我们将使用cryptogen (在下一个会话中会更详细)创建加密材料，并使用docker-compose来启动网络组件。 在docker-compose配置文件中，目录映射到每个网络组件。 例如， peer0.org1.example.com加密材料已通过peer0.org1.example.com -compose文件正确安装在此对等设备中。

crypto material of peer0.org1 is correctly mapped to peer0.org1 containers in docker-compose files

peer0.org1的加密材料已正确映射到docker-compose文件中的peer0.org1容器

It is a decent and systematic way as it can be coded into configuration. Nevertheless, you also can mount the crypto material one-by-one and manually, if it is desired.

由于可以将其编码为配置，因此这是一种体面而又系统的方法。 不过，如果需要，您也可以手动并手动安装加密材料。

As we still rely on docker-compose files for bringing up network components, we will follow this directory structure. It is automatically generated with cryptogen, but some more copy-n-paste is needed when we are using CA Server.

由于我们仍然依赖docker-compose文件来启动网络组件，因此我们将遵循此目录结构 。 它是使用cryptogen自动生成的，但是当我们使用CA Server时，还需要复制n粘贴。

With these, we can start looking into the first way to generate crypto material: cryptogen.

有了这些，我们可以开始研究生成加密材料的第一种方法： cryptogen 。

使用加密原生成加密材料 (Generating Crypto Material using Cryptogen)

Hyperledger Fabric provides a tool that crypto material can be generated with minimum configuration. The tool is bin/cryptogen. Working with a configuration file, the crypto material of Test Network is generated and the result is kept as the directory structure shown above. With that, we can bring up the consortium network with docker compose files.

Hyperledger Fabric提供了一种工具，可以用最少的配置生成加密材料。 该工具是bin/cryptogen 。 使用配置文件，将生成测试网络的加密材料，并将结果保留为上面所示的目录结构。 这样，我们就可以使用docker compose文件建立联盟网络。

目录结构 (Directory Structure)

We first use ./network.sh script to bring up Test Network and make some observations on the directory structure.

我们首先使用./network.sh脚本启动测试网络，并对目录结构进行一些观察。

cd test-network
./network.sh up

Per script design the material is kept in organizations/. Here we take Org1 as an example for exploration.

根据脚本设计，材料保存在organizations/ 。 这里我们以Org1为例进行探索。

Here are a quick summary for all these components

这是所有这些组件的快速摘要

• ca/: a directory holding crypto material for CA of Org1

  ca/ ：存放Org1 CA的加密材料的目录

• peers/: a directory holding a list of peers under Org1, and each peer has its own crypto material, of both identity and TLS

  peers/ ：一个目录，其中包含Org1下的对等方列表，每个对等方都有自己的身份和TLS加密材料

• users/: a directory holding a list of network users under Org1, and each peer has its own crypto material, of both identity and TLS

  users/ ：一个目录，用于存放Org1下的网络用户列表，每个对等方都有自己的身份和TLS加密材料

• tlsca/: a directory holding the TLS CA

  tlsca/ ：存放TLS CA的目录

• msp/: it is the material joining a consortium network.

  msp/ ：这是加入联盟网络的材料。

• connection-org1.yaml and connection-org1.json: these are the connection profile files in different formats. They will be used in client applications.

  connection-org1.yaml和connection-org1.json ：这些是不同格式的连接配置文件。 它们将在客户端应用程序中使用。

We break it further down and observe some relevant items.

我们将其进一步细分并观察一些相关项目。

CA Certificate

CA证书

We first take a look at the CA of Org1. It is this CA issuing identity (certificate) to all entities within Org1.

我们首先看一下Org1的CA。 这是该CA向Org1中的所有实体颁发身份(证书)。

From the directory we see a private secret key and a certificate. We will inspect the subject and issuer of the certificate.

从目录中，我们可以看到私钥和证书。 我们将检查证书的主题和颁发者。

It is a self-signed certificate (subject == issuer). It is a typical design for non-production environments, as we allow a new self-signed certificate as the CA to issue identity for the whole organization. This is what cryptogen can provide, and this is also its limitation (see discussion later).

它是一个自签名证书(主题==颁发者)。 这是非生产环境的典型设计，因为我们允许使用新的自签名证书作为CA来为整个组织颁发身份。 这就是cryptogen可以提供的，这也是它的局限性(请参阅后面的讨论)。

Network Components (peer)

网络组件(对等)

As Org1 is a peer organization, the network component is “peer”. In the peers/ we see a list of peers defined per the crypto configuration file (will be examined later). In the Test Network we have only one peer.

由于Org1是对等组织，因此网络组件是“对等”。 在对peers/我们看到了按加密配置文件定义的对等体列表(稍后将进行检查)。 在测试网络中，我们只有一个对等方。

Double click to this directory, there are two directories. msp/ is for identity, and tls/ is for TLS material. This directory structure will be seen in every entity.

双击该目录，有两个目录。 msp/用于标识， tls/用于TLS材料。 在每个实体中都会看到此目录结构。

We focus on the identity part. We will revisit the TLS material when we cover TLS later.

我们专注于身份部分。 稍后我们将讨论TLS时，将重新访问TLS材料。

Inside msp/ the directory structure looks like this. We will be very familiarized with this directory structure later, as it is the structure for all entities, both network components and network users.

在msp/ ，目录结构如下所示。 稍后我们将非常熟悉此目录结构，因为它是所有实体(网络组件和网络用户)的结构。

For identity, the private secret key of this peer is stored in msp/keystore/, while the certificate is kept in msp/signcerts/.

为了标识，此对等方的私钥存储在msp/keystore/ ，而证书保留在msp/signcerts/ 。

We take a look at the certificate of this peer. The issuer is the CA of Org1 mentioned above, and the subject is CN=peer0.org1.example.com and OU=peer.

我们来看一下该对等方的证书。 发行者是上述Org1的CA，主题是CN=peer0.org1.example.com和OU=peer 。

Network Users

网络用户

Network users are kept in users/. From the directory we see a list of users defined in the crypto configuration file (will be examined later). In Test Network we have one Admin, and one user named User1.

网络用户保留在users/ 。 从目录中，我们看到在加密配置文件中定义的用户列表(稍后将进行检查)。 在测试网络中，我们有一个Admin和一个名为User1的用户 。

Let’s take Admin as an example. Again there are two directories. msp/ is for identity, and tls/ is for TLS material.

让我们以Admin为例。 同样，有两个目录。 msp/用于标识， tls/用于TLS材料。

Here is the private key and certificate for Admin.

这是管理员的私钥和证书。

Finally we take a look at the certificate of Admin, both the subject and issuer. We see that the subject contains OU=admin, and the certificate is issued by the CA of Org1.

最后，我们来看一下主题和颁发者的Admin证书。 我们看到该主题包含OU=admin ，并且证书是由Org1的CA颁发的。

Same directory structure for User1. There is a difference in the certificate subject. We see OU=client for User1. Obviously it is the difference of roles in these two network users. Admin is an admin, while User1 is a client user. If some actions only allow admin role to perform, User1 is denied.

User1的目录结构相同。 证书主题有所不同。 我们看到OU=client User1的OU=client 。 显然，这是这两个网络用户中角色的不同。 Admin是管理员，而User1是客户端用户。 如果某些操作仅允许执行管理员角色，则User1被拒绝。

TLS

TLS

Though TLS is not relevant to the identity system, the crypto material for TLS is also generated during the cryptogen process. Here we just make a highlight and locate those materials inside the directory structure.

尽管TLS与身份系统无关，但是在加密过程中也会生成TLS的加密材料。 在这里，我们只是突​​出显示并在目录结构中找到这些资料。

A TLS CA is also created for Org1. The TLS CA Certificate is stored in tlsca/. TLS crypto material for all entities in Org1 is generated from this TLS CA.

还为Org1创建了一个TLSCA。 TLS CA证书存储在tlsca /中 。 从此TLS CA生成Org1中所有实体的TLS加密材料。

We see this is a self-signed certificate. Therefore in cryptogen the Identity CA and TLS CA are different systems, and do not have any relationship to each other.

我们看到这是一个自签名证书。 因此，在cryptogen ，身份CA和TLS CA是不同的系统，并且彼此之间没有任何关系。

In a TLS communication, network components play a TLS server role. Therefore each network component is installed with a TLS server key and server certificate. As in Org1 we only have one peer, we can inspect the material inside peers/peer0.org1.example.com/tls/.

在TLS通信中，网络组件扮演TLS服务器角色。 因此，每个网络组件都安装了TLS服务器密钥和服务器证书。 就像在Org1中我们只有一个同伴一样，我们可以检查peers/peer0.org1.example.com/tls/的材料。

And again we see the TLS server certificate server.crt is issued by TLS CA.

再次，我们看到TLS服务器证书server.crt由TLS CA颁发。

Network user plays a TLS client role. Therefore each network user is installed with a TLS client key and client certificate. We take Admin as an example here.

网络用户扮演TLS客户端角色。 因此，每个网络用户都安装了TLS客户端密钥和客户端证书。 我们以Admin为例。

And the client certificate client.crt is also issued by TLS CA.

客户端证书client.crt也由TLS CA颁发。

This is a diagram showing the relationship of crypto material generated with cryptogen. Note that the Identity CA for each organization is just a CA’s private key and a CA Certificate. There is no software currently running as a CA Server. You will not see a container running in any CA Servers generating this. This certificate issuance process is done by cryptogen software itself. Nevertheless, one can easily bring up a CA Server with CA’s private key and CA Certificate when identity for more entities is needed.

这是显示用cryptogen生成的加密材料之间的关系的图。 请注意，每个组织的身份CA只是CA的私钥和CA证书。 当前没有任何软件作为CA Server运行。 您将不会在生成此消息的任何CA Server中看到正在运行的容器。 该证书颁发过程由cryptogen软件本身完成。 但是，当需要更多实体的身份时，可以轻松地使用CA的私钥和CA证书来启动CA服务器。

cryptogen tool in Test Network cryptogen工具生成的加密货币材料

配置文件 (Configuration File)

We have seen the result of cryptogen. Now we take a look at the configuration files, which tell cryptogen how to generate the crypto material shown above.

我们已经看到了cryptogen的结果。 现在我们来看一下配置文件，这些文件告诉cryptogen如何生成上面显示的加密材料。

The configuration for Test Network is kept inside organizations/cryptogen/. Inside these files we can specify the organization structure of the network (peer organization and orderer organization), and detail of entities within an organization. These configuration files are self-explanatory. For sake of completeness we put them here.

测试网络的配置保存在organizations/cryptogen/ 。 在这些文件中，我们可以指定网络的组织结构(对等组织和订购者组织)，以及组织内实体的详细信息。 这些配置文件是不言自明的。 为了完整起见，我们将其放在此处。

For orderer organization. The result is one orderer with name orderer.example.com. One Admin user is generated by default.

对于订购者组织。 结果是一个名称为orderer.example.com者。 默认情况下，会生成一个管理员用户。

configuration for Orderer Organization in Test Network

测试网络中订购者组织的配置

For peer organization (here we see Org1). The result is one peer (Count 1 in Template) and the name is by default peer0.org1.example.com. One Admin user is generated by default. The Count 1 in Users means one additional user is generated as well, with a name User1 by default.

对于同行组织(在这里我们看到Org1)。 结果是一个对等方(模板中的Count 1 )，默认名称为peer0.org1.example.com 。 默认情况下，会生成一个管理员用户。 “用户中的计数1”意味着还将另外产生一个用户 ，默认情况下名称为User1 。

configuration for Org1, a PeerOrganization in Test Network

测试网络中的PeerOrganization Org1的配置

This matches all the entities we see above in Org1.

这与我们在Org1中上面看到的所有实体匹配。

密码原的使用 (Use of cryptogen)

In the script network.sh, the crypto material is generated in this command.

在脚本network.sh ，此命令生成了加密材料。

cryptogen generate --config=<configuration_file> --output=<output_directory>

This command is executed for all the three organizations: Org1, Org2 and Orderer Organization.

对于所有三个组织(Org1，Org2和订购者组织)执行此命令。

We can see how cryptogen works: with this command and configuration files, we can build the directory structure of crypto material shown above.

我们可以看到cryptogen工作原理：使用此命令和配置文件，我们可以构建上面显示的加密材料的目录结构。

讨论区 (Discussion)

Cryptogen by far is the simplest way for us to generate crypto material for typical network designs. No matter how many orderers we are to deploy (one for Solo, five for Raft, etc) in orderer organization, how many peers needed for each peer organization, or how many client users needed in each organization, we can specify the requirement in the configuration files and generate the material with a simple command.

到目前为止，对于我们来说，对于传统的网络设计而言，加密Cryptogen是最简单的方法。 无论我们在订购者组织中要部署多少订购者(一个用于Solo，五个用于Raft，等等)，每个对等组织需要多少个对等方，或者每个组织中需要多少个客户用户，我们都可以在配置文件并使用简单的命令生成材料。

This is also where the limitation lies. From Hyperledger Fabric documentation, we learn that cryptogen is good for generating crypto material for testing purposes, and would normally not be used in production operation. There are several considerations.

这也是限制所在。 从Hyperledger面料文档，我们了解到cryptogen是用于生成加密材料用于测试目的好的，通常不会在生产经营中使用。 有几个注意事项。

One is that the CA certificates are all generated as self-signed certificates. In real life we may ask for different settings. For example, we cannot use an existing CA as the MSP for our organization, or we cannot chained certificates.

一种是将CA证书全部生成为自签名证书。 在现实生活中，我们可能会要求不同的设置。 例如，我们不能将现有的CA用作组织的MSP，也不能链接证书。

Also it is predefined with organization type: orderer organizations and peer organizations are defined separately. If for example we need orderers owned by peer organizations, we have to use some workaround (refer to this article on this requirement).

它也预定义了组织类型：订购者组织和对等组织分别定义。 例如，如果我们需要对等组织拥有的订购者，则必须使用一些解决方法(有关此要求，请参阅本文 )。

Last but not the least, material is generated once based on configuration file, but in real life we may need more peers or more clients after deployment. Although it is still doable, as we can generate the new entities with CA’s private key, it is not as simple as running cryptogen on a configuration file.

最后但并非最不重要的一点是，材料是根据配置文件生成一次的，但是在现实生活中，部署后我们可能需要更多的同伴或更多的客户端。 尽管它仍然可行，但是我们可以使用CA的私钥生成新实体，但这并不像在配置文件上运行cryptogen那样简单。

If you are just creating for testing, the above should not be your concern, and cryptogen is good enough. Otherwise, you can take another approach: bring up a CA server and generate the crypto material for entities with this CA according to your desired network design. This is the second way to generate crypto material for a consortium network.

如果您只是为了测试而创建，那么上面的内容就不用担心了，并且cryptogen就足够了。 否则，您可以采取另一种方法：启动CA服务器并根据您所需的网络设计为具有此CA的实体生成加密材料。 这是为联盟网络生成加密材料的第二种方法。

使用CA Server生成加密材料 (Generating Crypto Material using CA Server)

We see some limitations in using cryptogen. To gain more flexibility and make it more practical, a better way is to bring up a CA Server, and we can generate crypto material for entities according to our network design. This involves more steps, but provides a standard way to either generate crypto material that cryptogen cannot generate, or for future use if more network components and users are needed.

我们看到使用cryptogen一些限制。 为了获得更大的灵活性并使之更加实用，一种更好的方法是启动一个CA Server，并且我们可以根据我们的网络设计为实体生成加密材料。 这包括更多的步骤，而是提供一种标准方法要么生成加密材料cryptogen不能产生，或以备将来使用，如果需要更多的网络组件和用户。

总览 (Overview)

A CA Server is a software to generate crypto material on request. Inside a CA Server there is a CA, represented by a private secret key and a CA Certificate. Any certificates signed and issued by this CA is verifiable with the CA Certificate (or CA’s public key). CA’s private secret key and CA Certificate is the essence of a CA, while a CA Server is just a software tool to perform this signing.

CA Server是一种根据要求生成加密材料的软件。 在CA Server内有一个CA，以私钥和CA证书表示。 由该CA签名和颁发的任何证书都可以使用CA证书(或CA的公钥)进行验证。 CA的私钥和CA证书是CA的本质，而CA Server只是执行此签名的软件工具。

Technically speaking, once one gets hold the CA’s private secret key and CA Certificate, one can issue certificates. It can be done on a CA Server, or it can be done by common tools such as openssl. Therefore, always make a difference between a CA (representing the ownership of that private key) and a CA Server (where certificate is signed and issued).

从技术上讲，一旦获得了CA的私有密钥和CA证书，就可以颁发证书。 它可以在CA Server上完成，也可以通过通用工具(例如openssl)完成。 因此，请始终在CA(代表该私钥的所有权)和CA Server(签名和颁发证书的地方)之间有所区别。

There are many CA Server products in the market. Hyperledger Fabric comes with one, Fabric-CA Server. This whole process begins with bringing up a Fabric-CA Server, running as a docker container. We either use an existing CA for this CA Server, or generate a self-signed certificate as root CA. In the Test Network example, it is a self-signed certificate, and we then generate all crypto material from it.

市场上有许多CA Server产品。 Hyperledger Fabric随附一个Fabric-CA Server 。 整个过程从启动作为Docker容器运行的Fabric-CA Server开始。 我们要么为此CA服务器使用现有的CA，要么将其作为根CA生成自签名证书。 在测试网络示例中，它是一个自签名证书，然后我们从中生成所有加密材料。

To interact with Fabric-CA Server, we need another tool on our side. It can be either a Fabric-CA Client or Fabric SDKs. Fabric-CA Client is used in Test Network script. Note that Fabric-CA Client is running on our localhost, and it interacts with the Fabric-CA Server which is a running container. You can refer to a comprehensive explanation in fabric documentation (link).

要与Fabric-CA Server交互，我们需要另一边的工具。 它可以是Fabric-CA客户端或Fabric SDK。 Fabric-CA Client用于测试网络脚本。 请注意，Fabric-CA Client在我们的本地主机上运行，​​并且与作为运行容器的Fabric-CA Server进行交互。 您可以在结构文档( 链接 )中参考全面的说明。

目录结构和内容 (Directory Structure and Content)

As mentioned before, we need the same directory structure in order to match the docker-compose configuration. Therefore the result of using CA needs to be the same as the result after using cryptogen. This involves some name changing and file moving. Instead of repeating everything about the directory structure, here we highlight some difference on the content and process.

如前所述，我们需要相同的目录结构以匹配docker-compose配置。 因此，使用CA的结果必须与使用cryptogen后的结果相同。 这涉及一些名称更改和文件移动。 在这里，我们不再强调目录结构的所有内容，而是在内容和过程上强调一些区别。

We first use ./network.sh script to bring up the minimum setup and observe the resulting directory structure and content. Note the option -a is required to bring up crypto material using CA instead of cryptogen.

我们首先使用./network.sh脚本进行最小设置，并观察生成的目录结构和内容。 请注意，需要使用选项-a来使用CA而不是cryptogen来产生加密材料。

cd test-network
./network.sh up -ca

The majority of steps are in fact executed in the script fabric-ca/registerEnroll.sh.

实际上，大多数步骤都在脚本fabric-ca/registerEnroll.sh 。

We see three CAs, one for each organization, up and running. As a comparison, no CA containers are running when we bring up the network using cryptogen.

我们看到三个CA，每个组织一个，并且正在运行。 作为比较，当我们使用cryptogen启动网络时，没有CA容器正在运行。

Only the CA Certificate is here, which is a public information, but there is no private secret key (scroll up to the session on cryptogen and see a comparison). It is because the private secret key is in the CA Server. This is a more realistic way as it is the CA Server holding that secret, and it should not be available and visible outside the CA Server. We will see more detail about this CA Certificate when we dive into the Fabric-CA Server

这里只有CA证书，这是一个公共信息，但没有私钥(向上滚动至有关加密cryptogen的会话，并进行比较)。 这是因为专用密钥在CA Server中。 这是一种更现实的方法，因为它是由CA Server持有的秘密，并且在CA Server之外不应可见。 当我们深入研究Fabric-CA服务器时，我们将看到有关此CA证书的更多详细信息

The structure for entities (peer and users) are similar. Here we just bring out the certificate of the peer and both users. They are all issued by CA of Org1, with proper identifiers in OU.

实体(对等和用户)的结构相似。 在这里，我们只是带出对等方和两个用户的证书。 它们全部由Org1的CA颁发，并在OU中带有适当的标识符。

We now take a look at the TLS. First the TLS CA. Interesting enough, we see the same certificate as CA.

现在我们来看一下TLS。 首先是TLSCA。 有趣的是，我们看到了与CA相同的证书。

In the previous session about cryptogen, we see a separate TLS CA for all TLS material. When using a CA, the script of Test Network generates all crypto material for TLS with the same CA. There is no strict requirement whether using one CA for each purpose or for both purposes.

在上一期有关cryptogen会议中，我们为所有TLS资料看到一个单独的TLSCA。 使用CA时，测试网络的脚本会为具有相同CA的TLS生成所有加密材料。 对于每种用途还是两种用途，都没有严格的要求。

Finally we see that only network component is equipped with TLS server certificates, and network users (e.g. Admin, User1) is not. It works fine as most setup only server authentication (one-way authentication) is required in TLS. To know more about TLS settings in Hyperledger Fabric, refer to the fabric documentation about this (link).

最后，我们看到只有网络组件才配备TLS服务器证书，而网络用户(例如Admin，User1)则没有。 由于大多数设置仅在TLS中需要服务器身份验证(单向身份验证)，因此它可以正常工作。 要了解有关Hyperledger Fabric中TLS设置的更多信息，请参阅有关此Fabric文档( 链接 )。

This is how it looks like in Test Network after launching it using CA Server.

这是使用CA Server启动后在测试网络中的样子。

Fabric CA Server in Test Network Fabric CA Server生成的加密材料

Fabric-CA服务器 (Fabric-CA Server)

We have seen the result. Now we can take a look on the CA Server side, and locate the material inside CA Server.

我们已经看到了结果。 现在，我们可以在CA Server端进行查看，然后在CA Server中找到资料。

Our Fabric-CA Server is being brought up as a docker container. The docker compose file for it is ./docker/docker-compose-ca.yaml. It brings up all the three CA servers. We take a look at the one for Org1.

我们的Fabric-CA服务器将作为docker容器启动。 泊坞窗的撰写文件是./docker/docker-compose-ca.yaml 。 它调出所有三个CA服务器。 我们来看看Org1的那个。

The Org1 portion of docker-compose-ca.yaml configuration file

docker-compose-ca.yaml配置文件的Org1部分

Some observations in this configuration.

在此配置中的一些观察。

There is a predefined configuration file fabric-ca-server-config.yaml for Org1, stored in organizations/fabric-ca/org1. From the volumes (line 23–24) it is mapped to the container. Therefore this file exists in the container when fabric-ca-server is running. This is a practical way for managing configuration, as we can edit in localhost while the edited configuration file is directly in the container.

Org1有一个预定义的配置文件fabric-ca-server-config.yaml ，存储在organizations/fabric-ca/org1 。 从卷(第23-24行)将其映射到容器。 因此，当fabric-ca-server运行时，此文件存在于容器中。 这是一种管理配置的实用方法，因为我们可以在localhost中进行编辑，而编辑后的配置文件直接位于容器中。

Several environment variables are set in the container. What is defined here is to override the configuration file.

在容器中设置了几个环境变量。 此处定义的是覆盖配置文件。

Finally the command to bring up the Fabric CA Server is fabric-ca-server start with a bootstrap identity -b admin:adminpw. It will be used in the next step when we enroll a CA Admin with Fabric-CA Client.

最后，启动Fabric CA Server的命令是fabric-ca-server start ，以引导程序标识-b admin:adminpw 。 当我们通过Fabric-CA Client注册CA Admin时，将在下一步中使用它。

Certain material is kept in /etc/hyperledger/fabric-ca-server when the Fabric-CA Server is running. We can examine the content in localhost, according to the mapping in the container (line 23–24).

当Fabric-CA Server运行时，某些材料会保存在/etc/hyperledger/fabric-ca-server 。 我们可以根据容器中的映射(第23-24行)检查本地主机中的内容。

Material inside Fabric-CA Server, being mapped to localhost for inspection.

Fabric-CA Server内部的材料，被映射到localhost进行检查。

Among them we will see

其中我们将看到

• msp/: where the crypto material for CA of Org1 stored

  msp/ ：存储Org1的CA的加密材料的位置

• ca-cert.pem: the CA Certificate for Org1

  ca-cert.pem ：Org1的CA证书

• tls-cert.pem: the TLS server certificate for CA Server, used when accessing the CA Server with TLS

  tls-cert.pem ：CA Server的TLS服务器证书，在使用TLS访问CA Server时使用

• fabric-ca-server.db: the database of the Fabric CA Server, recording the user registration and certificate issuance

  fabric-ca-server.db ：Fabric CA Server的数据库，记录用户注册和证书颁发

• IssuerPublicKey and IssuerRevocationPublicKey: the names are self-explanatory.

  IssuerPublicKey和IssuerRevocationPublicKey ：名称是不言自明的。

We first take a look at the CA Certificate ca-cert.pem for Org1.

我们首先来看一下Org1的CA证书ca-cert.pem 。

This is a self-signed certificate. Again, this is just one option. With Fabric-CA Server we can incorporate an existing certificate (with its private key).

这是一个自签名证书。 同样，这只是一种选择。 使用Fabric-CA Server，我们可以合并现有证书(及其私钥)。

Fabric-CA Server, as a server, supports TLS. Therefore a TLS server certificate is generated and kept as tls-cert.pem.

Fabric-CA Server作为服务器支持TLS。 因此，将生成TLS服务器证书并将其保存为tls-cert.pem 。

And this is just a TLS server certificate issued by CA of Org1.

这只是由Org1的CA颁发的TLS服务器证书。

The corresponding private keys are kept in msp/keystore/.

相应的私钥保存在msp/keystore/ 。

It does not take too much effort to correlate the two secret keys matching the CA Certificate for Org1 and TLS server certificate for the Fabric-CA Server.

将与Org1的CA证书和Fabric-CA服务器的TLS服务器证书相匹配的两个秘密密钥相关联不需要花费太多的精力。

详细过程 (The Process in Detail)

We follow the process executed in network.sh script. Here is the overall flow of generating crypto material using CA Server. For an organization,

我们遵循在network.sh脚本中执行的过程。 这是使用CA Server生成加密材料的总体流程。 对于一个组织，

1. Bring up the Fabric-CA Server which is used as the CA of that organization.
   启动用作该组织的CA的Fabric-CA服务器。
2. Use Fabric-CA Client to enroll a CA Admin.
   使用Fabric-CA Client注册CA Admin。
3. With the CA Admin, use Fabric-CA Client to register and enroll every entity (peer, orderer, user, etc) one by one to the Fabric-CA Server.
   使用CA Admin，使用Fabric-CA Client将每个实体(对等，订购者，用户等)注册并注册到Fabric-CA Server。
4. Move the result material to the directory structure.
   将结果材料移到目录结构。

Proper configuration is provided whenever needed. And repeat this process for all organizations, as each of them has its own organization CA.

必要时提供正确的配置。 并对所有组织重复此过程，因为每个组织都有自己的组织CA。

We will take Org1 as an example and take a look on the steps. And we will follow the instruction in network.sh and perform this process once. This helps us understand what happens behind.

我们将以Org1为例，并看一下步骤。 然后，我们将按照network.sh中的指令执行一次此过程。 这有助于我们了解背后发生的情况。

Before, clean up what has been deployed with,

之前，请清理已部署的内容，

cd test-network
./network.sh down# if you see permission error in removing some directories, perform the following
sudo rm -r organizations/fabric-ca/org1/msp/
sudo rm -r organizations/fabric-ca/org2/msp/
sudo rm -r organizations/fabric-ca/ordererOrg/msp/

Step 1: Fabric-CA Server

步骤1：Fabric-CA服务器

IMAGE_TAG=latest docker-compose -f docker/docker-compose-ca.yaml up -d

Check if the CAs are up and running.

检查CA是否已启动并正在运行。

Step 2: Enroll CA Admin

步骤2：注册CA Admin

As we are using Fabric-CA Client to interact with the Fabric-CA Server, we first need to specify the Fabric-CA Client home directory.

当我们使用Fabric-CA Client与Fabric-CA Server交互时，我们首先需要指定Fabric-CA Client主目录。

mkdir -p organizations/peerOrganizations/org1.example.com/export PATH=$PATH:/home/ubuntu/fabric-samples/bin
export FABRIC_CA_CLIENT_HOME=${PWD}/organizations/peerOrganizations/org1.example.com/

Now we can enroll a CA Admin.

现在，我们可以注册一个CA Admin。

fabric-ca-client enroll -u https://admin:adminpw@localhost:7054 --caname ca-org1 --tls.certfiles ${PWD}/organizations/fabric-ca/org1/tls-cert.pem

In this enrollment,

在这个招生中，

• bootstrap identity admin:adminpw is specified

  引导程序身份admin:adminpw已指定

• the CA name is ca-org1
  CA名称为ca-org1
• the correct TLS server certificate for CA Server
  CA Server的正确TLS服务器证书

Now our Fabric-CA Client has the credential of a CA Admin, and ready to perform the enrollment for each entity. For information this credential is kept in the home directory (msp/keystore and msp/signcerts).

现在，我们的Fabric-CA客户端具有CA Admin的凭据，并准备对每个实体执行注册。 有关信息，该凭据保存在主目录( msp/keystore和msp/signcerts )中。

And the certificate is issued by the CA of Org1.

证书由Org1的CA颁发。

Step 3: Register and Enroll Each Entity

步骤3：注册并注册每个实体

For each entity (peer0, Admin and User), we will first register in the CA Server, and then enroll the entity to obtain the credential.

对于每个实体(peer0，Admin和User)，我们将首先在CA Server中注册，然后注册该实体以获得证书。

We need a config.yaml file to enable the OU identifiers, and keep the OU identifiers for each type of entity. They are peer, orderer, client and admin.

我们需要一个config.yaml文件来启用OU标识符，并保留每种类型的实体的OU标识符。 他们是同行 ， 订购者 ， 客户和管理员 。

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

Store this file under client home directory: organizations/peerOrganizations/org1.example.com/msp/

将此文件存储在客户端主目录下： organizations/peerOrganizations/org1.example.com/msp/

Here we just take peer0.org1.example.com as an example.

这里我们仅以peer0.org1.example.com为例。

We first register this entity.

我们首先注册该实体。

fabric-ca-client register --caname ca-org1 --id.name peer0 --id.secret peer0pw --id.type peer --id.attrs '"hf.Registrar.Roles=peer"' --tls.certfiles ${PWD}/organizations/fabric-ca/org1/tls-cert.pem

In this registration, besides the CA Name and TLS certificate of the CA Server, there are several items relevant to the identity of peer0.org1.example.com,

在此注册中，除了CA Server的CA名称和TLS证书之外，还有一些与peer0.org1.example.com的身份有关的peer0.org1.example.com ，

• id.name: peer0, this is the name of entity

  id.name ，这是实体的名称

• id.secret: peer0pw, this is the secret to be used when enrol this entity

  id.secret ：peer0pw，这是注册此实体时要使用的秘密

• id.type: peer, here is where we specify the type of this entity. The correct OU identifier will be set according to the config.yaml above.

  id.type ：对等体，在这里我们指定此实体的类型。 正确的OU标识符将根据上面的config.yaml进行设置。

• id.attrs: “hf.Registrar.Roles=peer”

  id.attrs ：“ hf.Registrar.Roles = peer”

This effectively puts the information into the Fabric-CA Server database for later enrollment. Nothing is received after registration.

这样可以有效地将信息放入Fabric-CA Server数据库中，以便以后注册。 注册后什么也收不到。

Then we can use the name (id.name) and secret (id.secret) to enrol the peer0.org1.example.com, with this command.

然后，我们可以使用名称( id.name )和密钥( id.secret )通过此命令注册peer0.org1.example.com 。

fabric-ca-client enroll -u https://peer0:peer0pw@localhost:7054 --caname ca-org1 -M ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp --csr.hosts peer0.org1.example.com --tls.certfiles ${PWD}/organizations/fabric-ca/org1/tls-cert.pem

Besides the CA Name and TLS certificate of the CA Server, we need to specify

除了CA Server的CA名称和TLS证书，我们还需要指定

• CA’s URL with entity’s name and secret, in the format as https://<name>:<secret>@<CA’s URL>

  具有实体名称和机密的CA的URL，格式为https://<name>:<secret>@<CA's URL>

• the MSP location (local directory) to store the crypto material received
  MSP位置(本地目录)以存储接收到的加密材料

• the host in the default CSR (in fabric-ca-client.yaml) is changed to peer0.org1.example.com. This is to override the default setting.

  默认CSR中的主机(位于fabric-ca-client.yaml )更改为peer0.org1.example.com 。 这将覆盖默认设置。

Now the crypto material for peer0.org1.example.com is stored in organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp/, as specified in the enroll command.

现在，如enroll命令中所指定的，peer0.org1.example.com的加密材料存储在organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp/中。

The directory is familiar, as it is the same directory structure we observe before. Here we just show the certificate (inside signcerts/).

该目录很熟悉，因为它与我们之前观察到的目录结构相同。 在这里，我们仅显示证书(在signcerts/内部)。

Besides the subject and issuer, we also see some more information about the certificate of peer0.org1.example.com. Take a note on the X509v3 Subject Alternative Name with peer0.org1.example.com, and also the attributes specified in registration and enrollment.

除了主题和颁发者之外，我们还看到有关peer0.org1.example.com证书的更多信息。 记下带有peer0.org1.example.com的X509v3使用者备用名称 ，以及在注册和注册中指定的属性。

We also need to enrol a TLS server cert.

我们还需要注册TLS服务器证书。

fabric-ca-client enroll -u https://peer0:peer0pw@localhost:7054 --caname ca-org1 -M ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls --enrollment.profile tls --csr.hosts peer0.org1.example.com --csr.hosts localhost --tls.certfiles ${PWD}/organizations/fabric-ca/org1/tls-cert.pem

The command is similar to enrol the credential for identity. The only difference is that the enrollment.profile is tls, and CSR hosts.

该命令类似于注册身份凭证。 唯一的区别是enrollment.profile是tls和CSR主机。

The result is stored in organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/, as specified in the enroll command.

结果存储在enroll命令中指定的organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/中。

Again we just see the TLS server certificate (in signcerts/).

同样，我们只看到TLS服务器证书(在signcerts/ )。

Note the X509v3 Extended Key Usage. As we specify enrollment profile as TLS, we see TLS Web Server Authentication and TLS Web Client Authentication here.

请注意X509v3扩展密钥用法。 当我们将注册配置文件指定为TLS时，我们在此处看到TLS Web服务器身份验证和TLS Web客户端身份验证 。

This is for peer0.org1.example.com. The process is repeated for Admin and User1. Note that the network.sh script does not enrol the TLS client certificate for them.

这是针对peer0.org1.example.com 。 对Admin和User1重复该过程。 请注意， network.sh脚本不会为其注册TLS客户端证书。

Step 4: Move material to the right directory

步骤4：将资料移至正确的目录

The directory of identity is kept inside <entity>/msp/, and the structure is good for use in docker-compose files. However the directory of <entity>/tls/ is not the format. Therefore we need to move TLS CA (inside tlscacerts/), server cert (inside signcerts/) and server key (inside keystore/) out and fit them into the <entity>/tls/ with proper names.

身份目录保留在<entity>/msp/ ，并且该结构非常适合在docker-compose文件中使用。 但是， <entity>/tls/的目录不是格式。 因此，我们需要将TLS CA(在tlscacerts/ )，服务器证书(在signcerts/ )和服务器密钥(在keystore/ )移出，并以适当的名称放入<entity>/tls/ 。

Also copy the CA certificates, we can reconstruct the desired directory structure. This is good enough for bringing up containers with docker-compose.

同样复制CA证书，我们可以重建所需的目录结构。 这足以用docker-compose调出容器。

You can read the remaining steps in network.sh and registerEnroll.sh script to complete the whole process.

您可以阅读network.sh和registerEnroll.sh脚本中的其余步骤以完成整个过程。

摘要 (Summary)

In this article, we use Test Network to show the two different ways of generation crypto material for a consortium network. While cryptogen is a fast and easy way with minimum configuration to bring up a workable network, it has certain limitations and therefore is always considered for testing purposes. A more practical way for production is to bring up a CA server and generate the material according to one’s need in a consortium network. In the Test Network, we see how Fabric-CA Server is used as the CA Server, and how to use Fabric-CA Client to perform the whole process.

在本文中，我们使用测试网络来演示为联盟网络生成加密材料的两种不同方式。 虽然cryptogen是一种快速简便的方法，只需最少的配置即可建立一个可行的网络，但它具有一定的局限性，因此始终被考虑用于测试目的。 一种更实际的生产方式是在联盟网络中启动CA服务器并根据需要生成材料。 在测试网络中，我们将了解如何将Fabric-CA Server用作CA Server，以及如何使用Fabric-CA Client执行整个过程。

翻译自: https://medium.com/@kctheservant/two-ways-to-generate-crypto-materials-in-hyperledger-fabric-cryptogen-and-ca-server-36d3c3e2daad