Fabric CA官方文档翻译——Registering and enrolling identities with a CA

翻译：https://hyperledger-fabric-ca.readthedocs.io/en/latest/deployguide/use_CA.html

读者：组织管理员，节点管理员

如果你也已经阅读过我们关于标识和MSP的文档，你就会知道在Hyperledger Fabric中，证书颁发机构用于生成分配给管理员，节点和用户（客户端应用程序）的标识。虽然可以生成x.509证书的任何颁发机构都可以用于创建构成标识的公钥、私钥对，但是Fabric CA可以生成Hyperledger Fabric所需的本地和组织MSP文件夹结构。

本文章，我们展示“happy path”来使用Fabric CA来生成身份标识和MSP。请注意，你不必使用Fabric CA来注册和注册标识。但是，如果使用不同的CA，则需要创建Fabric用于创建组织，客户端标识和节点的相关标识和MSP。我们将下面展示这些msp的例子。

注册登记概况

而CA的管理员可以创建标识并将公钥、私钥对授予带外用户，但此过程将授予CA管理员对每个用户的私钥的访问权限。这种安排违反了关于私钥安全的基本安全程序，不应以任何理由暴漏私钥。

因此，CA管理员注册用户，在这个过程中，CA管理员向身份提供注册ID和密码（类似于用户名和密码），并为其分配角色和任何必须的属性。然后，CA管理员将这个注册ID和密码提供给身份的最终用户。然后，用户可以使用此注册ID和密码执行Fabric CA client enroll命令，返回包含CA管理员分配的角色和属性的公钥、私钥对。

这个过程既保留了CA的完整性（因为只有CA管理员才能注册用户并分配角色和属性关系）和私钥（因为只有身份的用户才能访问它们）。

虽然管理员身份只需要注册和注册到“组织CA”中，该“组织CA”为管理员和节点生成身份证书，但节点也必须注册和注册到TLS CA。这也会创建公钥私钥对这样节点用于签名和加密通信。如果TLS CA仅适用TLS配置文件创建，则向组织CA注册和注册标识的命令与向TLS CA注册和注册的命令相同。如果你使用的CA包含两个配置文件，则在于CA通信时必须制定TLS配置文件。有关创建只能用作TLS CA的CA的更多信息，请参阅 CA deployment guide。

开始之前

在本教程中，我们假设已经使用CA设置说明配置和设置了CA服务器。我们还将显示在注册标识（由CA管理员处理的任务或具有CA注册器权限的标识）和注册标识（由标识的用户处理的任务）时使用的命令和变量。

无论哪种情况，fabric-ca-client必须被设置，因为它用于调用注册和登录身份CA的服务器。如果在生产环境，需要启用TLS，这会需要TLS证书来加密CA间的通信。TLS证书会需要来自TLS CA，你可以使用TLS CA生成节点，管理员和客户端的标识，该TLS CA与你将用于生成证书的CA相同（因为节点使用TLS彼此通信）。

决定文件夹和证书的结构

无论运行环境是测试还是生产，对于管理文件夹和证书，保持一致且一致的结构来管理文件夹和证书是至关重要的。尽管在任何地方都使用相同的模式并并不是Fabric必须的（只要你在引用路径时是正确的，例如在引导节点时，Fabric可以使用它们），但是证书路径错误是Fabric用户面临的最常见错误之一。 有远见的保持一致可以减少事件。

请注意，生产部署可能包括我们在这里不展示的结构。例如，它可能包含一个网关文件夹，允许管理员轻松查看哪些组织、节点和客户端与每个网络相关联。类似地，你可能会看到一个包含于网络关联的智能合约的文件夹。

我们在这里描述的组织文件夹和证书的方法不是强制性的，但是你会发现它很有用，因为它与本主题的其余部分以及CA部署指南一致。最重要的是，它围绕着拥有和管理它们的组织来组织结构。虽然很自然地认为你的部署是围绕物理结构（如对等点和排序节点）组织的，但实际上组织才是集中化的对象。尤其是因为并非所有的网络参与者都必须拥有一个节点。

这里介绍的结构和方法也代表了最佳实践，例如，Fabric希望MSP文件夹名为MSP，如果使用其他名称，则必须在相关YAML文件夹中更改文件夹的名称。

操作Fabric CA client的文件夹结构

虽然一致的结构对于你将从CA（创建节点并充当管理员时使用）取回的证书很重要，但对于那些将使用单个Fabric CA client作为管理员链接到多个CA的用户来说，这也很重要。这是因为与组织管理员不同，在组织管理员中，可以使用单个身份作为所需多个节点的管理员，每个CA都必须有一个单独的管理员，该管理员在引导和稍后注册时注册。

这就是为什么如果你以管理员身份从同一个CA客户端连接到不同的CA服务器，那么在使用--mspdir标志时，还必须包含-u标志以针对正确的CA服务器。这将允许你为连接到的CA指定正确的CA管理员凭据。这将允许你为连接到的CA指定正确的CA管理员凭据。

如果你将只使用一个CA client来针对一个CA server（对于将成为组织或者节点管理员的用户来说，这情况更常见），你可以选择在CA client的YAML文件中指定CA服务器。

如果你遵循了CA部署指南中描述的过程，则应该有一组与Fabric cA client关联的文件夹，这些文件夹类似于：

上图显示了与使用单个Fabric CA client连接到多个CA server相关联的文件夹的结构。

如你所见，每个CA服务器在Fabric CA client文件夹下都有一个单独的文件夹。在每个CA文件夹中都有一个msp文件夹，其中包含该CA管理员身份的公钥、私钥对。这是管理CA时（例如，注册标识时）必须指定的--mspdir。

如果你不是CA管理员，而是拥有一个Fabric CA client，仅用于向组织CA和TLS CA注册，那么使用单个Fabric CA client仍然是一个最佳实践。此CA client仍将需要TLS证书（可以使用《CA部署指南》中描述的过程获得），但你不需要指向CA管理员证书，因为你不是CA管理员。相反，注册身份的CA 管理员给你的注册ID和机密允许你与特定的CA服务器交互并接收必要的证书。

组织和节点管理员标识的文件夹结构

虽然使用Fabric CA client操作的CA文件夹的组织方式在很大程度上取决于典型CA管理员将与之交互的多个CA，但用于组织MSP的组织方法部分取决于你预期创建和管理的组织数量。

例如，在Fabric  test network，所有peer组织和orderer组织创建。结果，与网络相关联的脚本创建一个名为organizations的文件夹，包含了ordererOrganization 和peerOrganization 文件夹。这些文件夹中的每个文件夹都包含每个组织的文件夹，其中既包含该组织的MSP，也包含这些组织拥有的每个节点的文件夹。

上图显示了由管理员管理的组织结构。

即使你不打算创建orderer组织，这种结构为你的部署提供了高级别的长期灵活性。例如，如果你创建了一个新的对等方，你将知道在organizations/<name of org>/<name of new peer>中创建一个文件夹。此<name of new peer>文件夹将是peer本地msp（在注册peer身份时生成）和通过TLS CA注册生成的证书和位置。同样，peer所属组织的msp位置可以引用组织的msp以及组织管理员的公共证书（许多情况下，该证书将是对等方的管理员）。

上图显示了组织拥有的peer内部的子文件夹。请注意“peer”文件夹下的msp文件夹。这是peer的本地msp，不是org1.example.com的msp的副本。

最佳做法是在注册标识之前创建这些文件夹，然后在通过--mspdir 标志发出enroll命令时引用它们。请注意，虽然--mspdir 标志用于指定CA管理员的MSP在注册期间的位置，但在注册期间它用于指定文件系统上存储CA返回的文件夹和证书的位置。

NodeOUs

在以前的Fabric版本中，身份只有两种类型：client和peer。peer类型用于peer节点和orderer节点，而client类型用于client和admin，将client类型放置在特殊的admincerts文件夹中，使标识成为特定上下文中的管理员。

现在，我们可以（并且建议）不仅将peer或client，还可以将orderer或者admin角色编码到证书中（使用NodeOUs），这将在证书中嵌入身份所具有的角色。

注意一个身份只可以有一个角色，要启用这些角色，必须将相关的部分复制到config.yaml中。config.yaml文件在Fabric中不同的方式使用。在通道msp，用来验证组织的admin是否有admin的角色（这将替代旧版本的Fabric中使用的admincerts文件夹）。在节点的本地MSP中，它用于验证节点admin的admin角色和节点本身的peer或orderer角色。

注意你可以将此msp文件夹命名为任何你想要的名称-msp是Fabric CA client使用的默认文件夹名称。如果选择另一个名称，例如org1msp，则在注册标识时必须使用--mspdir标志引用此文件夹。已编程方式，你可以使用此与此类似的命令进行复制config.yaml 到正确的msp文件夹，以获取注册的标识。

echo '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' > path to msp>/msp/config.yaml

也可以手动将Node OU材料复制到config.yaml或msp文件夹中：

NodeOUs:
  Enable: true
  ClientOUIdentifier:
    Certificate: cacerts/<root CA cert for this org>.pem
    OrganizationalUnitIdentifier: client
  PeerOUIdentifier:
    Certificate: cacerts/<root CA cert for this org>.pem
    OrganizationalUnitIdentifier: peer
  AdminOUIdentifier:
    Certificate: cacerts/<root CA cert for this org>.pem
    OrganizationalUnitIdentifier: admin
  OrdererOUIdentifier:
    Certificate: cacerts/<root CA cert for this org>.pem
    OrganizationalUnitIdentifier: orderer

在生产场景中，假设用户将只创建一个组织。但是，最好为这个组织建立一个单独的文件夹结构，然后在这个组织下为你的msp（定义组织）和你的节点（将有一个本地msp和TLS部分）创建一个结构。

如果你创建一个orderer，你显然不需要复制PeerOUIdentifier 到config.yaml文件（反之亦然），但是为了简单起见，你可能需要使用整个节，而且它们允许使用相同的config.yaml用于与组织关联的多种类型的节点和标识。

注册身份

虽然管理员（或其他用户）使用的标识和节点使用的标识有不同的用途，但它们基本上都只是标识：公钥、私钥对，其中公钥为他人所知，私钥用于签名，生成一个可以被验证为来自私钥的输出，即使私钥本身从未公开过。