部署一个生产网络
本部署指南是对设置生产 Fabric 网络组件的适当的顺序的整体概述，此外还有最佳做法和部署时要记住的一些注意事项。
部署 Fabric 网络的过程很复杂，需要了解公钥基础设施和管理分布式系统。如果你是智能合约或应用开发者，在部署生产级别 Fabric 网络时，你不应该需要这种级别的专业技能。然而，你可能需要了解网络是如何部署的，以便开发有效的智能合约和应用程序。
如果你只需要一个开发环境来测试链码、智能合约和应用程序，请查看 使用Fabric的测试网络。它包括两个组织，每个组织拥有一个 peer 节点，以及一个拥有单个排序节点的排序服务组织。该测试网络并不打算为部署生产组件提供蓝图，也不应该这样使用，因为它会做出生产部署不会做出的假设和决策。
本指南会向你概述设置生产组件和生产网络的步骤：
步骤一:选定你的网络配置
区块链网络结构必须按照用例来决定。这些基本的业务决策将根据你的用例的改变而改变，但是让我们考虑一些场景。
- 与开发环境或概念证明相反，在生产环境中操作时，安全性、资源管理和高可用性成为优先考虑的事项。
- 你需要多少个节点来满足高可用性，以及你希望在哪些数据中心部署它们来确保灾难恢复和数据驻留的需求得到满足？
- 你将如何确保你的私钥和信任根保持安全状态？
除了以上提到的，这有一个在部署组件之前你需要做出决定的案例：
- 证书颁发机构配置。 作为整体决策的一部分，你必须决定你的 peer 节点（有多少，每个通道有多少等等）和你的排序服务（有多少节点，谁将拥有它们），你还必须决定你的组织的 CA（译者注：证书颁发机构，下同）节点如何被部署。生产网络应该使用传输层安全性（TLS），这将需要设置一个 TLS CA，并使用它来生成 TLS 证书。此 TLS CA 需要在你登录 CA 之前部署。我们将更多在 步骤三：设置你的 CA（译注：证书颁发机构，下同）节点 讨论这点。
- 使用或者不使用组织的单位？ 一些组织可能会发现有必要建立组织单位，以便在特定身份和由单一认证机构创建的 MSP（成员服务提供商）之间建立分离。
- 数据库类型。 网络中的一些通道可能需要所有数据以某种 使用 CouchDB 作为状态数据库 能理解的方式进行建模，然而其他优先考虑速度的网络可能会决定所有 peer 节点将使用 LevelDB。注意通道中不应该有同时使用 CouchDB 和 LevelDB 的 peer 节点，因为两个数据库类型模型数据稍有不同。
- 通道和私有数据。 一些网络可能认为 通道 是确保某些特定交易的隐私性和隔离性的最佳方式。其他网络可能会认为一个单一通道连同 私有数据 能更好地服务于他们的隐私需求。
- 容器编排。 不同用户也可能做出针对他们的容器编排的不同决定，为他们的 peer 进程创建单独的容器，为 peer 进程、CouchDB、gRPC 通信以及链码记录日志；而其他用户可能会决定组合这些进程中的一些。
- 链码部署方式。 用户现在可以选择使用内置构建结合运行支持（自定义构建和使用 外部构建器和启动器 来运行），或者使用 将链码作为外部服务。
- 使用防火墙。 在产品部署中，属于某个组织的组件可能需要访问其他组织的组件，使用防火墙和高级网络配置成为必须。例如，使用 Fabric SDK 的应用程序需要访问所有组织的所有背书 peer 节点以及所有通道的排序服务。类似地，peer 节点需要在他们接收区块的通道上访问排序服务。
无论你的组件何时以何种方式部署的，为了有效地运行你的网络，你将需要在你选择的管理系统（如 Kubernetes）中拥有高度的专业知识。类似地，网络结构必须被设计成适用于业务用例以及网络所运行行业的任何相关法律法规。
本部署指南不会覆盖每一次迭代和潜在的网络配置，但给出了需要考虑的通用指南和规则。
步骤二:为你的资源设置一个集群
一般来说，Fabric 与部署和管理它的方法无关。例如，可能在一台笔记本电脑上部署和管理一个 peer 节点。因为种种原因，这可能不是可取的，但 Fabric 中没有任何东西可以禁止它。
只要你有能力部署容器，无论是在本地（或防火墙后），还是在云端，都应该有可能建立组件并将它们相互连接。然而，Kubernetes 具有许多有用的工具，使其成为部署和管理 Fabric 网络的普及容器管理平台。需了解更多关于 Kubernetes 的信息，请查看 the Kubernetes documentation。本主题将主要将其范围限制在二进制文件中，并提供在使用 Docker 部署或 Kubernetes 时可以应用的说明。
无论你选择以什么方式，在什么地方部署你的组件，你都需要确保有足够的资源让组件有效运行。你需要的大小很大程度上取决于你的用例。如果你计划将单个 peer 节点加入几个高容量通道，它将比一个用户计划加入单个通道的 peer 节点需要更多的 CPU 和内存。粗略计算，计划分配给 peer 节点的资源大约是你计划分配给单个排序节点资源（如下所述，推荐部署至少三个，最好是五个节点到排序服务）的三倍。类似地，对于一个 CA，你应该需要相当于 peer 节点十分之一的资源。你也需要添加存储到你的集群（一些云提供商可能会提供存储），因为如果没有先与云提供商一起设置存储，你就无法配置持久卷和持久卷声明。
通过部署概念证明网络并在负载下测试它，你将更好地了解你需要的资源。
管理你的基础设施
你用来管理你的后端的确切方法和工具将取决于你选择的后端。然而，这里有一些值得注意的事项。
- 使用机密对象在集群中安全地存储重要的配置文件。有关 Kubernetes 机密的信息，请查看 Kubernetes secrets。你也可以选择使用强化安全模块加密持久卷 （PVs）。类似的路线，在部署完 Fabric 组件后，你可能想在你自己的后端链接一个容器，例如在 Docker Hub 这样的服务中使用私有仓库。你需要以 Kubernetes 密码的形式对登录信息进行编码，并在部署组件时将其包含在 YAML 文件中。
- 集群注意事项和节点大小。在上面的第2步中，我们讨论了如何考虑节点大小的一般概要。你的用例，以及一个健壮的开发阶段，是你真正了解你的 peer 节点、排序节点和 CA 节点需要多大的唯一方法。
- 你选择如何挂载你的卷。最佳做法是将与节点相关的卷挂载在部署节点的外部。这将允许你稍后引用这些卷（例如，重新启动已崩溃的节点或容器），而不必重新部署或重新生成你的密码材料。
- 你如何监控你的资源。通常关键是要建立一个策略和方法来监视我们个人节点使用的资源和部署到集群的资源。随着你加入你的 peer 节点到更多的通道，你可能需要增加它的 CPU 和内存分配。同样，你需要确保你的状态数据库和区块链有足够的存储空间。
步骤三:设置你的CA(证书颁发机构)节点
Fabric 网络中必须部署的第一个组件是 CA。这是因为在节点本身能被部署之前，节点相关证书（不仅是节点本身的证书，还有识别谁可以管理节点的证书）必须被创建。虽然不是必需使用 Fabric CA 来创建这些证书，但 Fabric CA 还创建了组件和组织要正确定义所需的 MSP 结构。如果用户选择使用 Fabric CA 以外的 CA，则必须自己创建 MSP 文件夹。
- 一个 CA（或者更多，如果你正在使用中间 CA — 以下有关于中间 CA 的更多信息）用于生成（通过一个称为“登录”的过程）组织管理员的证书、该组织的 MSP 以及该组织拥有的任何节点。此 CA 还将为任何其他用户生成证书。由于它在“登录”身份中的作用，这个 CA 有时被称为“登录 CA”或“ecert CA”。
- 其他 CA 生成保护传输层安全（TLS）通信的证书。因此，这个 CA 通常被称为“TLS CA”。这些 TLS 证书被附加到防止“中间人”攻击的活动中。请注意，TLS CA 仅用于为节点颁发证书，当该活动完成时可以关闭。用户可以选择使用单向（仅客户端）TLS 以及双向（服务器和客户端）TLS，后者也称为“相互（mutual）TLS”。因为指定你的网络使用 TLS（推荐使用） 应该在部署“登录” CA（指定此 CA 配置的 YAML 文件有一个启用 TLS 的字段）之前，所以你应该先部署 TLS CA，并在引导登录 CA 时使用其根证书。当链接到登录 CA 为用户和节点登录身份时候，这份 TLS 证书也会被
fabric-ca client使用。
虽然与组织相关的所有非 TLS 证书都可以由单个“根”CA（即其自身信任根的 CA）创建，但对于添加的安全组织来说，可以决定使用证书由根 CA（或最终导向根 CA 的另一个中间 CA）创建的“中间”CA。由于根 CA 的泄露导致其整个信任域（管理员、节点和它为其生成的任何证书的 CA）崩溃，中间 CA 是一种限制根 CA 暴露的有用方法。你是否选择使用中间 CA 将取决于用例的需要。并非强制使用。请注意，对于那些已经采取此实现方式，并且不想在现有基础设施中添加身份管理层的企业，还可以配置轻量级目录访问协议（LDAP）来管理 Fabric 网络上的身份。
在生产网络中，建议每个组织至少部署一个用于注册目的 CA，另一个用于 TLS 的 CA。 例如，如果你部署了三个与某个组织相关联的 peer 节点和一个与排序组织相关联的排序节点，则至少需要四个 CA。两个 CA 是用于 peer 组织（为 peer 节点、管理员、通信以及代表组织的 MSP 目录结构生成登录和 TLS 证书），其他两个 CA 将用于排序组织注意，用户通常只用登录 CA 来注册和登录，然而节点需要用登录 CA（在登录 CA 中，当节点尝试对其操作进行签名时，它将获得标识它的签名证书）和 TLS CA（在那里它将获得用于验证其通信的 TLS 证书）来注册和登录。
对于如何设置组织 CA 和 TLS CA 并登录其管理员身份的示例，请查看 Fabric CA 部署指南。本部署指南使用 Fabric CA 客户端来注册和登录需要设置 CA 的身份。
步骤四:用CA来创建身份和MSP
创建CA后，可以使用它们为与组织相关的身份和组件（由 MSP 表示）创建证书。对于每个组织，你至少需要：
- 注册和登录管理员身份并创建 MSP。在创建了与组织关联的 CA 之后，可以使用它先注册一个身份，然后登录它。在第一步中，身份的用户名和密码由 CA 的管理员分配。属性和从属关系也可以被赋予身份（例如，
admin的role，这是组织管理员所必需的）。身份注册后，可以使用用户名和密码来登录。该CA将为该身份生成两个证书-网络其他成员已知的公共证书（也称为签名证书）和用于身份签名操作的私钥（存储在keystore文件夹中）。该 CA 也会生成一个包含 CA 颁发证书的公有证书的 MSP 文件以及 CA 的信任根（这可能是也可能不是同一个 CA）。此 MSP 可以被认为是定义与管理员身份相关的组织。对于这个过程细节的例子，请查看 管理员如何登录的例子。如果组织的管理员也是节点的管理员（这将是典型的），你必须在创建本地节点的 MSP 之前，创建组织管理员身份，因为当创建本地 MSP 时，节点管理员证书必须被使用。 - 注册和登录节点身份。就像一个组织管理员身份被注册和登录一样，节点的身份必须用登录的 CA 和 TLS CA 执行注册和登录操作。因此，登录 CA 和 TLS 共享数据库（允许节点身份仅注册一次并由每个 CA 服务器单独登录)可能是有用的，尽管这是一个可选的配置选项。当用登录 CA 注册节点身份时，不给节点
admin或user的角色，而是给它一个peer或orderer的角色。与管理员一样，此身份的属性和从属关系也可以分配。节点的 MSP 结构称为 “本地 MSP”，因为分配给身份的权限仅与本地（节点）级别相关。此 MSP 是在创建节点身份时创建的，并在引导节点时使用。在你用 TLS CA 登录后并将组织加入到通道（当登录管理员身份时，此证书必须添加到创建的 orgMSP 中）时，以及使用 peer 二进制作为 CLI 客户端向其他 peer 节点（如peer chaincode invoke）或排序节点（如peer channel fetch）进行调用时（因为没有orderer的 CLI），你将使用生成的TLS 根证书。没有必要将TLS根证书添加到节点的本地MSP中，因为这些证书包含在通道配置中。
有关基于Fabric的区块链网络中的身份和权限的更多概念信息，请查看 身份 and 成员服务提供者 (MSP).
要了解如何使用 CA 来生成一个管理员身份和 MSP，查看 Enroll Org1’s Admin.
要了解如何用登录 CA 和 TLS CA 来为节点生成证书，查看 Setup Org1’s Peers.
步骤五:部署节点
一旦你收集完你需要的所有证书和 MSP，你几乎准备好创建一个节点了。如上所述，有很多合法的方式来部署节点。
创建一个peer节点
在创建 peer 节点之前，你需要为 peer 节点定制配置文件。在 Fabric 中，这个文件叫做 core.yaml。你可以找到一个示例 core.yaml 配置文件 在 Hyperledger Fabric sampleconfig 目录.
正如你在文件中看到的，有相当多的参数，你可以选择设置，或者需要设置节点才能正常工作。一般情况下，如果你不需要更改变化值，就不要管它。但是，你可能需要调整各种地址、指定要使用的数据库类型以及指定节点的 MSP 所在位置。
你主要有三个选择更改配置。
1、编辑和二进制文件绑定的 YAML 文件。
2、在部署时，使用环境变量来重写。
3、在 CLI 命令中指定标识。
选项1的优点是，每当你将节点关闭并又恢复启动时，会持久化你的更改。缺点是，升级到新的二进制版本时，必须将你定制的选项移植到新的 YAML 文件（升级到新版本时，应该使用最新的 YAML）。
无论哪种方式，这有一些在 core.yaml 中你必须检查的值。
peer.localMspID：这是你的 peer 组织的本地 MSP 的名称。在此MSP中，将列出你的 peer 组织管理员以及 peer 组织的根 CA 和TLS CA 证书。peer.mspConfigPath：peer 节点的本地 MSP 的所在地。注意，将此卷挂载到容器外部是最佳做法。这确保即使容器被停止（例如，在维护周期中），MSP也不会丢失，并且必须重新创建。peer.address：代表同一组织中的其他 peer 节点的终端，这是在组织内建立 gossip 通信的一个重要注意事项。peer.tls：当你将enabled值设置为true（应该在生产网络中完成）时，你将必须指定相关 TLS 证书的位置。请注意，网络中的所有节点（peer 节点和排序节点）都必须启用或不启用 TLS。对于生产网络，强烈建议启用TLS。与你的MSP一样，将此卷挂载到容器外部是最佳做法。ledger：用户可以做许多关于其账本的决定，包括状态数据库类型（例如，LevelDB 或 CouchDB）以及其位置（通过fileSystemPath指定）。请注意，对于 CouchDB 来说，在 peer 节点外部（例如，在一个单独的容器中）操作你的状态数据库是一种最佳实践，因为你将能够以这种方式更好地将特定资源分配给数据库。出于延迟和安全原因，将 Couch DB 容器放在与 peer 节点服务器相同的服务器上是最佳做法。对 CouchDB 容器的访问应该仅限于 peer 节点容器。gossip：在设置 Gossip 数据传播协议 时，有许多配置选项要考虑，包括externalEndpoint（它使 peer 节点可被其他组织的 peer 节点发现）以及bootstrap地址（通过它在 peer 自己的组织中识别一个 peer）。chaincode.externalBuilders：当使用 将链码作为外部服务 时，设置这个字段很重要。
当你对如何配置 peer 节点、如何挂载卷以及后端配置感到得心应手时，可以运行命令启动 peer 节点（此命令将取决于后端配置）。
创建一个排序节点
与创建 peer 节点不同，你将需要创建一个创世纪块（或者引用已经创建的块，如果将排序节点添加到现有的排序服务中），并在启动排序节点之前指定其路径。
在Fabric中，这个用于排序节点的配置文件称为 orderer.yaml。你可以在 Hyperledger Fabric 的 sampleconfig 目录中 找到一个示例配置文件 orderer.yaml。请注意，orderer.yaml 与排序服务的“genesis block”不同。该区块包括排序系统通道的初始配置，必须在创建排序节点之前创建，因为它用于引导节点。
与 peer 节点一样，你将看到有相当多的参数，你要么可以选择设置，要么需要设置节点才能正常工作。一般情况下，如果您不需要更改变化值，就不要管它。
你有三个主要选项来更改你的配置。
1、编辑和二进制文件绑定的 YAML 文件。
2、在部署时，使用环境变量重写。
3、在 CLI 命令中指明标签。
选项1的优点是，每当你将节点关闭并又恢复启动时，会持久化你的更改。缺点是，升级到新的二进制版本时，必须将你定制的选项移植到新的 YAML 文件（升级到新版本时，应该使用最新的 YAML）。
无论如何，在 orderer.yaml 中有一些值你必须检查。你将发现这些字段中的一些是和 core.yaml 中的一样的，只是名称不同。
General.LocalMSPID：通过排序组织的 CA 生成的本地 MSP 的名称。General.LocalMSPDir：排序节点所在地的本地 MSP。注意，把此卷挂载在容器外面是一种最佳做法。General.ListenAddress和General.ListenPort：代表相同组织中的其他排序节点的终端。FileLedger：虽然排序节点没有状态数据库，但它们仍然都携带区块链的副本，因为这允许它们使用最新的配置块来验证权限。因此，应该用正确的文件路径定制账本字段。Cluster：这些值对于与其他排序节点通信的排序服务节点非常重要，例如在基于 Raft 的排序服务中。General.BootstrapFile：这是用于引导排序节点的配置块的名称。如果此节点是在排序服务中生成的第一个节点，则必须生成此文件，并将其称为“创始块”。General.BootstrapMethod：给出引导块的方法。目前，这只能是文件，其中指明了BootstrapFile中的文件。从2.0开始，你可以通过指定none来简单地在不引导的情况下启动排序节点。Consensus：确定共识插件（支持并推荐 Raft 排序服务）允许的键值对，用于写头日志（WALDir）和快照（SnapDir）。
当你对如何配置排序节点、如何挂载卷以及后端配置感到得心应手时，可以运行命令启动排序节点（此命令将取决于后端配置）。
下一步
区块链网络都是关于连接的，所以一旦你部署了节点，你显然会想把它们连接到其他节点！如果你有一个 peer 组织和一个 peer 节点，你需要加入你的组织到一个联盟，并加入 通道。如果你有一个排序节点，你需要添加 peer 组织到你的联盟。你还将需要学习如何开发链码，你可以在以下主题中了解到 场景 and 链码开发者教程。
连接节点和创建通道的部分过程将涉及修改策略以适应业务网络的用例。有关策略的更多信息，请查看 策略。
Fabric 中的一个常见任务是编辑现有的通道。有关该过程的教程，请查看 更新通道配置。一个常见的的通道更新操作是向现有通道添加一个组织。有关该特定过程的教程，请查看 向通道添加组织。有关部署后升级节点的信息，请查看 Upgrading your components。
Deploying a Production CA
Fabric CA 用户指南
Hyperledger Fabric CA 是Hyperledger Fabric的证书颁发机构（CA）
它提供以下功能：
- 身份注册，或作为用户注册表连接到 LDAP
- 颁发注册证书 (ECerts)
- 证书更新和撤销
注：LDAP（Light Directory Access Portocol），它是基于X.500标准的轻量级目录访问协议。
Hyperledger Fabric CA 由服务器和客户端组件组成，如本文档后面所述。
概述
下图说明了 Hyperledger Fabric CA 服务器如何融入整个 Hyperledger Fabric 架构。
与 Hyperledger Fabric CA 服务器交互的方式有两种：通过 Hyperledger Fabric CA 客户端或通过其中一种 Fabric SDK。与 Hyperledger Fabric CA 服务器的所有通信都是通过 REST API 进行的。有关这些 REST API 的 swagger 文档，请参阅fabric-ca/swagger/swagger-fabric-ca.json 。您可以通过Swagger 在线编辑器查看此文档。
Hyperledger Fabric CA 客户端或 SDK 可以连接到 Hyperledger Fabric CA 服务器集群中的服务器。这在图表的右上部分进行了说明。客户端路由到 HA 代理端点，该端点将流量负载平衡到 fabric-ca-server 集群成员之一。
集群中的所有 Hyperledger Fabric CA 服务器共享同一个数据库，用于跟踪身份和证书。如果配置了 LDAP，身份信息将保存在 LDAP 而不是数据库中。
一台服务器可能包含多个 CA。每个 CA 要么是根 CA，要么是中间 CA。每个中间 CA 都有一个父 CA，它可以是根 CA 也可以是另一个中间 CA。
入门
先决条件
- Go 1.10+安装
GOPATH环境变量设置正确- 已安装
libtool和libtdhl-dev软件包
下面在 Ubuntu 上安装libtool依赖项：
|
|
有关libtool的更多信息，请参阅
有关libltdl-dev的更多信息，请参阅
安装
以下命令将fabric-ca-server和fabric-ca-client二进制文件安装在 $GOPATH/bin 中
|
|
注意：如果您已经克隆了 fabric-ca 存储库，请确保在运行上面的“go get”命令之前位于主分支上。否则，您可能会看到以下错误：
|
|
本机启动服务器
以下使用默认设置启动fabric-ca-server
|
|
-b选项为引导程序的管理员提供注册 ID 和密码；如果未使用ldap.enabled设置启用 LDAP，则这是必需的。
在本地目录中创建一个名为fabric-ca-server-config.yaml的默认配置文件，可以自定义。
通过Docker启动服务器
Docker Hub
前往: https://hub.docker.com/r/hyperledger/fabric-ca/tags/
找到与您的 fabric-ca 的架构和版本相匹配的标签。
创建一个如下所示的docker-compose.yml文件。更改image行为您之前找到的标签。
|
|
在与docker-compose.yml文件相同的目录中打开终端并执行以下命令：
|
|
如果 Compose 文件中指定的 fabric-ca 镜像不存在，将从GitHub拉下它，并启动 fabric-ca 服务器的一个实例。
构建自己的Docker镜像
您可以通过 Docker Compose 构建和启动服务器，如下所示。
|
|
hyperledger/fabric-ca Docker 镜像包含 fabric-ca-server 和 fabric-ca-client。
|
|
探索Fabric CA CLI
为方便起见，本节仅提供 Fabric CA 服务器和客户端的使用消息。以下部分提供了其他使用信息。
配置设置
- CLI 标志
- 环境变量
- 配置文件
在本文档的其余部分，我们指的是对配置文件进行更改。但是，可以通过环境变量或 CLI 标志覆盖配置文件更改。
例如，如果我们在客户端配置文件中有以下内容：
|
|
以下环境变量可用于覆盖cert.pem配置文件中的设置：
|
|
如果我们想覆盖环境变量和配置文件，我们可以使用命令行标志。
|
|
相同的方法适用于 fabric-ca-server
文件路径
Fabric CA 服务器和客户端配置文件中指定文件名的所有属性都支持相对路径和绝对路径。相对路径是相对于配置文件所在的配置目录。比如config目录是~/config，tls部分如下所示，Fabric CA服务器或客户端会在目录~/config中查找文件root.pem，在~/config/certs目录中查找文件cert.pem，在目录/abs/path中查找文件key.pem
|
|
Fabric CA服务器
本节介绍 Fabric CA 服务器。
您可以在启动之前初始化 Fabric CA 服务器。这为您提供了一个生成默认配置文件的机会，可以在启动服务器之前查看和自定义该文件。
Fabric CA 服务器的主目录确定如下：
- 如果设置了 –home 命令行选项，则使用它的值
- 否则，如果
FABRIC_CA_SERVER_HOME设置了环境变量，则使用它的值 - 否则，如果
FABRIC_CA_HOME设置了环境变量，则使用它的值 - 否则，如果
CA_CFG_PATH设置了环境变量，则使用它的值 - 否则，使用当前工作目录
对于本服务器的其余部分，我们假设您已将FABRIC_CA_HOME环境变量设置为$HOME/fabric-ca/server.
下面的说明假定服务器配置文件存在于服务器的主目录中。
初始化服务器
初始化 Fabric CA 服务器如下：
|
|
当 LDAP 被禁用时，-b（bootstrap identity)选项用来初始化。至少需要一个引导标识来启动 Fabric CA 服务器；这个身份是服务器管理员。
服务器配置文件包含可以配置的证书签名请求 (CSR) 部分。以下是示例 CSR。
|
|
以上所有字段都属于X.509签名密钥和证书，由fabric-ca-server init生成。这对应服务器配置文件中的ca.certfile and ca.keyfile文件。字段如下：
- cn是通用名称
- O是组织名称
- OU是组织单位
- L是位置或城市
- ST是状态
- C是国家
如果需要自定义CSR的值，可以自定义配置文件，删除和配置 ca.certfile and ca.keyfile 文件中指定的具体项，然后重新运行命令fabric-ca-server init -b admin:adminpw
除非指定 -u <parent-fabric-ca-server-URL> 选项，否则 fabric-ca-server init 命令会生成自签名 CA 证书。如果指定了-u，则服务器的 CA 证书由父 Fabric CA 服务器签名。为了向父 Fabric CA 服务器进行身份验证，URL 必须采用以下形式 <scheme>://<enrollmentID>:<secret>@<host>:<port>，其中 <enrollmentID> 和 <secret> 对应于具有值为“true”的“hf.IntermediateCA”属性的身份。该命令还在服务器的主目录中生成一个名为fabric-ca-server-config.yaml的默认配置文件
如果您希望 Fabric CA 服务器使用您提供的 CA 签名证书和密钥文件，您必须将您的文件分别放在 ca.certfile 和ca.keyfile的位置。这两个文件都必须是 PEM 编码的，并且不得加密。更具体地说，CA 证书文件的内容必须以 -----BEGIN CERTIFICATE----- 开头，密钥文件的内容必须以 -----BEGIN PRIVATE KEY----- 开头，而不是 -----BEGIN ENCRYPTED PRIVATE KEY-----。
算法和密钥大小
可以自定义 CSR 以生成支持椭圆曲线 (ECDSA) 的 X.509 证书和密钥。以下设置是使用prime256v1曲线和签名算法ecdsa-with-SHA256实现椭圆曲线数字签名算法 (ECDSA) 的示例：
|
|
算法和密钥大小的选择基于安全需要。
椭圆曲线 (ECDSA) 提供以下密钥大小选项：
| 尺寸 | ASN1 OID | 签名算法 |
|---|---|---|
| 256 | prime256v1 | ecdsa-with-SHA256 |
| 384 | secp384r1 | ecdsa-with-SHA384 |
启动服务器
按如下方式启动 Fabric CA 服务器：
|
|
如果服务器之前没有被初始化，它将在第一次启动时自行初始化。在此初始化期间，服务器将生成ca-cert.pem和ca-key.pem文件（如果它们尚不存在），如果它们不存在，还将创建一个默认配置文件。请参阅初始化 Fabric CA 服务器部分。
除非 Fabric CA 服务器被配置为使用 LDAP，否则它必须配置至少一个预注册的引导身份，以便您能够注册和注册其他身份。该-b选项指定引导身份的名称和密码。
要使 Fabric CA 服务器侦听https而不是http，请设置tls.enabled为true。
安全警告：Fabric CA 服务器应始终在启用 TLS 的情况下启动（tls.enabled设置为 true）。不这样做会使服务器容易受到攻击者访问网络流量的攻击。
要限制同一口令（或密码）可用于注册的次数，请将配置文件中的 registry.maxenrollments 设置为适当的值。如果将该值设置为 1，则 Fabric CA 服务器只允许对特定注册 ID 使用一次密码。如果您将该值设置为 -1，则 Fabric CA 服务器对密钥可重复用于注册的次数没有限制。默认值为 -1。将该值设置为 0，Fabric CA 服务器将禁用所有身份的注册，并且不允许身份注册。
Fabric CA 服务器现在应该在端口 7054 上侦听。
如果您不想配置 Fabric CA 服务器在集群中运行或使用 LDAP，您可以跳到Fabric CA 客户端部分。
配置数据库
本节介绍如何配置 Fabric CA 服务器以连接到 PostgreSQL 或 MySQL 数据库。默认数据库是 SQLite，默认数据库文件fabric-ca-server.db位于 Fabric CA 服务器的主目录中。
如果您不关心在集群中运行 Fabric CA 服务器，您可以跳过本节；否则，您必须按如下所述配置 PostgreSQL 或 MySQL。Fabric CA 在集群设置中支持以下数据库版本：
- PostgreSQL：9.5.5 或更高版本
- MySQL：5.7 或更高版本
PostgreSQL
为了连接到 PostgreSQL 数据库，可以将以下示例添加到服务器的配置文件中。请务必适当地自定义各种值。数据库名称中允许使用哪些字符是有限制的。有关详细信息，请参阅 Postgres 文档
|
|
指定sslmode配置为SSL身份验证的类型。sslmode 的有效值下面列出：
| 模式 | 描述 |
|---|---|
| 禁用 | 没有SSL |
| 要求 | 始终使用 SSL（跳过验证） |
| 验证ca | 始终使用 SSL（验证服务器提供的证书是否由受信任的 CA 签名） |
| 验证完整 | 与 verify-ca 相同并验证服务器提供的证书是否由受信任的 CA 签名并且服务器主机名与证书中的主机名匹配 |
如果您想使用 TLS，则必须指定 Fabric CA 服务器配置文件中的db.tls部分。如果在 PostgreSQL 服务器上启用了 SSL 客户端身份验证，则还必须在db.tls.client部分中指定客户端证书和密钥文件。以下是该db.tls部分的示例：
|
|
-
certfiles - PEM 编码的可信根证书文件列表。
-
certfile和keyfile - Fabric CA 服务器用于与 PostgreSQL 服务器安全通信的 PEM 编码证书和密钥文件
PostgreSQL SSL 配置
在 PostgreSQL 服务器上配置 SSL 的基本说明：
- 在 postgresql.conf 中，取消注释 SSL 并设置为“on”（SSL=on）
- 将证书和密钥文件放在 PostgreSQL 数据目录中。
生成自签名证书的说明
注意：自签名证书用于测试目的，不应在生产环境中使用
PostgreSQL 服务器 - 需要客户端证书
- 将您信任的证书颁发机构 (CA) 的证书放在 PostgreSQL 数据目录中的文件 root.crt 中
- 在 postgresql.conf 中，将“ssl_ca_file”设置为指向客户端的根证书（CA 证书）
- 在 pg_hba.conf 中适当的 hostssl 行将 clientcert 参数设置为 1。
有关在 PostgreSQL 服务器上配置 SSL 的更多详细信息，请参阅 PostgreSQL 文档
MySOL
为了连接到 MySQL 数据库，可以将以下示例添加到 Fabric CA 服务器配置文件中。请务必适当地自定义各种值。数据库名称中允许使用哪些字符是有限制的。请参阅以下 MySQL 文档以获取更多信息
在 MySQL 5.7.X 上，某些模式会影响服务器是否允许“0000-00-00”作为有效日期。可能有必要放宽 MySQL 服务器使用的模式。我们希望服务器能够接受零日期值。
在 my.cnf 中，找到配置选项sql_mode并删除NO_ZERO_DATE（如果存在）。进行此更改后重新启动 MySQL 服务器。
请参阅以下有关可用不同模式的 MySQL 文档，并为正在使用的特定 MySQL 版本选择适当的设置。
|
|
如果通过 TLS 连接到 MySQL 服务器，则还需要db.tls.client部分，如上面PostgreSQL部分所述。
MySQL SSL 配置
-
为服务器打开或创建 my.cnf 文件。在 [mysqld] 部分中添加或取消注释以下行。这些应该指向服务器的密钥和证书，以及根 CA 证书。
创建服务器和客户端证书的说明：http://dev.mysql.com/doc/refman/5.7/en/creating-ssl-files-using-openssl.html
|
|
可以运行以下查询以确认 SSL 已启用：
|
|
应该看到：
| 变量名 | 值 |
|---|---|
| have_openssl | Yes |
| have_ssl | Yes |
- 服务器端SSL配置完成后，下一步是创建一个用户，该用户有权通过SSL访问MySQL服务器。为此，登录到 MySQL 服务器，然后键入：
|
|
如果您想提供一个特定的 IP 地址，用户将从该地址访问服务器，请将%更改为特定的 IP 地址。
MySQL 服务器 - 需要客户端证书
安全连接选项与服务器端使用的选项类似。
- ssl-ca 标识证书颁发机构 (CA) 证书。如果使用此选项，则必须指定服务器使用的相同证书。
- ssl-cert 标识 MySQL 服务器的证书。
- ssl-key 标识 MySQL 服务器的私钥。
假设您要使用没有特殊加密要求的帐户或使用包含 REQUIRE SSL 选项的 GRANT 语句创建的帐户进行连接。作为一组推荐的安全连接选项，启动 MySQL 服务器时至少要使用 –ssl-cert 和 –ssl-key 选项。然后在服务器配置文件中设置db.tls.certfiles属性并启动 Fabric CA 服务器。
要要求同时指定客户端证书，请使用 REQUIRE X509 选项创建帐户。然后客户端还必须指定适当的客户端密钥和证书文件；否则，MySQL 服务器将拒绝连接。要为 Fabric CA 服务器指定客户端密钥和证书文件，请设置db.tls.client.certfile和db.tls.client.keyfile配置属性。
配置LDAP
Fabric CA 服务器可以配置为从 LDAP 服务器读取。
特别是，Fabric CA 服务器可能会连接到 LDAP 服务器以执行以下操作：
- 注册前验证身份
- 检索用于授权的身份属性值。
修改 Fabric CA 服务器配置文件的 LDAP 部分，将服务器配置为连接到 LDAP 服务器。
|
|
scheme是ldap或ldaps之一；adminDN是管理员用户的专有名称；pass是管理员用户的密码；host是 LDAP 服务器的主机名或 IP 地址；port是可选端口号，其中ldap的默认值为 389 ，ldaps的默认值为 636 ；base是用于搜索的 LDAP 树的可选根；filter是搜索时使用的过滤器，用于将登录用户名转换为专有名称。例如，搜索具有值为(uid=%s)登录用户名的uid属性值的 LDAP 条目。同样，(email=%s)可用于使用电子邮件地址登录。LDAPAttrs是代表用户从 LDAP 服务器请求的 LDAP 属性名称数组；attribute.converters部分用于将 LDAP 属性转换为结构 CA 属性，其中fcaAttrName是结构 CA 属性的名称；fcaExpr是一个表达式，其评估值分配给结构 CA 属性。例如，假设<LDAPAttrs>是 [“uid”]，<fcaAttrName>是 ‘hf.Revoker’，而<fcaExpr>是 ‘attr(“uid”) =~ “revoker*”'。这意味着代表用户从 LDAP 服务器请求名为“uid”的属性。如果用户的“uid”LDAP 属性的值以“revoker”开头，则用户将获得“hf.Revoker”属性的“true”值；否则，将为用户提供“hf.Revoker”属性的“false”值。attribute.maps部分用于映射 LDAP 响应值。典型的用例是将与 LDAP 组关联的专有名称映射到身份类型。
LDAP 表达式语言使用 govaluate 包，如https://github.com/Knetic/govaluate/blob/master/MANUAL.md所述。这定义了诸如“=~”之类的运算符和诸如“revoker*”之类的文字，这是一个正则表达式。扩展基本 govaluate 语言的特定于 LDAP 的变量和函数如下：
DN是一个等于用户专有名称的变量。affiliation是等于用户的从属关系的变量。attr是一个接受 1 或 2 个参数的函数。第一个参数是 LDAP 属性名称。第二个参数是一个分隔符字符串，用于将多个值连接成一个字符串；默认的分隔符字符串是“,”。该attr函数始终返回“字符串”类型的值。map是一个接受 2 个参数的函数。第一个参数是任何字符串。第二个参数是映射的名称，用于对来自第一个参数的字符串执行字符串替换。if是一个带有 3 个参数的函数，其中第一个参数必须解析为布尔值。如果它的计算结果为真，则返回第二个参数；否则，返回第三个参数。
例如，如果用户具有以“O=org1,C=US”结尾的可分辨名称，或者如果用户具有以“org1.dept2”开头的从属关系，则以下表达式的计算结果为 true。并且还具有“true”的“admin”属性。
|
|
注意：由于该attr函数始终返回“字符串”类型的值，因此不能使用数字运算符来构造表达式。例如，以下不是有效的表达式：
|
|
或者，如下所示用引号括起来的正则表达式可用于返回等效结果：
|
|
以下是 Docker 映像位于 的 OpenLDAP 服务器的默认设置的示例配置部分https://github.com/osixia/docker-openldap。
|
|
请参见FABRIC_CA/scripts/run-ldap-tests，它是有关启动 OpenLDAP Docker 映像、配置它、在FABRIC_CA/cli/server/ldap/ldap_test.go中运行 LDAP 测试并停止 OpenLDAP 服务器的脚本。
配置 LDAP 后，注册工作如下：
- Fabric CA 客户端或客户端 SDK 发送带有基本授权标头的注册请求。
- Fabric CA 服务器接收注册请求，解码授权标头中的身份名称和密码，使用配置文件中的“userfilter”查找与身份名称相关联的 DN（专有名称），然后尝试与 LDAP 绑定身份的密码。如果 LDAP 绑定成功，则注册处理获得授权并可以继续。
设置集群
您可以使用任何 IP sprayer 对 Fabric CA 服务器集群进行负载平衡。本节提供了一个示例，说明如何设置 Haproxy 以路由到 Fabric CA 服务器集群。请务必更改主机名和端口以反映 Fabric CA 服务器的设置。
haproxy.conf
|
|
注意：如果使用 TLS，需要使用.mode tcp
设置多个CA
默认情况下，fabric-ca 服务器由一个默认 CA 组成。但是，可以使用cafiles或cacount配置选项将其他 CA 添加到单个服务器。每个额外的 CA 都有自己的主目录。
cacount
cacount提供了一种快速启动 X 数量的默认附加 CA 的方法。主目录将相对于服务器目录。使用此选项，目录结构将如下所示：
|
|
每个额外的 CA 都会在其主目录中生成一个默认配置文件，在配置文件中它将包含一个唯一的 CA 名称。
例如，以下命令将启动 2 个默认 CA 实例：
|
|
cafiles
如果在使用 cafiles 配置选项时未提供绝对路径，则 CA 主目录将相对于服务器目录。
要使用此选项，必须已经为要启动的每个 CA 生成并配置了 CA 配置文件。每个配置文件必须具有唯一的 CA 名称和通用名称 (CN)，否则服务器将无法启动，因为这些名称必须是唯一的。CA 配置文件将覆盖任何默认 CA 配置，并且 CA 配置文件中任何缺少的选项将被默认 CA 中的值替换。
优先顺序如下：
- CA 配置文件
- 默认 CA CLI 标志
- 默认 CA 环境变量
- 默认 CA 配置文件
CA 配置文件必须至少包含以下内容：
|
|
您可以按如下方式配置您的目录结构：
|
|
例如，以下命令将启动两个自定义 CA 实例：
|
|
注册中间CA
为了为中间 CA 创建 CA 签名证书，中间 CA 必须以与 fabric-ca-client 向 CA 注册相同的方式向父 CA 注册。这是通过使用 -u 选项指定父 CA 的 URL 以及注册 ID 和密码来完成的，如下所示。与此注册 ID 关联的身份必须具有名称为“hf.IntermediateCA”且值为“true”的属性。已颁发证书的 CN（或通用名称）将设置为注册 ID。如果中间 CA 尝试显式指定 CN 值，则会发生错误。
|
|
对于其他中间 CA 标志，请参阅Fabric CA 服务器的配置文件格式部分。
升级服务器
在升级 Fabric CA 客户端之前，必须先升级 Fabric CA 服务器。升级前，建议备份当前数据库：
- 如果使用 sqlite3，请备份当前数据库文件（默认名为 fabric-ca-server.db）。
- 对于其他数据库类型，使用适当的备份/复制机制。
要升级 Fabric CA 服务器的单个实例：
- 停止 fabric-ca-server 进程。
- 确保备份当前数据库。
- 用升级版本替换以前的 fabric-ca-server 二进制文件。
- 启动 fabric-ca-server 进程。
- 使用以下命令验证 fabric-ca-server 进程是否可用，其中
<host>是启动服务器的主机名：
|
|
升级集群
要使用 MySQL 或 Postgres 数据库升级 fabric-ca-server 实例集群，请执行以下过程。我们假设您正在使用 haproxy 分别对 host1 和 host2 上的两个 fabric-ca-server 集群成员进行负载均衡，这两个成员都监听端口 7054。在此过程之后，您将对升级后的 fabric-ca-server 集群成员进行负载均衡分别在 host3 和 host4 上，都监听端口 7054。
为了使用 haproxy stats 监视更改，启用统计信息收集。将以下行添加到 haproxy 配置文件的全局部分：
|
|
重新启动 haproxy 以获取更改：
|
|
要显示来自 haproxy“show stat”命令的摘要信息，以下函数可能对解析返回的大量 CSV 数据很有用：
|
|
- 最初，您的 haproxy 配置文件类似于以下内容：
|
|
将此配置更改为以下内容：
|
|
- 使用新配置重新启动 HA 代理，如下所示：
|
|
"haProxyShowStats"现在将反映修改后的配置，具有两个活动的旧版本备份服务器和两个（尚未启动）升级服务器：
|
|
- 在 host3 和 host4 上安装 fabric-ca-server 的升级二进制文件。host3 和 host4 上新升级的服务器应该配置为使用与 host1 和 host2 上的旧服务器相同的数据库。启动升级后的服务器后，数据库会自动迁移。haproxy 会将所有新流量转发到升级后的服务器，因为它们未配置为备份服务器。在继续之前使用
"fabric-ca-client getcainfo"命令验证您的集群是否仍在正常运行。此外，"haProxyShowStats"现在应该反映所有服务器都处于活动状态，类似于以下内容：
|
|
- 停止 host1 和 host2 上的旧服务器。在继续之前使用
"fabric-ca-client getcainfo"命令验证您的新集群是否仍在正常运行。然后从 haproxy 配置文件中删除旧的服务器备份配置，使其看起来类似于以下内容：
|
|
- 使用新配置重新启动 HA 代理，如下所示：
|
|
"haProxyShowStats"现在将反映修改后的配置，其中两个活动服务器已升级到新版本：
|
|
运营服务
CA 服务器托管一个提供 RESTful“运营”API 的 HTTP 服务器。此 API 旨在供运营商使用，而非管理员或网络“用户”。
该 API 公开了以下功能：
- Prometheus target for operational metrics (when configured)
- 翻译：运营指标的普罗米修斯目标（配置时）
配置运营服务
运营服务需要两个基本配置：
- 要侦听的地址和端口。
- 用于身份验证和加密的TLS 证书和密钥。
请注意，这些证书应由单独的专用 CA 生成。请勿使用已为任何渠道的任何组织生成证书的 CA。
可以在服务器配置文件的operations部分配置 CA 服务器：
|
|
该listenAddress密钥定义了运营服务器将侦听的主机和端口。如果服务器要监听所有地址，主机部分可以省略。
该tls部分用于指示是否为运营服务启用了 TLS，服务证书和私钥的位置，以及客户端身份验证应信任的证书颁发机构根证书的位置。当clientAuthRequired是true时，客户端将需要提供证书进行身份验证。
运营安全
由于运营服务专注于运营并且有意与 Fabric 网络无关，因此它不使用成员服务提供者进行访问控制。相反，运营服务完全依赖于带有客户端证书身份验证的双向 TLS。
强烈建议通过在生产环境中设置clientAuthRequired的值为true来启用双向 TLS 。使用此配置，客户端需要提供有效证书以进行身份验证。如果客户端不提供证书或服务无法验证客户端的证书，请求将被拒绝。注意，如果clientAuthRequired设置为false，客户端不需要提供证书；但是，如果他们这样做，并且服务无法验证证书，则请求将被拒绝。
当禁用 TLS 时，授权将被绕过，任何可以连接到运营端点的客户端都将能够使用 API。
指标
Fabric CA 公开了可以深入了解系统行为的指标。运营员和管理员可以使用此信息更好地了解系统在一段时间内的运行情况。
配置指标
Fabric CA 提供了两种公开指标的方式：基于 Prometheus 的pull(拉式)模型和基于 StatsD 的push(推式)模型。
Prometheus
典型的 Prometheus 部署通过从检测目标公开的 HTTP 端点请求指标来抓取指标。由于 Prometheus 负责请求指标，因此它被认为是pull(拉式)系统。
配置后，Fabric CA 服务器将在运营服务上提供/metrics资源。要启用 Prometheus，请将服务器配置文件中的提供程序值设置为prometheus.
|
|
StatsD
StatsD 是一个简单的统计聚合守护进程。指标被发送到statsd守护进程，在那里它们被收集、聚合并推送到后端以进行可视化和警报。由于此模型需要检测流程将指标数据发送到 StatsD，因此这被视为推送系统。
可以将 CA 服务器配置为通过在服务器配置文件的metrics部分中将metrics提供程序设置为statsd向 StatsD 发送metrics。该statsd子部分还必须配置 StatsD 守护程序的地址、要使用的网络类型（tcp或udp）以及发送指标的频率。可以指定一个可选项prefix来帮助区分指标的来源——例如，区分来自不同服务器的指标——这将被添加到所有生成的指标之前。
|
|
要查看生成的不同指标，请查看指标参考。
Fabric客户端
本节介绍如何使用 fabric-ca-client 命令。
Fabric CA 客户端的主目录确定如下：
- 如果设置了
–home命令行选项，则使用它的值 - 否则，如果
FABRIC_CA_CLIENT_HOME设置了环境变量，则使用它的值 - 否则，如果
FABRIC_CA_HOME设置了环境变量，则使用它的值 - 否则，如果
CA_CFG_PATH设置了环境变量，则使用它的值 - 否则，使用
$HOME/.fabric-ca-client
下面的说明假定客户端配置文件存在于客户端的主目录中。
注册引导身份
首先，如果需要，自定义客户端配置文件中的 CSR（证书签名请求）部分。请注意，该csr.cn字段必须设置为引导身份的 ID。默认 CSR 值如下所示：
|
|
有关字段的说明，请参阅CSR 字段
然后运行命令 fabric-ca-client enroll 注册身份。例如，以下命令通过调用本地运行在 7054 端口的 Fabric CA 服务器注册 ID 为admin密码为adminpw的身份。
|
|
enroll命令将注册证书 (ECert)、相应的私钥和 CA 证书链 PEM 文件存储在 Fabric CA 客户端目录的msp子目录中。您将看到指示 PEM 文件存储位置的消息。
注册新身份
执行注册请求的身份必须当前已注册，并且还必须具有注册正在注册的身份类型的适当权限。
具体而言，Fabric CA 服务器在注册期间会进行以下三项授权检查：
- 注册商（即调用者）必须具有“hf.Registrar.Roles”属性和以逗号分隔的值列表，其中一个值等于正在注册的身份类型；例如，如果注册商具有值为“peer”的“hf.Registrar.Roles”属性，则注册商可以注册 peer 类型的身份，但不能注册 client、admin 或 orderer。
- 注册商的从属关系必须等于或作为被注册身份从属关系的前缀。例如，具有“ab”从属关系的注册商可以注册具有“abc”从属关系的身份，但不能注册具有“ac”从属关系的身份。如果身份需要根从属关系，则从属关系请求应为点 (.)，并且注册商也必须具有根从属关系。如果在注册请求中没有指定从属关系，则被注册的身份将被赋予注册服务商的从属关系。
- 如果满足以下所有条件，注册商可以注册具有属性的身份：
- 注册商可以注册具有前缀“hf”的 Fabric CA 保留属性。仅当注册商拥有该属性并且它是 hf.Registrar.Attributes 属性值的一部分时。此外，如果属性是列表类型，则被注册属性的值必须等于注册商拥有的值或该值的子集。如果该属性是布尔类型，则仅当注册服务商的属性值为“真”时，注册服务商才能注册该属性。
- 注册自定义属性（即名称不以“hf.”开头的任何属性）要求注册商具有“hf.Registar.Attributes”属性以及正在注册的属性或模式的值。唯一支持的模式是末尾带有“”的字符串。例如，“ab”是匹配所有以“ab”开头的属性名称的模式。例如，如果注册商有 hf.Registrar.Attributes=orgAdmin，那么注册商可以添加或从身份中删除的唯一属性是“orgAdmin”属性。
- 如果请求的属性名称是“hf.Registrar.Attributes”，则执行附加检查以查看此属性的请求值是否等于“hf.Registrar.Attributes”的注册商值的子集。为此，每个请求的值必须与注册商的“hf.Registrar.Attributes”属性值相匹配。例如，如果注册商的“hf.Registrar.Attributes”值为“ab*, xyz”，而请求的属性值为“abc, xyz”，则它是有效的，因为“abc”匹配“ab*”和“xyz”匹配注册商的“xyz”值。
-
例子：
有效场景：如果注册商具有属性“hf.Registrar.Attributes = ab*, xyz”并且正在注册属性“abc”，则“abc”与“ab*”匹配是有效的。如果注册商具有属性“hf.Registrar.Attributes = ab*, xyz”并且正在注册属性“xyz”，则它是有效的，因为“xyz”与注册商的“xyz”值匹配。如果注册商有属性 ‘hf.Registrar.Attributes = ab*, xyz’ 并且请求的属性值为 ‘abc, xyz’，它是有效的，因为 ‘abc’ 匹配 ‘ab*’ 并且 ‘xyz’ 匹配注册商的 ' xyz 的值。如果注册商具有属性“hf.Registrar.Roles = peer,client,admin,orderer”并且请求的属性值为“peer”、“peer,client,admin,orderer”或“client,admin”，则它是有效的因为请求的值等于注册服务商的值或者是注册商值的子集。无效场景：如果注册商具有属性“hf.Registrar.Attributes = ab*, xyz”并且正在注册属性“hf.Registar.Attributes = abc, xy*”，则它无效，因为请求的属性“xy*”不是拥有的模式由注册官。值“xy*”是“xyz”的超集。如果注册商具有属性“hf.Registrar.Attributes = ab*, xyz”并且正在注册属性“hf.Registrar.Attributes = abc, xyz, attr1”，则它是无效的，因为注册商的“hf.Registrar.Attributes”属性值不包含“attr1”。如果注册器具有属性“hf.Registrar.Attributes = ab*, xyz”并且正在注册属性“a.b”，则它是无效的，因为值“a.b”不包含在“ab*”中。如果注册器具有属性“hf.Registrar.Attributes = ab*, xyz”并且正在注册属性“x.y”，则它是无效的，因为“xyz”不包含“x.y”。如果注册商具有’hf.Registrar.Roles = peer’属性并且请求的属性值为’peer,client’，则它是无效的，因为注册商在其hf.Registrar.Roles属性值中没有客户角色。如果注册商具有属性“hf.Revoker = false”并且请求的属性值为“true”，则它是无效的，因为 hf.Revoker 属性是一个布尔属性并且注册商对该属性的值不是“true”。
下表列出了可以为身份注册的所有属性。属性名称区分大小写。
| 姓名 | 类型 | 描述 |
|---|---|---|
| hf.Registrar.Roles | 列表 | 允许注册商管理的角色列表 |
| hf.Registrar.DelegateRoles | 列表 | 允许注册商为其“hf.Registrar.Roles”属性赋予注册树的角色列表 |
| hf.Registrar.Attributes | 列表 | 注册商允许注册的属性列表 |
| hf.GenCRL | 布尔值 | 如果属性值为真，则身份能够生成 CRL |
| hf.Revoker | 布尔值 | 如果属性值为真，身份能够撤销身份和/或证书 |
| hf.AffiliationMgr | 布尔值 | 如果属性值为真，则身份能够管理从属关系 |
| hf.IntermediateCA | 布尔值 | 如果属性值为真，则身份能够注册为中间 CA |
注意：注册身份时，您指定一组属性名称和值。如果数组指定了多个同名的数组元素，则当前只使用最后一个元素。也就是说，目前不支持多值属性。
以下命令使用管理员身份的凭据注册一个新身份，其注册 ID 为“admin2”、隶属关系为“org1.department1”、名为“hf.Revoker”且值为“true”的属性以及一个属性名为“admin”，值为“true”。“:ecert”后缀意味着默认情况下“admin”属性及其值将被插入到身份的注册证书中，然后可用于做出访问控制决策。
|
|
打印密码，也称为注册密码。注册身份需要此密码。这允许管理员注册一个身份并将注册 ID 和秘密提供给其他人以注册该身份。
可以将多个属性指定为 –id.attrs 标志的一部分，每个属性必须以逗号分隔。对于包含逗号的属性值，该属性必须用双引号括起来。请参见下面的示例。
|
|
或者
|
|
您可以通过编辑客户端的配置文件为注册命令中使用的任何字段设置默认值。例如，假设配置文件包含以下内容：
|
|
然后，以下命令将注册一个新身份，其注册 ID 为“admin3”，它从命令行获取，其余部分从配置文件中获取，包括身份类型：“client”，从属关系：“org1.department1” ，以及两个属性：“hf.Revoker”和“anotherAttrName”。
|
|
要注册具有多个属性的身份，需要在配置文件中指定所有属性名称和值，如上所示。
将maxenrollments设置为 0 或将其从配置中删除将导致注册身份以使用 CA 的最大注册值。此外，正在注册的身份的最大注册值不能超过 CA 的最大注册值。例如，如果 CA 的最大注册值为 5。任何新身份的值都必须小于或等于 5，并且不能将其设置为 -1（无限注册）。
接下来，让我们注册一个 peer 身份，它将用于在下一节中注册 peer。以下命令注册peer1身份。请注意，我们选择指定我们自己的密码（或秘密）而不是让服务器为我们生成一个。
|
|
请注意，从属关系区分大小写，但服务器配置文件中指定的非叶从属关系除外，它们始终以小写形式存储。例如，如果服务器配置文件的附属部分如下所示：
|
|
BU1、Department1、BU2以小写形式存储。这是因为 Fabric CA 使用 Viper 读取配置。Viper 将映射键视为不区分大小写并始终返回小写值。要使用Team1隶属关系注册身份，需要将bu1.department1.Team1指定为–id.affiliation标志，如下所示：
|
|
注册peer身份
现在您已经成功注册了peer身份，您现在可以在给定注册 ID 和密码（即上一节中的*密码）的情况下注册peer。*这类似于注册引导身份，除了我们还演示了如何使用“-M”选项来填充 Hyperledger Fabric MSP（会员服务提供商）目录结构。
以下命令注册 peer1。请务必将“-M”选项的值替换为您peer的 MSP 目录的路径，该路径是peer的 core.yaml 文件中的“mspConfigPath”设置。您还可以将 FABRIC_CA_CLIENT_HOME 设置为您peer的主目录。
|
|
注册orderer是相同的，除了 MSP 目录的路径是orderer的 orderer.yaml 文件中的“LocalMSPDir”设置。
fabric-ca-server 颁发的所有注册证书都有如下组织单位（或简称“OU”）：
- OU 层次结构的根等于标识类型
- 为身份从属关系的每个组成部分添加一个 OU
例如，如果身份的类型为peer且其从属关系为department1.team1，则身份的 OU 层次结构（从叶到根）为OU=team1, OU=department1, OU=peer。
获取Identity Mixer凭证
Identity Mixer (Idemix) 是一种加密协议套件，用于保护隐私的身份验证和已认证属性的传输。Idemix 允许客户在没有发行者 (CA) 参与的情况下与验证者进行身份验证，并有选择地仅披露验证者需要的那些属性，并且可以在不跨交易链接的情况下这样做。
除了 X509 证书之外，Fabric CA 服务器还可以颁发 Idemix 凭证。可以通过将请求发送到/api/v1/idemix/credentialAPI 端点来请求 Idemix 凭证。有关此和其他 Fabric CA 服务器 API 端点的更多信息，请参阅swagger-fabric-ca.json。
Idemix 证书颁发是一个两步过程。首先，向 API 端点发送一个空主体的请求/api/v1/idemix/credential，以获取随机数和 CA 的 Idemix 公钥。其次，使用随机数和 CA 的 Idemix 公钥创建凭证请求，并将正文中包含凭证请求的另一个请求发送到/api/v1/idemix/credentialAPI 端点，以获取 Idemix 凭证、凭证撤销信息 (CRI) 以及属性名称和值。目前只支持三个属性：
- **OU——**身份的组织单位。此属性的值设置为身份的从属关系。例如，如果身份的从属关系是dept1.unit1，则 OU 属性设置为dept1.unit1
- IsAdmin - 身份是否为管理员。此属性的值设置为isAdmin注册属性的值。
- EnrollmentID - 身份的注册 ID
获取Idemix凭证的两步流程参考实现可以参考https://github.com/hyperledger/fabric-ca/blob/main/lib/client.go中的handleIdemixEnroll函数。
API端点/api/v1/idemix/credential接受基本和令牌授权标头。基本授权标头应包含用户的注册 ID 和密码。如果身份已经有X509注册证书，也可以用来创建token授权头。
请注意，Hyperledger Fabric 将支持客户端使用 X509 和 Idemix 凭证签署交易，但只支持对等方和订购者身份的 X509 凭证。和以前一样，应用程序可以使用 Fabric SDK 向 Fabric CA 服务器发送请求。SDK 隐藏了与创建授权标头和请求负载以及处理响应相关的复杂性。
获取Idemix CRI(证书吊销信息)
Idemix CRI（凭证撤销信息）在目的上类似于 X509 CRL（证书撤销列表）：撤销之前发布的内容。但是，存在一些差异。
在 X509 中，颁发者吊销最终用户的证书，其 ID 包含在 CRL 中。验证者检查用户的证书是否在 CRL 中，如果是，则返回授权失败。最终用户不参与这个撤销过程，除了从验证者那里收到授权错误。
在 Idemix 中，最终用户参与其中。颁发者撤销最终用户的凭证，类似于 X509，并且此撤销的证据记录在 CRI 中。CRI 提供给最终用户（又名“证明者”）。然后，最终用户根据 CRI 生成其证书未被撤销的证明。最终用户将此证明交给验证者，验证者根据 CRI 验证该证明。为了验证成功，最终用户和验证者使用的 CRI 版本（称为“epoch”）必须相同。可以通过向 API 端点发送请求来请求最新的 CRI /api/v1/idemix/cri。
当 fabric-ca-server 收到注册请求并且吊销句柄池中没有剩余的吊销句柄时，CRI 的版本会增加。在这种情况下，fabric-ca-server 必须生成一个新的撤销句柄池，它会增加 CRI 的纪元。撤销句柄池中的撤销句柄数量可通过idemix.rhpoolsize服务器配置属性进行配置。
重新注册身份
假设您的注册证书即将过期或已被盗用。您可以发出 reenroll 命令来更新您的注册证书，如下所示。
|
|
撤销证书或身份
可以撤销身份或证书。撤销身份将撤销该身份拥有的所有证书，并且还将阻止该身份获得任何新证书。吊销证书将使单个证书失效。
为了撤销证书或身份，调用身份必须具有hf.Revoker和hf.Registrar.Roles属性。吊销身份只能吊销证书或具有等于或以吊销身份的从属关系为前缀的从属关系的身份。此外，撤销者只能撤销具有在撤销者的hf.Registrar.Roles属性中列出的类型的身份。
例如，具有从属关系orgs.org1和 ‘hf.Registrar.Roles=peer,client’ 属性的撤销者可以撤销附属于orgs.org1或orgs.org1.department1的对等或客户端类型身份****，但不能撤销身份隶属于orgs.org2或任何其他类型。
以下命令禁用身份并撤销与该身份关联的所有证书。Fabric CA 服务器从此身份收到的所有未来请求都将被拒绝。
|
|
以下是可以使用-r标志指定的支持原因：
- unspecified（未指定）
- keycompromise（关键妥协）
- cacompromise（妥协）
- affiliationchanged（隶属关系改变了）
- superseded（取代）
- cessationofoperation（停止经营）
- certificatehold（持证人）
- removefromcrl（从 crl 中删除）
- privilegewithdrawn（撤销特权）
- aacompromise（一个妥协）
例如，与从属关系树的根关联的引导管理员可以撤销peer1的身份，如下所示：
|
|
属于身份的注册证书可以通过指定其 AKI（授权密钥标识符）和序列号来撤销，如下所示：
|
|
例如，您可以使用 openssl 命令获取 AKI 和证书的序列号，并将它们传递给撤销该证书的revoke命令，如下所示：
|
|
–gencrl标志可用于生成包含所有已撤销证书的 CRL（证书撤销列表）。例如，以下命令将撤销身份peer1，生成 CRL 并将其存储在**<msp 文件夹>/crls/crl.pem**文件中。
|
|
还可以使用gencrl命令生成 CRL 。有关gencrl命令的更多信息，请参阅生成 CRL（证书吊销列表）部分。
生成CRL(证书撤销列表)
在 Fabric CA 服务器中吊销证书后，还必须更新 Hyperledger Fabric 中相应的 MSP。这包括peer的本地 MSP 以及适当通道配置块中的 MSP。为此，必须将 PEM 编码的 CRL（证书撤销列表）文件放在MSP 的crls文件夹中。fabric-ca-client gencrl命令可用于生成 CRL。任何具有hf.GenCRL属性的身份都可以创建一个 CRL，其中包含在特定时期内被吊销的所有证书的序列号。创建的 CRL 存储在<msp 文件夹>/crls/crl.pem文件中。
以下命令将创建一个包含所有已撤销证书（过期和未过期）的 CRL，并将 CRL 存储在~/msp/crls/crl.pem文件中。
|
|
下一个命令将创建一个 CRL，其中包含在 2017-09-13T16:39:57-08:00 之后（由–revokedafter标志指定）和 2017-09-21T16:39 之前撤销的所有证书（过期和未过期）：57-08:00（由–revokedbefore标志指定）并将 CRL 存储在~/msp/crls/crl.pem文件中。
|
|
–caname标志指定将此请求发送到的 CA 的名称。在此示例中，gencrl 请求被发送到默认 CA。
–revokedafter和–revokedbefore标志指定时间段的下限和上限。生成的 CRL 将包含在此时间段内被吊销的证书。这些值必须是以 RFC3339 格式指定的 UTC 时间戳。–revokedafter时间戳不能大于–revokedbefore时间戳。
默认情况下，CRL 的“下一次更新”日期设置为第二天。crl.expiry CA 配置属性可用于指定自定义值。
gencrl 命令还将接受–expireafter和–expirebefore标志，这些标志可用于生成带有在这些标志指定的期限内过期的已撤销证书的 CRL。例如，以下命令将生成一个 CRL，其中包含在 2017-09-13T16:39:57-08:00 之后和 2017-09-21T16:39:57-08:00 之前被吊销的证书，以及在之后过期的证书2017-09-13T16:39:57-08:00 及之前 2018-09-13T16:39:57-08:00
|
|
启用TLS
本节更详细地描述了如何为 Fabric CA 客户端配置 TLS。
以下部分可以在fabric-ca-client-config.yaml.
|
|
certfiles选项是客户端信任的根证书集。这通常只是在ca-cert.pem文件的服务器主目录中找到的根 Fabric CA 服务器证书。
仅当在服务器上配置了双向 TLS 时才需要客户端选项
基于属性的访问控制
访问控制决策可以由链代码（以及 Hyperledger Fabric 运行时）基于身份的属性做出。这称为基于属性的访问控制，Attribute-Based Access Control,简称ABAC 。
为了使这成为可能，身份的注册证书 (ECert) 可能包含一个或多个属性名称和值。链代码然后提取属性的值以做出访问控制决策。
例如，假设您正在开发应用程序app1并希望特定的链代码操作仅可由 app1 管理员访问。您的链代码可以验证调用者的证书（由通道信任的 CA 颁发）是否包含名为app1Admin且值为true的属性。当然，属性的名称可以是任何东西，值不必是布尔值。
那么如何获得具有属性的注册证书呢？有两种方法：
-
注册身份时，您可以指定为该身份颁发的注册证书默认应包含一个属性。此行为可以在注册时被覆盖，但这对于建立默认行为很有用，并且假设注册发生在您的应用程序之外，不需要任何应用程序更改。
下面显示了如何使用两个属性注册user1 ： app1Admin和email。“:ecert” 后缀导致appAdmin属性默认插入到用户 1 的注册证书中，当用户在注册时没有明确请求属性时。默认情况下，email属性不会添加到注册证书中。
|
|
-
注册身份时，您可以明确请求将一个或多个属性添加到证书中。对于请求的每个属性，您可以指定该属性是否可选。如果不是选择性请求，身份不具备该属性，就会出错。
下面显示了如何使用 email 属性注册user1 ，没有app1Admin属性，并且可以选择使用phone属性（如果用户拥有phone属性）。
下表显示了为每个身份自动注册的三个属性。
| Attribute Name | Attribute Value |
|---|---|
| hf.EnrollmentID | 身份的注册ID |
| hf.Type | 身份类型 |
| hf.Affiliation | 身份的隶属关系 |
要默认将上述任何属性添加到证书中，您必须使用“:ecert”规范显式注册该属性。例如，以下注册身份“user1”，以便在注册时没有请求特定属性的情况下将“hf.Affiliation”属性添加到注册证书中。请注意，'–id.affiliation' 和 ‘–id.attrs’ 标志中的从属关系值（即 ‘org1’）必须相同。
|
|
有关用于基于属性的访问控制的链代码库 API 的信息，请参阅https://github.com/hyperledger/fabric-chaincode-go/blob/master/pkg/cid/README.md
动态服务器配置更新
本节介绍如何使用 fabric-ca-client 动态更新部分 fabric-ca-server 配置，而无需重新启动服务器。
本节中的所有命令都要求您首先通过执行fabric-ca-client enroll命令进行注册。
动态更新身份
本节介绍如何使用 fabric-ca-client 动态更新身份。
如果客户端身份不满足以下所有条件，则会发生授权失败：
- 客户端身份必须拥有“hf.Registrar.Roles”属性和一个逗号分隔的值列表，其中一个值等于正在更新的身份类型；例如，如果客户端的身份具有值为“client”的“hf.Registrar.Roles”属性，则客户端可以更新“client”类型的身份，但不能更新“peer”类型的身份。
- 客户端身份的从属关系必须等于或更新的身份从属关系的前缀。例如，具有“ab”从属关系的客户端可以使用“abc”从属关系更新身份，但不能更新具有“ac”从属关系的身份。如果身份需要根从属关系，则更新请求应为该从属关系指定一个点 (.)，并且客户端也必须具有根从属关系。
下面显示了如何添加、修改和删除从属关系。
获取身份信息
只要调用者满足上一节中突出显示的授权要求，调用者就可以从 fabric-ca 服务器检索有关身份的信息。以下命令显示如何获取标识。
|
|
调用者还可以通过发出以下命令来请求检索有关其有权查看的所有身份的信息。
|
|
添加身份
下面为“user1”添加了一个新身份。添加新身份执行与通过“fabric-ca-client register”命令注册身份相同的操作。添加新身份有两种可用的方法。第一种方法是通过-json标志，您可以在其中描述 JSON 字符串中的身份。
|
|
下面添加一个具有 root 隶属关系的用户。请注意“.”的隶属关系名称。表示根隶属关系。
|
|
添加身份的第二种方法是使用直接标记。请参阅下面的示例以添加“user1”。
|
|
下表列出了身份的所有字段以及它们是必需的还是可选的，以及它们可能具有的任何默认值。
| Fields | Required | Default Value |
|---|---|---|
| ID | Yes | |
| Secret | No | |
| Affiliation | No | Caller’s Affiliation |
| Type | No | client |
| Maxenrollments | No | 0 |
| Attributes | No |
修改身份
有两种可用的方法来修改现有标识。第一种方法是通过–json标志，您可以在其中描述对 JSON 字符串中的身份的修改。可以在单个请求中进行多项修改。身份的任何未修改的元素都将保留其原始值。
注意：maxenrollments 值“-2”指定要使用 CA 的最大注册设置。
下面的命令使用 –json 标志对身份进行多项修改。
|
|
下面的命令使用直接标志进行修改。以下将身份“user1”的注册密码（或密码）更新为“newsecret”。
|
|
以下将身份“user1”的从属关系更新为“org2”。
|
|
以下将身份“user1”的类型更新为“peer”。
|
|
以下将身份“user1”的最大注册数更新为 5。
|
|
通过指定最大注册值“-2”，以下内容会导致身份“user1”使用 CA 的最大注册设置。
|
|
下面将身份“user1”的“hf.Revoker”属性的值设置为“false”。如果标识具有其他属性，则不会更改它们。如果该身份之前不具有“hf.Revoker”属性，则将该属性添加到该身份。也可以通过不指定属性值来删除属性。
|
|
以下删除用户“user1”的“hf.Revoker”属性。
|
|
下面演示了可以在单个fabric-ca-client 身份修改命令中使用多个选项。在这种情况下，用户“user1”的密码和类型都会更新。
|
|
删除身份
以下删除身份“user1”并撤销与“user1”身份关联的任何证书。
|
|
注意：默认情况下，在 fabric-ca-server 中删除身份是禁用的，但可以通过使用 –cfg.identities.allowremove 选项启动 fabric-ca-server 来启用。
动态更新从属关系
本节介绍如何使用 fabric-ca-client 动态更新从属关系。下面显示如何添加、修改、删除和列出从属关系。
添加从属关系
如果客户端身份不满足以下所有条件，则会发生授权失败：
- 客户端身份必须拥有值为“true”的属性“hf.AffiliationMgr”。
- 客户端身份的从属关系必须在层次上高于正在更新的从属关系。例如，如果客户端的从属关系是“ab”，则客户端可以添加从属关系“abc”而不是“a”或“ab”。
下面添加一个名为“org1.dept1”的新从属关系。
|
|
修改从属关系
如果客户端身份不满足以下所有条件，则会发生授权失败：
- 客户端身份必须拥有值为“true”的属性“hf.AffiliationMgr”。
- 客户端身份的从属关系必须在层次上高于正在更新的从属关系。例如，如果客户端的从属关系是“ab”，则客户端可以添加从属关系“abc”而不是“a”或“ab”。
- 如果'–force’选项为真并且有必须修改的身份，则客户端身份也必须被授权修改身份。
以下将“org2”隶属关系重命名为“org3”。它还重命名任何子从属关系（例如’org2.department1' 被重命名为’org3.department1'）。
|
|
如果有受重命名从属关系影响的身份，除非使用“–force”选项，否则将导致错误。使用“–force”选项将更新受影响的身份的从属关系以使用新的从属关系名称。
|
|
删除从属关系
如果客户端身份不满足以下所有条件，则会发生授权失败：
- 客户端身份必须拥有值为“true”的属性“hf.AffiliationMgr”。
- 客户端身份的从属关系必须在层次上高于正在更新的从属关系。例如，如果客户端的从属关系是“ab”，则客户端可以删除从属关系“abc”而不是“a”或“ab”。
- 如果'–force’选项为真并且有必须修改的身份，则客户端身份也必须被授权修改身份。
以下删除从属关系“org2”以及任何子从属关系。例如，如果“org2.dept1”是“org2”下的从属关系，它也会被删除。
|
|
如果存在受删除从属关系影响的身份，除非使用“–force”选项，否则将导致错误。使用“–force”选项还将删除与该从属关系关联的所有身份，以及与这些身份中的任何一个关联的证书。
注意：默认情况下，在 fabric-ca-server 中删除从属关系是禁用的，但可以通过使用 –cfg.affiliations.allowremove 选项启动 fabric-ca-server 来启用。
列出从属关系信息
如果客户端身份不满足以下所有条件，则会发生授权失败：
- 客户端身份必须拥有值为“true”的属性“hf.AffiliationMgr”。
- 客户端身份的从属关系必须等于或高于正在更新的从属关系。例如，如果客户端的从属关系是“ab”，则客户端可能获得关于“ab”或“abc”的从属关系信息，而不是“a”或“ac”。
以下命令显示如何获取特定的从属关系。
|
|
调用者还可以通过发出以下命令请求检索有关其有权查看的所有从属关系的信息。
|
|
管理证书
本节介绍如何使用 fabric-ca-client 管理证书。
列出证书信息
调用方可见的证书包括：
- 那些属于调用者的证书
- 如果调用者拥有
hf.Registrar.Roles属性或hf.Revoker值为 的属性true，则属于调用者从属关系中和以下身份的所有证书。例如，如果客户端的从属关系是a.b，则客户端可能会获得从属关系是a.b或a.b.c但不是a或 的身份的证书a.c。
如果执行请求多个身份证书的列表命令，则仅列出具有等于或低于调用者从属关系的从属关系的身份证书。
将列出的证书可以根据 ID、AKI、序列号、过期时间、撤销时间、notrevoked 和 notexpired 标志进行过滤。
id：列出此注册 ID 的证书serial：列出具有此序列号的证书aki：列出具有此 AKI 的证书expiration：列出到期日期在此到期时间内的证书revocation：列出在此吊销时间内吊销的证书notrevoked: 列出尚未撤销的证书notexpired: 列出尚未过期的证书
您可以使用标志notexpired和notrevoked作为过滤器从结果集中排除已撤销的证书和/或过期的证书。例如，如果您只关心已过期但未被吊销的证书，则可以使用expiration和notrevoked标志来取回此类结果。下面提供了这种情况的示例。
时间应根据 RFC3339 指定。例如，要列出在 2018 年 3 月 1 日下午 1:00 和 2018 年 6 月 15 日凌晨 2:00 之间到期的证书，输入时间字符串将类似于 2018-03-01T13:00:00z 和 2018-06 -15T02:00:00z。如果时间不是问题，只有日期很重要，那么时间部分可以省略，然后字符串变为 2018-03-01 和 2018-06-15。
该字符串now可用于表示当前时间，而空字符串可用于表示任何时间。例如，now::表示从现在到未来任意时间的时间范围，::now表示从过去任意时间到现在的时间范围。
以下命令显示如何使用各种过滤器列出证书。
列出所有证书：
|
|
按 id 列出所有证书：
|
|
按序列号和 aki 列出证书：
|
|
按 id 和 serial/aki 列出证书：
|
|
列出既不是吊销者也不是按 id 过期的证书：
|
|
列出所有未被吊销的证书（管理员）：
|
|
列出所有尚未过期的证书（管理员）：
“–notexpired”标志等同于“–expiration now::”，这意味着证书将在未来某个时间过期。
|
|
列出在 id (admin) 的时间范围内被吊销的所有证书：
|
|
列出在某个时间范围内被吊销但尚未过期的所有证书（管理员）：
|
|
使用持续时间（在 30 天到 15 天前撤销）列出所有已撤销的证书（管理员）：
|
|
列出某个时间之前所有已撤销的证书
|
|
一段时间后列出所有已撤销的证书
|
|
列出现在之前和特定日期之后所有已撤销的证书
|
|
列出所有在某个时间范围内过期但尚未因 id (admin) 被吊销的证书：
|
|
使用 id (admin) 的持续时间（在 30 天到 15 天前过期）列出所有过期的证书：
|
|
列出所有已过期或将在特定时间前过期的证书
|
|
列出所有已过期或将在特定时间后过期的证书
|
|
列出现在之前和特定日期之后的所有过期证书
|
|
列出未来 10 天内到期的证书：
|
|
list certificate 命令也可用于在文件系统上存储证书。这是在 MSP 中填充 admins 文件夹的便捷方式，“-store”标志指向文件系统上存储证书的位置。
通过在 MSP 中存储身份证书，将身份配置为管理员：
|
|
联系特定的CA实例
当服务器运行多个 CA 实例时，请求可以定向到特定的 CA。默认情况下，如果客户端请求中未指定 CA 名称，则请求将定向到 fabric-ca 服务器上的默认 CA。可以使用过滤器在客户端caname命令的命令行上指定 CA 名称，如下所示：
|
|
配置一个HSM
默认情况下，Fabric CA 服务器和客户端将私钥存储在 PEM 编码文件中，但它们也可以配置为通过 PKCS11 API 将私钥存储在 HSM（硬件安全模块）中。此行为在服务器或客户端配置文件的 BCCSP（区块链加密服务提供商）部分中配置。目前，Fabric 仅支持 PKCS11 标准与 HSM 通信。
例子
以下示例演示如何配置 Fabric CA 服务器或客户端以使用名为 SoftHSM 的 PKCS11 软件版本（请参阅https://github.com/opendnssec/SoftHSMv2。
安装 SoftHSM 后，确保将 SOFTHSM2_CONF 环境变量设置为指向存储 SoftHSM2 配置文件的位置。配置文件看起来像
|
|
创建一个令牌，将其标记为“ForFabric”，将引脚设置为“98765432”（请参阅 SoftHSM 文档）。
您可以使用配置文件和环境变量来配置 BCCSP。例如，如下设置 Fabric CA 服务器配置文件的 bccsp 部分。请注意，默认字段的值为 PKCS11。
|
|
您可以通过环境变量覆盖相关字段，如下所示：
|
|
预构建的 Hyperledger Fabric Docker 映像未启用以使用 PKCS11。如果使用 Docker 部署 Fabric CA，则需要构建自己的映像并使用以下命令启用 PKCS11：
|
|
您还需要确保 PKCS11 库可供 CA 使用，方法是安装它或将其安装在容器内。如果您使用 Docker Compose 部署 Fabric CA，则可以更新您的 Compose 文件以使用卷将 SoftHSM 库和配置文件安装在容器内。例如，您可以将以下环境和卷变量添加到 Docker Compose 文件中：
|
|
文件格式
Fabric CA服务器的配置文件格式
默认配置文件在服务器的主目录中创建（有关更多信息，请参阅Fabric CA 服务器部分）。以下链接显示了示例服务器配置文件。
Fabric CA客户端的配置文件格式
默认配置文件在客户端的主目录中创建（有关更多信息，请参阅Fabric CA 客户端部分）。以下链接显示了一个样本客户端配置文件。
故障排除
- 如果您在尝试执行
fabric-ca-client或者fabric-ca-server时在 OSX 上看到Killed: 9错误，则在https://github.com/golang/go/issues/19734上有一个描述此问题的长线程。简短的回答是，要解决此问题，您可以运行以下命令：
|
|
-
如果发生以下事件序列，则会发生错误：
[ERROR] No certificates found for provided serial and akia. 您发出fabric-ca-client 注册命令，创建注册证书（即 ECert）。这会将 ECert 的副本存储在 fabric-ca-server 的数据库中。
b. fabric-ca-server 的数据库被删除并重新创建，因此丢失了步骤“a”中的 ECert。例如，如果您停止并重新启动托管 fabric-ca-server 的 Docker 容器，但您的 fabric-ca-server 使用默认的 sqlite 数据库并且数据库文件未存储在卷上，因此不是持久性的，则可能会发生这种情况.
c. 您发出fabric-ca-client 注册命令或任何其他尝试使用步骤“a”中的 ECert 的命令。在这种情况下，由于数据库不再包含 ECert，因此会发生
[ERROR] No certificates found for provided serial and aki要解决此错误，您必须通过重复步骤“a”重新注册。这将发布一个新的 ECert，该 ECert 将存储在当前数据库中。
-
向使用共享 sqlite3 数据库的 Fabric CA Server 集群发送多个并行请求时，服务器偶尔会返回“数据库已锁定”错误。这很可能是因为数据库事务在等待释放数据库锁（由另一个集群成员持有）时超时。这是一个无效的配置，因为sqlite是一个嵌入式数据库，这意味着Fabric CA服务器集群必须通过共享文件系统共享同一个文件，这就引入了SPoF（单点故障），这与集群拓扑的目的相矛盾。最佳实践是在集群拓扑中使用 Postgres 或 MySQL 数据库。
-
假设在使用 Fabric CA Server 颁发的注册证书时，peer 或 orderer 返回类似
Failed to deserialize creator identity, err The supplied identity is not valid, Verify() returned x509: certificate signed by unknown authority的错误。这表明 Fabric CA 服务器用于颁发证书的签名 CA 证书与用于进行授权检查的 MSP 的cacerts或intermediatecerts文件夹中的证书不匹配。用于进行授权检查的 MSP 取决于发生错误时您正在执行的操作。例如，如果您尝试在对等点上安装链码，则会使用对等点文件系统上的本地 MSP；否则，如果您正在执行一些特定于通道的操作，例如在特定通道上实例化链代码，则使用创世块中的 MSP 或通道的最新配置块。
要确认这是问题所在，请将注册证书的 AKI（颁发机构密钥标识符）与相应 MSP 的cacerts和intermediatecerts文件夹中证书的 SKI（主题密钥标识符）进行比较。命令openssl x509 -in
<PEM-file>-noout -text | grep -A1 “Authority Key Identifier”将显示 AKI 和openssl x509 -in<PEM-file>-noout -text | grep -A1 “Subject Key Identifier”将显示 SKI。如果它们不相等，则您已确认这是错误的原因。发生这种情况的原因有多种，包括：
a. 您使用cryptogen生成了密钥材料，但没有使用cryptogen生成的签名密钥和证书启动fabric-ca-server。
要解决（假设FABRIC_CA_SERVER_HOME设置为您的fabric-ca-server的主目录）：
a. 停止fabric-ca-server。
b. 将crypto-config/peerOrganizations/
<orgName>/ca/pem 复制到$FABRIC_CA_SERVER_HOME/ca-cert.pem。 c. 将crypto-config/peerOrganizations/
<orgName>/ca/*_sk复制到$FABRIC_CA_SERVER_HOME/msp/keystore/。 d. 启动fabric-ca-server。
e. 删除之前颁发的任何注册证书并通过重新注册获取新证书。
b. 在生成创世块后，您删除并重新创建了 Fabric CA 服务器使用的 CA 签名密钥和证书。如果 Fabric CA 服务器在 Docker 容器中运行，容器已重新启动，并且其主目录不在卷装载上，则可能会发生这种情况。在这种情况下，Fabric CA 服务器将创建一个新的 CA 签名密钥和证书。
假设您无法恢复原始 CA 签名密钥，从这种情况中恢复的唯一方法是将相应 MSP 的cacerts（或intermediatecerts ）中的证书更新为新的 CA 证书。
Fabric CA 操作指南
本指南将说明如何使用 Fabric CA 设置 Fabric 网络。参与 Hyperledger Fabric 区块链网络的所有身份都必须经过授权。此授权以加密材料的形式提供，并通过受信任的权威机构进行验证。
在本指南中，您将看到设置区块链网络的过程，该网络包括两个组织，每个组织都有两个节点和一个排序节点。您将看到如何为排序者、同行、管理员和最终用户生成加密材料，以便私钥永远不会离开生成它们的主机或容器。
拓扑结构
在此示例中，我们将研究如何跨三个组织设置排序节点、同级节点和 CA。此部署的拓扑结构如下图所示：
此示例将模拟使用 docker 容器的部署。这些容器将被视为在不同的主机上运行。这样做是为了让您可以看到哪些资产需要在网络中涉及的各方之间进行带外交换。
docker 的网络配置假定所有容器都在同一网络中运行。如果您的部署分布在不同的网络中，则需要调整示例以适应您的网络配置。
下面的文档分解了 docker-compose 文件来讨论各个组件。要查看整个 docker-compose，请单击此处。
设置CA
下载 fabric-ca-client 二进制文件
对于需要获取加密材料的每个主机，您需要在主机上提供 fabric-ca-client 二进制文件。客户端将用于连接到 Fabric CA 服务器容器。
要下载 fabric-ca-client 二进制文件，请浏览到此存储库并为您的机器选择最新的二进制文件。
此示例使用 1.4.0 版的 fabric-ca-client。
设置TLS CA
TLS CA 用于颁发 TLS 证书。为了保护各种进程之间的通信，需要这些证书。
为了简化此示例，所有组织都将使用相同的 TLS CA 并禁用 TLS 相互身份验证。
在生产环境中，您可能会使用您组织的 CA 来获取 TLS 证书。您必须将您的 CA 证书带外传输给将验证您的 TLS 证书的组织。因此，与此示例不同，每个组织都有自己的 TLS CA。
如下所示的 docker 服务可用于启动 Fabric TLS CA 容器。
|
|
可以使用以下 docker 命令启动此容器。
|
|
成功启动容器后，您将在 CA 容器的日志中看到以下行。
|
|
此时 TLS CA 服务器正在侦听安全套接字，并且可以开始颁发 TLS 证书。
注册 TLS CA 的管理员
在开始使用 CA 客户端之前，您必须获取 CA 的 TLS 证书的签名证书。这是使用 TLS 连接之前的必需步骤。
在我们的示例中，您需要获取位于/tmp/hyperledger/tls-ca/crypto/ca-cert.pem运行 TLS CA 服务器的计算机上的文件，并将该文件复制到您将运行 CA 客户端二进制文件的主机上。此证书，也称为 TLS CA 的签名证书，将用于验证 CA 的 TLS 证书。将证书复制到 CA 客户端的主机后，您就可以开始使用 CA 发出命令。
TLS CA 的签名证书将需要在每台将针对 TLS CA 运行命令的主机上可用。
TLS CA 服务器以引导程序身份启动，该身份具有服务器的完全管理员权限。管理员的一项关键能力是注册新身份的能力。该 CA 的管理员将使用 Fabric CA 客户端向 CA 注册四个新身份，一个用于每个对等方，一个用于排序者。这些身份将用于为同行和订购者获取 TLS 证书。
您将发出以下命令以注册 TLS CA 管理员，然后注册身份。我们假设已将 TLS CA 的受信任根证书复制到/tmp/hyperledger/tls-ca/crypto/tls-ca-cert.pem将通过 fabric-ca-client 与该 CA 通信的所有主机上。
|
|
如果环境变量 FABRIC_CA_CLIENT_TLS_CERTFILES 的路径不是绝对路径，它将被解析为相对于客户端的主目录。
使用在 TLS CA 上注册的身份，我们可以继续设置每个组织的网络。任何时候我们需要为组织中的节点获取 TLS 证书时，我们都会参考这个 CA。
设置 Orderer Org CA
每个组织都必须有自己的证书颁发机构 (CA) 来颁发注册证书。CA 将为组织中的每个同级和客户端颁发证书。
您的 CA 创建属于您的组织的身份，并为每个身份颁发公钥和私钥。这些密钥允许您的所有节点和应用程序签署和验证它们的操作。由您的 CA 签名的任何身份都将被网络的其他成员理解，以识别属于您的组织的组件。
Org0 的管理员将启动一个 Fabric CA docker 容器，Org0 将使用它来为 Org0 中的身份发布加密材料。
如下所示的 docker 服务可用于启动 Fabric CA 容器。
|
|
成功启动容器后，您将在 CA 容器的日志中看到以下行。
|
|
此时 CA 服务器正在侦听安全套接字，并可以开始发布加密材料。
注册 Orderer 组织的 CA 管理员
您将发出以下命令以注册 CA 管理员，然后注册 Org0 的两个身份。
在下面的命令中，我们假设 CA 的 TLS 证书的可信根证书已复制到/tmp/hyperledger/org0/ca/crypto/ca-cert.pem存在 fabric-ca-client 二进制文件的主机上。如果客户端二进制文件位于不同的主机上，您将需要通过带外进程获取签名证书。
以下身份将被注册：
- Orderer (orderer1-org0)
- Orderer admin (admin-org0)
|
|
您在上面执行的注册命令将使用从/tmp/hyperledger/org0/ca/adminCA 颁发的加密材料填充目录。您将看到如下文件：
|
|
fabric-ca-client-config.yaml是CA客户端生成的文件，这个文件包含了CA客户端的配置。还有其他三个重要文件需要注意。第一个是0-0-0-0-7053.pem，这是为此身份颁发证书的 CA 的公共证书。其次是60b6a16b8b5ba3fc3113c522cce86a724d7eb92d6c3961cfd9afbd27bf11c37f_sk，这是由客户端生成的私钥。该文件的名称是可变的，每次生成密钥时都会不同。最后一项是cert.pem，这是 CA 签发的管理员证书。
设置 Org1 的 CA
您为 Org0 执行的同一组步骤适用于 Org1 的 CA。
Org1 的管理员将启动一个 Fabric CA docker 容器，Org1 将使用该容器为 Org1 中的身份发布加密材料。
如下所示的 docker 服务可用于启动 Fabric CA 容器。
|
|
成功启动容器后，您将在 CA 容器的日志中看到以下行。
|
|
此时 CA 服务器正在侦听安全套接字，并可以开始发布加密材料。
注册 Org1 的 CA 管理员
您将发出以下命令以注册 CA 管理员，然后注册 Org1 的两个身份。
正在注册以下身份：
- Peer 1 (peer1-org1)
- Peer 2 (peer2-org1)
- Admin (admin1-org1)
- End user (user-org1)
在下面的命令中，我们假设 CA 的 TLS 证书的可信根证书已复制到/tmp/hyperledger/org1/ca/crypto/ca-cert.pem存在 fabric-ca-client 二进制文件的主机上。如果客户端的二进制文件位于不同的主机上，您将需要通过带外进程获取签名证书。
|
|
设置 Org2的CA
您对 Org1 遵循的一组相同步骤适用于 Org2。因此，我们将快速完成 Org2 管理员将执行的一组步骤。
如下所示的 docker 服务可用于为 Org2 启动 Fabric CA。
|
|
成功启动容器后，您将在 CA 容器的日志中看到以下行。
|
|
注册 Org2 的 CA 管理员
您将发出以下命令以注册 CA 管理员并注册所有对等相关身份。在下面的命令中，我们假设 CA 的 TLS 证书的受信任根证书已复制到/tmp/hyperledger/org2/ca/crypto/ca-cert.pem.
|
|
设置Peers
一旦 CA 启动并运行，我们就可以开始注册Peers。
设置 Org1 的Peers
Org1 的管理员将向其 CA 注册对等点，然后启动对等点 docker 容器。在启动对等点之前，您需要向 CA 注册对等点身份以获取对等点将使用的 MSP。这称为本地对等 MSP。
注册Peer1
如果运行 Peer1 的主机没有 fabric-ca-client 二进制文件，请参阅上面的说明下载二进制文件。
在下面的命令中，我们假设 Org1 的受信任根证书已复制到/tmp/hyperledger/org1/peer1/assets/ca/org1-ca-cert.pemPeer1 的主机上。获取签名证书是一个带外过程。
|
|
下一步是为peer获取 TLS 加密材料。这需要再次注册，但这次您将根据tlsTLS CA 上的配置文件进行注册。您还需要在注册请求中提供 Peer1 的主机地址作为标志的输入csr.hosts。在下面的命令中，我们假设 TLS CA 的证书已复制到/tmp/hyperledger/org1/peer1/assets/tls-ca/tls-ca-cert.pem在Peer1 的主机上。
|
|
转到路径/tmp/hyperledger/org1/peer1/tls-msp/keystore并将密钥的名称更改为key.pem. 这样可以方便地在后面的步骤中参考。
此时，您将拥有两个 MSP 目录。一个 MSP 包含对等方的注册证书，另一个具有对等方的 TLS 证书。但是需要在注册MSP目录下多加一个文件夹，就是这个admincerts文件夹。此文件夹将包含 Org1 管理员的证书。当我们进一步注册 Org1 的管理员时，我们将更多地讨论这个问题。
注册Peer2
您将为 Peer2 执行类似的命令。在下面的命令中，我们假设 Org1 的受信任根证书已复制到/tmp/hyperledger/org1/peer2/assets/ca/org1-ca-cert.pemPeer2 的主机上。
|
|
下一步是为对等方获取 TLS 加密材料。这需要再次注册，但这次您将根据tlsTLS CA 上的配置文件进行注册。您还需要在注册请求中提供 Peer2 主机的地址作为标志的输入csr.hosts。在下面的命令中，我们假设 TLS CA 的证书已复制到/tmp/hyperledger/org1/peer2/assets/tls-ca/tls-ca-cert.pemPeer2 的主机上。
|
|
转到路径/tmp/hyperledger/org1/peer2/tls-msp/keystore并将密钥的名称更改为key.pem. 这样可以方便地在后面的步骤中参考。
此时，您将拥有两个 MSP 目录。一个 MSP 包含对等方的注册证书，另一个具有对等方的 TLS 证书。admincerts管理员注册后，您会将文件夹添加到注册 MSP。
注册 Org1 的管理员
此时，两个peer都已注册。现在，您将注册 Org1 的管理员身份。管理员身份负责安装和实例化链代码等活动。以下步骤将注册管理员。在下面的命令中，我们假设它们在 Peer1 的主机上执行。
|
|
注册后，您应该有一个管理 MSP。您将从该 MSP 复制证书并将其移动到admincerts文件夹中的 Peer1 的 MSP。您需要将此管理员证书分发给组织中的其他同级，并且需要进入admincerts每个同级的 MSP 的文件夹中。
下面的命令仅适用于 Peer1，将管理证书交换到 Peer2 将在带外发生。
|
|
如果该admincerts文件夹在对等方的本地 MSP 中丢失，则peer将无法启动。
启动 Org1 的Peers
一旦我们注册了所有节点和组织管理员，我们就有了启动节点所需的 MSP。
如下所示的 docker 服务可用于为 Peer1 启动容器。
|
|
启动对等服务将启动一个peer容器，在日志中您将看到以下行：
|
|
如下所示的 docker 服务可用于为 Peer2 启动容器。
|
|
启动对等服务将启动一个对等容器，在日志中您将看到以下行：
|
|
设置 Org2 的Peers
Org2 的管理员将使用 CA 的引导程序身份向 CA 注册对等点，然后启动对等 docker 容器。
注册Peer1
您将发出以下命令来注册 Peer1。在下面的命令中，我们假设 Org2 的受信任根证书在/tmp/hyperledger/org2/peer1/assets/ca/org2-ca-cert.pemPeer1 的主机上可用。
|
|
接下来，您将获得 TLS 证书。在下面的命令中，我们假设 TLS CA 的证书已复制到/tmp/hyperledger/org2/peer1/assets/tls-ca/tls-ca-cert.pemPeer1 的主机上。
|
|
转到路径/tmp/hyperledger/org2/peer1/tls-msp/keystore并将密钥的名称更改为key.pem.
注册 Peer2
您将发出以下命令以注册 Peer2。在下面的命令中，我们假设 Org2 的受信任根证书在/tmp/hyperledger/org2/peer2/assets/ca/org2-ca-cert.pemPeer2 的主机上可用。
|
|
接下来，您将获得 TLS 证书。在下面的命令中，我们假设 TLS CA 的证书已复制到/tmp/hyperledger/org2/peer2/assets/tls-ca/tls-ca-cert.pemPeer2 的主机上。
|
|
转到路径/tmp/hyperledger/org2/peer2/tls-msp/keystore并将密钥的名称更改为key.pem.
注册 Org2 的管理员
此时，您将拥有两个 MSP 目录。一个 MSP 包含您的注册证书，另一个包含您的 TLS 证书。但是需要在注册MSP目录下多加一个文件夹，就是这个admincerts文件夹。此文件夹将包含 Org2 管理员的证书。以下步骤将注册管理员。在下面的命令中，我们假设它们在 Peer1 的主机上执行。
|
|
注册后，您应该有一个管理 MSP。您将从该 MSP 复制证书并将其移动到该admincerts文件夹下的对等 MSP。下面的命令仅适用于 Peer1，admin 证书到 peer2 的交换将在带外发生。
|
|
如果该admincerts文件夹在peer的本地 MSP 中丢失，则peer将无法启动。
启动 Org2 的Peers
一旦我们注册了所有的节点和管理员，我们就有了必要的 MSP 来启动节点。
如下所示的 docker 服务可用于为 peer1 启动容器。
|
|
启动peer服务将启动一个peer容器，在日志中您将看到以下行：
|
|
如下所示的 docker 服务可用于为 peer2 启动容器。
|
|
启动peer服务将启动一个peer容器，在日志中您将看到以下行：
|
|
设置Orderer
我们需要设置的最后一件事是Orderer。在启动Orderer之前，我们需要采取一些行动。
注册 Orderer
在启动订购者之前，您需要向 CA 注册订购者的身份，以获取订购者将使用的 MSP。这称为本地订购者 MSP。
如果主机没有 fabric-ca-client 二进制文件，请参考上面的说明下载二进制文件。
您将发出以下命令以注册订购者。在下面的命令中，我们将假设 Org0 的可信根证书在/tmp/hyperledger/org0/orderer/assets/ca/org0-ca-cert.pem订购者的主机上可用。
|
|
接下来，您将获得 TLS 证书。在下面的命令中，我们假设 TLS CA 的证书已复制到/tmp/hyperledger/org0/orderer/assets/tls-ca/tls-ca-cert.pem在Orderer的主机上。
|
|
转到路径/tmp/hyperledger/org0/orderer/tls-msp/keystore并将密钥的名称更改为key.pem.
此时，您将拥有两个 MSP 目录。一个 MSP 包含您的注册证书，另一个包含您的 TLS 证书。但是需要在注册MSP目录下多加一个文件夹，就是这个admincerts文件夹。此文件夹将包含 peer 1 管理员的证书。现在，您将通过发出以下命令来注册 Org0 的管理员身份。
注册 Org0 的管理员
下面的命令假定这是在Orderer的主机上执行的。
|
|
注册后，您应该在 处有一个 msp 文件夹/tmp/hyperledger/org0/admin。您将从该 MSP 复制证书并将其移动到订购者的 MSPadmincerts文件夹下。
|
|
创建创世区块和通道交易
Orderer需要一个创世块来引导自己。您可以在Hyperledger Fabric 文档中找到更多信息
configtx.yaml在下面的文档中，您会找到针对此特定部署编写的片段。如需完整信息configtx.yaml，请单击此处。
在Orderer的主机上，我们需要收集所有组织的 MSP。该organization部分看起来configtx.yaml像：
|
|
Org0 的 MSP 将包含 Org0 的可信根证书、Org0 管理员身份的证书以及 TLS CA 的可信根证书。MSP 文件夹结构如下所示。
|
|
所有组织的模式都相同。Org1 的 MSP 文件夹结构如下：
|
|
Org2 的 MSP 文件夹结构如下：
|
|
一旦所有这些 MSP 都存在于订购者的主机上，您将从configtx.yaml存在的目录中执行以下命令：
|
|
这将生成两个工件genesis.block和channel.tx，它们将在后面的步骤中使用。
收集证书的命令
Fabric CA 客户端有几个命令，可用于获取订购者创世和对等 MSP 设置的证书。
第一个命令是fabric-ca-client certificate命令。此命令可用于获取 admincerts 文件夹的证书。该命令的更多使用方法请参考：列出证书信息
第二个命令是fabric-ca-client getcainfo命令。此命令可用于为cacerts和tlscacerts文件夹收集证书。getcainfo命令返回 CA 的证书。
双向 TLS
也可以使用 Mutual TLS 保护端点。如果 CA、Peer 或 Orderer 使用双向 TLS，则客户端还必须提供将由服务器验证的 TLS 证书。
Mutual TLS 要求客户端获取将提交给服务器的 TLS 证书。可以通过启用了双向 TLS 的 TLS 证书颁发机构来获取 TLS 证书。客户端获得 TLS 证书后，只要服务器上受信任的 TLS 颁发机构与客户端 TLS 证书的颁发机构相同，它就可以开始与启用 TLS 的相互服务器进行通信。
启动Orderer
一旦创建了创世块和通道交易，就可以定义一个指向上面创建的 genesis.block 的排序服务。
|
|
启动排序服务将启动一个排序容器，在日志中您将看到以下行：
|
|
创建CLI容器
与Peer的通信需要一个 CLI 容器，该容器包含适当的二进制文件，可让您发出与Peer相关的命令。您将为每个组织创建一个 CLI 容器。在此示例中，我们在与每个组织的 Peer1 相同的主机中启动一个 CLI 容器。
启动 Org1 的 CLI
|
|
启动 Org2 的 CLI
|
|
创建并加入通道
Org1
随着 CLI 容器的启动和运行，您现在可以发出命令来创建和加入频道。我们将使用 Peer1 创建通道。在 Peer1 的主机中，您将执行：
|
|
此命令将带您进入 CLI 容器并打开一个终端。从这里，您将使用管理 MSP 执行以下命令：
|
|
channel.tx是通过在orderer上运行configtxgen命令生成的工件。这个工件需要从排序者带外传输到 Peer1 的主机。上面的命令将在指定输出路径/tmp/hyperledger/org1/peer1/assets/mychannel.block的 Peer1 上生成mychannel.block，网络中所有希望加入通道的Peers都将使用该命令。mychannel.block将需要在带外传输到 Org1 和 Org2 中的所有对等点。
您要运行的下一个命令是让 Peer1 和 Peer2 加入频道。
|
|
Org2
运行以下命令进入 docker CLI 容器。
|
|
在 Org2 中，你只需要让 peer 加入通道即可。Org2 中的 Peer 不需要创建通道，这已经由 Org1 完成了。从 Org2 CLI 容器内部，您将使用管理 MSP 执行以下命令：
|
|
安装和实例化Chaincode
从 Github将此链代码下载到两个组织中 Peer1 上的本地文件系统。
Org1
在 Peer1 上，您将安装链码。该命令假定需要安装的链代码在 GOPATH 中可用。在这个例子中，我们假设链码位于/opt/gopath/src/github.com/hyperledger/fabric-samples/chaincode/abac/goGOPATH 中/opt/gopath。从 Org1 的 CLI 容器中，您将执行以下命令：
|
|
peer2 将遵循相同的一组步骤。
|
|
Org2
在 Peer1 上，您将执行与 Org1 相同的步骤。该命令假定需要安装的链代码在 处可用/opt/gopath/src/github.com/hyperledger/org2/peer1/assets/chaincode/abac/go。从 Org2 的 CLI 容器中，您将执行以下命令：
|
|
peer2 将遵循相同的一组步骤。
|
|
下一步将是实例化链代码。这是通过执行来完成的：
|
|
调用和查询链代码
在 Org1 的 CLI 容器中，执行：
|
|
这应该返回一个值100。
在 Org2 的 CLI 容器中，执行：
|
|
这将从a的值中减去 10并将其移动到b。现在，如果您通过运行查询：
|
|
这应该返回一个值90。
Fabric CA 操作指南到此结束。
Fabric CA 部署指南
本指南将说明如何使用 Fabric CA 二进制文件为生产网络设置 Fabric CA。在您掌握了使用这些二进制文件部署和运行 CA 之后，您可能希望改用 Fabric CA 映像，例如在 Kubernetes 或 Docker 部署中。不过现在，本指南的目的是教您如何正确使用二进制文件。然后该过程可以扩展到其他环境。
第一个主题向您介绍如何规划 CA 并决定您的组织所需的 CA 拓扑。接下来，您应该查看生产 CA 服务器的清单，以了解 CA 最常见的配置参数以及它们如何相互交互。最后，CA 部署步骤将引导您完成为生产网络配置 TLS CA、组织 CA 以及可选的中间 CA 的过程。完成此配置后，您就可以使用组织 CA 或中间 CA（如果您创建了中间 CA）来为您的组织注册身份。
部署生产CA
- Planning for a CA
- Checklist for a production CA server
- CA Deployment steps
- Registering and enrolling identities with a CA
规划CA
听众：架构师、网络运营商、设置生产结构网络的用户，熟悉传输层安全性 (TLS)、公钥基础设施 (PKI) 和成员服务提供商 (MSP)。
这些部署说明提供了有关如何为生产网络部署 CA 的指南。如果您需要快速建立一个网络用于教育或测试目的，请查看Fabric 测试网络。虽然 Fabric CA 服务器仍然是 Hyperledger Fabric 的首选和经过测试的证书颁发机构，但您可以在 Fabric 网络中使用来自非 Fabric CA 的证书；但是，本部署指南的范围集中在使用 Fabric CA。它侧重于您需要考虑的最重要的配置参数，并提供配置 CA 的最佳实践。
您可能已经熟悉 Fabric CA用户指南和操作指南。本主题旨在在部署 CA 之前告知您的决策，并提供有关如何根据这些决策配置 CA 参数的指导。在您做出决定时，您可能仍需要参考这些主题。
回想一下，Fabric CA 在区块链网络上执行以下功能：
- 注册身份，或连接到轻量级目录访问协议 (LDAP) 作为用户注册表。
- 颁发注册证书 (ECerts)。注册是 Fabric CA 颁发证书密钥对的过程，该密钥对由签名证书和构成身份的私钥组成。私钥和公钥首先由 Fabric CA 客户端在本地生成，然后将公钥发送到 CA，CA 返回编码证书，即签名证书。
- 证书更新和吊销。
您有机会自定义这些函数的行为。CA 第一次启动时，它会查找包含 CA 配置参数的fabric-ca-server-config.yaml 文件。如果该文件不存在，将为您创建一个默认文件。在部署您的 CA 之前，本主题提供有关该文件中的参数的指导以及您需要做出的决定，以便根据您的用例自定义 CA。
您将在您的网络上使用什么 CA 拓扑？
网络上 CA 的拓扑结构可能会有所不同，具体取决于参与网络的组织数量以及您希望如何管理 CA。
需要多少个 CA？
在配置 CA 之前，您需要了解您的网络需要多少个 CA。如果您阅读部署过程概述，您会记得建议您为每个组织部署两个 CA，一个组织 CA 和一个 TLS CA。任何生产网络都需要 TLS 通信来保护组织中节点之间的通信。因此，是 TLS CA 颁发了这些 TLS 证书。另一方面，组织 CA 用于生成组织和节点身份。另外，因为这是一个分布式账本，排序服务不应与同行属于同一组织，因此您需要为同行组织和排序服务组织提供单独的组织（因此需要 CA）。当多个组织为排序服务贡献节点时，每个排序节点都会有自己的组织 CA。所有这些分离对于排序服务和通道的分布式管理至关重要，并且可以阻止不良行为者破坏网络的能力。
为什么建议使用单独的 TLS 服务器？
单独的 TLS 服务器提供独立的信任链，仅用于保护通信。大多数组织更喜欢 TLS 通信由单独的加密材料保护——来自不同的根，来自单独的 Fabric TLS CA 或另一个外部证书颁发机构。
Fabric 提供的一个选项是配置双头 CA 的能力，单个 CA 在幕后包括组织的身份注册 CA（以下称为组织 CA）和 TLS CA。它们在相同的 CA 节点和端口上运行，但可以通过不同的 CA 名称进行寻址。本主题后面更详细讨论的参数cafiles允许每个 CA 拥有自己的配置，但在您希望两个 CA 共享同一个后端数据库时很有用。因此，使用此选项，当部署组织 CA 时，TLS CA 会自动为您一起部署。
还值得注意的是，从功能的角度来看，Fabric 组织 CA 和 Fabric TLS CA 之间没有区别。区别在于它们生成的证书类型。
我什么时候需要中间 CA？
中间 CA 是可选的。为了增加安全性，组织可以部署称为中间 CA 的 CA 链。中间 CA 的根证书由父 CA（根 CA）或另一个中间机构（成为父 CA）颁发，它为链中任何 CA 颁发的任何证书建立“信任链”。因此，拥有一个或多个中间 CA 可以保护您的信任根。这种追溯到根 CA 的能力不仅允许 CA 的功能扩展，同时仍然提供安全性——允许使用证书的组织自信地使用中间 CA——它限制了根 CA 的暴露，如果被破坏，将危及整个信任链。另一方面，如果中间 CA 遭到破坏，暴露的风险就会小得多。
包含中间 CA 的另一个原因是当您拥有一个拥有多个部门的非常大的组织并且您不希望单个 CA 为所有部门生成证书时。中间 CA 提供了一种机制，用于将 CA 管理的证书范围限定到较小的部门或子组。不需要中间 CA，但它们可以降低风险和范围证书管理。如果组织中只有少数成员，这种模式会导致大量窃听。作为部署多个中间 CA 的替代方法，您可以配置一个 CA affiliations（类似于部门）。稍后我们讨论时会详细介绍affiliations。
此外，在可以接受使用一个 TLS CA 颁发证书以保护整个组织的通信的情况下，中间 CA 使用与根 CA 相同的 TLS CA 而不是拥有自己的专用 TLS 是合理的加州。
应该以什么顺序部署 CA？
如果双头CA没有配置组织CA和TLS CA，那么TLS CA是单独部署的，需要在组织CA之前部署，才能为组织CA生成TLS证书。部署 TLS CA 后，可以部署组织 CA，然后根据需要部署任何中间 CA。
决定用户注册表
因为 Fabric CA 控制组织的身份，所以您需要在配置 CA 之前决定您的用户注册表。Fabric CA 服务器可以配置为使用数据库作为用户注册表，也可以配置为从轻量级目录访问协议 (LDAP) 服务器读取。LDAP 是服务器数据存储和检索的行业标准，其中信息表示为分层树。LDAP 协议用于在服务器上查找数据，在此上下文中，数据是用户和组，因此服务器是用户存储库。当 LDAP 服务器将成为您的用户存储库时，您将需要提供连接和配置详细信息。为 CA 配置 LDAP 后，它会在为该用户生成证书之前根据 LDAP 用户注册表验证身份，enrollment. 此外，从 LDAP 注册表中检索的用户属性对于在智能合约中做出访问控制决策很有用。如果您想了解有关 LDAP 注意事项的更多信息，请参阅配置 LDAP 。
本部署指南演示了使用数据库配置用户注册表的过程。
关于配置的说明
可以通过三种方式在 Fabric CA 服务器和客户端上配置设置。覆盖默认设置的优先顺序是：
- 使用Fabric CA 服务器 CLI 命令。
- 使用环境变量覆盖配置文件设置。
- 修改配置文件。
此顺序意味着从代码的角度来看，在 Fabric CA 服务器 CLI 命令上传递的任何标志都将覆盖环境变量（如果存在相同设置）以及配置文件中设置的默认值。同样，环境变量可用于覆盖配置文件中的设置。但是，不鼓励使用环境变量来修改配置设置，因为更改不会持久化，并且可能会在以后未设置或未设置为应有的设置时导致问题。了解配置文件中的参数及其对文件中其他参数设置的依赖性很重要。使用环境变量盲目地覆盖一个设置可能会影响另一个设置的功能。所以，**对配置文件中的设置进行修改，**以熟悉可用设置及其工作方式。
请注意，一些配置设置存储在 CA 数据库中，这意味着在 CA 启动后，无法再通过编辑配置文件或设置环境变量来覆盖这些设置。这些说明中通篇注明了受影响的参数。在这些情况下，需要使用 Fabric CA 服务器 CLI 命令进行修改，并且具有不需要重新启动服务器的额外好处。
生产CA服务器的清单
在准备构建生产 Fabric CA 服务器时，您需要考虑 fabric-ca-server-config.yaml 文件中以下字段的配置。当您初始化CA 服务器时，会为您生成此文件，以便您可以在实际启动服务器之前自定义它。
该清单涵盖了用于设置生产网络的关键配置参数。当然，您始终可以参考fabric-ca-server-config.yaml 文件以获取其他参数或更多信息。本主题中的参数列表包括：
CA
|
|
首先为您的 CA 命名。该名称通常表示此 CA 将服务的组织。或者，如果这是一个 TLS CA，您可能希望在名称中指明它。当通过 Fabric CA Client --caname参数将请求定位到此服务器时使用ca.name。如果此 CA 的加密材料是在其他地方生成的，您可以提供文件的名称以及它们所在位置的完全限定路径或相对路径。参数keyfile是私钥，certfile是公钥。
该chainfile参数仅适用于中间 CA。启动中间 CA 时，CA 将在该参数指定的位置创建链文件。该文件将包含以根证书开头的受信任链的证书以及任何中间证书。
TLS
|
|
配置此部分以启用 CA 的 TLS 通信。启用 TLS 后，所有与 CA 进行交易的节点也需要启用 TLS。
tls.enabled：对于安全的生产环境，应该通过在配置文件的部分中设置enabled: true启用tls以在节点之间进行安全通信。（请注意，默认情况下它是禁用的，这对于测试网络来说可能是可以接受的，但对于生产它需要启用它。）此设置将配置server-side TLS，这意味着 TLS 将向客户端保证服务器的身份并提供双向它们之间的加密通道。tls.certfile：每个 CA 都需要注册并注册其 TLS CA，然后才能与组织中的其他节点安全地进行交易。因此，在部署组织 CA 或中间 CA 之前，您必须先部署 TLS CA，然后向 TLS CA 注册并注册组织 CA 引导身份，以生成组织 CA 的 TLS 签名证书。当您使用 Fabric CA 客户端生成证书时，会在signedcerts文件夹的指定 msp 目录的文件夹FABRIC_CA_CLIENT_HOME中生成 TLS 签名证书。例如：/msp/signcerts/cert.pem。然后，在此tls.certfile字段中，提供生成的 TLS 签名证书的名称和位置。如果这是根 TLS CA，则此字段可以为空。tls.keyfile：与tls.certfile类似，提供为此 CA 生成的 TLS 私钥的名称和位置。例如：/msp/keystore/87bf5eff47d33b13d7aee81032b0e8e1e0ffc7a6571400493a7c_sk。如果您使用的是 HSM 或者这是根 TLS CA，则此字段将为空白。
**注意：**至少在生产网络中，server-side TLS应该启用。
如果服务器端 TLS 足以满足您的需求，则您已完成本节。如果您需要在网络中使用双向 TLS，则需要配置以下两个附加字段。（默认情况下禁用双向 TLS。）
tls.clientauth.type：如果服务端额外需要验证客户端的身份，那么就需要**双向TLS （mTLS）。**配置 mTLS 后，客户端需要在 TLS 握手期间发送其证书。要为 mTLS 配置您的 CA，请将clientauth.type设置为RequireAndVerifyClientCert.tls.clientauth.certfiles：仅对于 mTLS，提供服务器在验证客户端证书时使用的根证书颁发机构的 PEM 编码列表。在虚线 yaml 列表中指定证书。
cafiles
|
|
正如规划 CA主题中提到的，该cafiles参数可用于配置双头 CA – 一个在幕后包括组织 CA 和 TLS CA 的单个 CA。这种使用模式可能是为了方便起见，允许每个 CA 维护自己的配置但仍共享相同的后端用户数据库。在cafiles参数中，输入第二个 CA 服务器的路径fabric-ca-server-config.yaml，例如 TLS CA。辅助 CA 的配置可以包含与主 CA 服务器配置文件中相同的所有元素，除了port和tls部分。
如果这不是您的 CA 所需的配置，您可以将此参数的值留空。
中间CA
|
|
中间 CA 不是必需的，但为了降低您的组织（根）CA 受到威胁的风险，您可能希望在您的网络中包含一个或多个中间 CA。
**重要提示：**在设置中间 CA 之前，您需要验证父 CA 中的csr.ca.pathlength参数值。设置为0时，组织 CA 可以颁发中间 CA 证书，但这些中间 CA 可能不会依次注册其他中间 CA。如果您希望您的中间 CA 能够注册其他中间 CA，则根 CAcsr.ca.pathlength需要设置为1. 如果您希望这些中间 CA 注册其他中间 CA，则csr.ca.pathlength需要将根 CA 设置为2.
parentserver.url: 以格式指定父服务器urlhttps://<PARENT-CA-ENROLL-ID>:<PARENT-CA-SECRET>@<PARENT-CA-URL>:<PARENT-CA-PORT>。parentserver.caname：ca.name父CA服务器的入口。enrollment.profile:signing.profile：输入父 CA的值。通常这是ca.tls.certfiles：输入 TLS CA 签名证书文件的位置和名称ca-cert.pem文件。例如，tls/ca-cert.pem。此位置相对于服务器配置 .yaml 文件所在的位置。
除了编辑此intermediate部分之外，您还需要编辑此中间 CA 的配置 .yaml 文件的以下部分：
csr- 确保该csr.cn字段为空白。port- 请务必为中间 CA 设置一个唯一的端口。signing-仅当中间 CA 将作为其他中间 CA 的父 CA 时，验证isca设置为true，并且maxpathlen设置为0大于根 CA，否则应设置为0。请参阅签名参数。
port
|
|
每个 CA 必须在其自己唯一的端口上运行，并且显然不能与在该端口上运行的任何其他服务冲突。您需要提前决定要为您的 CA 使用哪些端口，并在 .yaml 文件中配置该端口。
用户注册
|
|
如果您没有使用 LDAP 用户注册表，那么需要db:部分以及关联的注册表数据库部分。此部分可用于在服务器启动时向 CA 注册用户列表。请注意，它只是注册用户，并不为他们生成注册证书。您使用 Fabric CA 客户端生成关联的注册证书。
maxenrollments：用于限制使用注册 ID 和密码为用户生成证书的次数。reenroll命令可用于获取证书，没有任何限制。identities：此部分定义用户列表及其在 CA 启动时要注册的相关属性。运行fabric-ca-server init命令后，此处的<<<adminUserName>>>和<<<adminPassword>>>将替换为通过-b命令选项指定的 CA 服务器引导身份用户和密码。identities.type：对于 Fabric，有效类型列表为client、peer、admin、orderer和member。affiliation：选择要与关联参数指定的用户关联的从属关系name:。可能的从属关系列表在本affiliations:节中定义。attrs：上面包含的角色列表适用于“管理员”用户，这意味着他们可以注册和注册其他用户。如果您注册的是非管理员用户，则不会授予他们这些权限。与身份关联的属性hf会影响该身份注册其他用户的能力。您应该查看有关注册新身份的主题以了解所需的模式。
当用户随后“注册”时，type、affiliation和attrs在用户的签名证书中可见，并被策略用于强制授权。回想一下enrollmentFabric CA 颁发证书密钥对的过程，该密钥对由签名证书和构成身份的私钥组成。私钥和公钥首先由 Fabric CA 客户端在本地生成，然后将公钥发送到 CA，CA 返回编码证书，即签名证书。
用户注册后，可以使用Identity命令修改用户的属性。
注册数据库
|
|
Fabric CA 将用户身份、从属关系、凭证和公共证书存储在数据库中。使用此部分指定用于存储 CA 数据的数据库类型。Fabric 支持三种数据库类型：
sqlite（SQLite 版本 3）postgres(PostgreSQL)mysql(MySQL)
如果您在集群中运行数据库，则必须选择postgres或mysql作为数据库类型。
如果 LDAP 被用作用户注册表（由ldap.enabled:true指定），那么忽略此部分。
LDAP
|
|
如果配置了 LDAP 注册表，则忽略注册表部分中的所有设置。
affiliations
|
|
隶属关系对于为组织指定子部门很有用。然后可以从策略定义中引用它们，例如，当您可能希望交易得到一个不仅是 ORG1 的成员，而且是 ORG1.MANUFACTURING 的成员的对等点背书时。请注意，注册商的从属关系必须等于或作为正在注册的身份从属关系的前缀。如果您正在考虑使用从属关系，您应该查看有关注册新身份的主题以了解要求。要了解有关如何在 MSP 中使用从属关系的更多信息，请参阅有关组织单位 (OU) 和 MSP 的MSP 关键概念主题。
上面列出的默认从属关系会在服务器首次启动时添加到 Fabric CA 数据库中。如果你不想在你的服务器上有这些从属关系，你需要在你第一次启动服务器*之前编辑这个配置文件并删除或替换它们。*否则，您必须使用 Fabric CA 客户端从属关系命令来修改从属关系列表。默认情况下，不能从配置中删除从属关系，而是必须明确启用该功能。有关配置允许删除从属关系的能力的说明，请参阅cfg部分。
CSR(证书签名请求)
|
|
CSR 部分控制根 CA 证书的创建。因此，如果您想自定义任何值，建议您在首次启动服务器之前配置此部分。您在此处指定的值将包含在生成的签名证书中。如果在启动服务器后自定义CSR的值，则需要删除ca.cert文件和ca.key文件，然后重新运行fabric-ca-server start命令。
- csr.cn：此字段必须设置为 CA 引导身份的 ID，可以留空。它默认为 CA 服务器引导标识。
- csr.keyrequest：如果您想自定义加密算法和密钥大小，请使用这些值。
- csr.names：指定要用于证书颁发者的值，在签名证书中可见。
- csr.hosts：提供服务器将在其上运行的主机名。
- csr.expiry：指定此 CA 的根证书何时过期。默认值为
131400h=15 年。 - csr.pathlength：如果您将拥有中间 CA，请将此值设置为
1根 CA。如果这是一个中间 CA，则该值将是0，除非它将作为另一个中间 CA 的父 CA。
signing
|
|
本节中的默认值通常足以用于生产服务器。但是，您可能想要修改生成的组织 CA 和 TLS 证书的默认到期时间。请注意，这与CA 根证书csr部分中指定的expiry不同。
如果这是 TLS CA，建议您删除profiles:中该ca部分，因为 TLS CA 应该只颁发 TLS 证书。
如果您计划拥有多个级别的中间 CA，则必须在根 CA 的配置 .yaml 文件中设置maxpathlen为大于0。该字段表示证书链中可以跟在该证书之后的非自发中间证书的最大数量。例如，如果您计划在此根 CA 下拥有中间 CA，则可以将maxpathlen设置为0。但是，如果您希望您的中间 CA 充当另一个中间 CA 的父 CA，则maxpathlen应设置为1.
要执行maxpathlen为 0，您还需要设置maxpathlenzero为 true。如果maxpathlen大于0，maxpathlenzero则应设置为false。
bccsp
|
|
此部分中的信息控制 CA 私钥的存储位置。上面的配置导致私钥存储在msp/keystore文件夹中的 CA 服务器的文件系统中。如果您计划使用硬件安全模块 (HSM)，则配置会有所不同。当您为 CA 配置 HSM时，CA 私钥由 HSM 生成并存储在 HSM 而不是msp/keystore文件夹中。softHSM 的 HSM 配置示例类似于：
|
|
cors
|
|
跨源资源共享 (CORS) 可以配置为使用额外的 HTTP 标头来告诉浏览器让在一个源上运行的 Web 应用程序访问来自不同源的选定资源。该origins参数包含允许访问资源的域列表。
cfg
|
|
这两个参数未在示例配置文件中列出，但理解起来很重要。如果默认配置设置为 false，您将无法在不重新启动服务器的情况下删除从属关系或身份。如果您预计需要在不重新启动服务器的情况下从您的生产环境中删除从属关系或身份，则应在启动服务器之前设置这两个字段为true。请注意，在服务器启动后，只能使用 Fabric CA 客户端 CLI 命令修改从属关系和身份。
operations
|
|
操作服务可用于 CA 的健康监控，并依赖双向 TLS 与节点进行通信。因此，您需要设置operations.tls.clientAuthRequired为true. 设置为true时，尝试确定节点健康状况的客户端需要提供有效证书以进行身份验证。如果客户端不提供证书或服务无法验证客户端的证书，请求将被拒绝。这意味着客户端将需要向 TLS CA 注册并在请求中提供他们的 TLS 签名证书。
如果两个 CA 在同一台机器上运行，您需要修改listenAddress:第二个 CA 以使用不同的端口。否则，当您启动第二个 CA 时，它将无法启动，并报告.the bind address is already in use
metrics
|
|
如果您想监控 CA 的指标，请选择您的指标提供者：
- provider：
Statsd是推模型，Prometheus是拉模型。因为 Prometheus 是拉模型，所以 Fabric CA 服务器端不需要任何配置。相反，Prometheus 将请求发送到操作 URL 以轮询指标。可用指标。
下一步
决定您的 CA 配置后，您就可以部署您的 CA。按照下一个 CA 部署步骤主题中的说明启动您的 CA。
CA部署步骤
下载二进制文件
Fabric CA 服务器和 CA 客户端二进制文件可以从github下载。向下滚动到资产并为您的机器类型选择最新的二进制文件。.zip 文件包含 CA 服务器和 CA 客户端二进制文件。在您掌握了使用这些二进制文件部署和运行 CA 之后，您可能希望改用 Fabric CA 映像，例如在 Kubernetes 或 Docker 部署中。不过现在，本主题的目的是教您如何正确使用二进制文件。
服务器二进制文件
在本主题中，我们使用服务器二进制文件部署三种不同类型的 CA：TLS CA、组织 CA 和可选的中间 CA。TLS CA 颁发的证书可确保组织中所有节点之间的通信安全。组织 CA 颁发身份证书。如果您决定包括中间 CA，组织 CA 将充当中间 CA 的根 CA 或父服务器。如果您还没有，您应该查看有关规划 CA 的主题以了解每种类型的 CA 的用途及其差异。我们从不同的文件夹运行 TLS CA、组织 CA 和中间 CA。我们会将 CA 服务器二进制文件复制到每个文件夹。
客户端二进制文件
同样，我们会将 Fabric CA 客户端二进制文件复制到它自己的目录中。将 CA 客户端放在自己的文件夹中有助于证书管理，尤其是当您需要与多个 CA 交互时。当您从 CA 客户端向 CA 服务器发出命令时，您可以通过修改请求中的 CA 服务器 URL 来定位特定的 CA。因此，只需要一个 Fabric CA 客户端二进制文件，并可用于与多个 CA 进行交易。更多关于使用下面的 Fabric CA 客户端的信息。
Fabric客户端
在部署 Fabric CA 服务器之前，您需要了解 Fabric CA 客户端的作用。虽然您可以使用 Fabric SDK 与您的 CA 交互，但建议您使用 Fabric CA 客户端注册和注册节点管理员身份. 本主题中提供的说明假设正在使用单个 Fabric CA 客户端。注册身份或用户是将注册 ID 和密码添加到 CA 数据库“用户注册表”的过程。如果您将 LDAP 服务器用于您的用户注册表，那么不需要注册步骤，因为身份已经存在于 LDAP 数据库中。用户注册后，您可以使用 Fabric CA 客户端“注册”身份，这是生成身份需要作为组织的一部分进行交易的证书的过程。当您提交注册请求时，私钥和公钥首先由 Fabric CA 客户端在本地生成，然后将公钥发送到 CA，CA 返回经过编码的“签名证书”。
因为您将使用单个 CA 客户端向多个 CA 提交注册和注册请求，所以在使用 CA 客户端时证书管理至关重要。因此，最佳做法是为 CA 客户端将与之交互的每个 CA 服务器创建子文件夹，以存储生成的证书。
- 创建一个子文件夹以连接到每个 CA 服务器，例如
/tls-ca或/org1-ca或/int-ca。这个文件夹可以在 Fabric CA 客户端下，也可以在 CA 客户端可以访问路径的任何地方。出于这些说明的目的，这些文件夹位于fabric-ca-client目录中。例如：
|
|
- **提示：**虽然您可以从您喜欢的任何文件夹运行 Fabric CA 客户端二进制文件，但为了便于遵循这些说明，我们将在其自己的名为
fabric-ca-client. - 将 Fabric CA 客户端二进制文件复制到该
fabric-ca-client文件夹中。 - 由于在生产网络上启用了 TLS 通信，组织的 TLS CA 负责生成证书，以保护组织中所有节点之间的通信。因此，每次 Fabric CA 客户端与该组织中的 CA 服务器进行交易时，它都需要提供 TLS CA“根证书”以确保客户端-服务器通信的安全。例如，当 Fabric CA 客户端向 CA 服务器发出注册或登记请求时，客户端请求包括该根证书以执行 SSL 握手。在服务器配置 .yaml 文件中启用 TLS 后，会在 TLS CA 上生成名为
ca-cert.pem的 TLS CA 根证书。要为您的 CA 客户端启用 TLS 通信，您需要一个tls-root-cert用于存储根证书的子文件夹。在本主题的后面，我们会将根证书复制到此文件夹中。
|
|
生成的文件夹结构类似于：
|
|
**重要提示：**如果您的 Fabric CA 客户端将与来自多个受不同 TLS 服务器保护的组织的 CA 进行交易，那么您需要创建不同的文件夹tls-root-cert来保存每个组织的 TLS CA 根证书，或者简单地在文件夹中以不同的方式命名它们以区分它们。由于我们的 Fabric CA 客户端只会与同一组织中的 CA 服务器进行交易，所有这些服务器都由同一 TLS CA 保护，因此我们在此文件夹中只有一个根证书。
您可以在 CLI 命令中使用环境变量或标志来指定证书的位置和 Fabric CA 客户端二进制文件：
FABRIC_CA_CLIENT_HOME- 指定 Fabric CA 客户端二进制文件所在的完全限定路径。FABRIC_CA_CLIENT_TLS_CERTFILES- 指定 TLS CA 根证书的位置和名称。如果环境变量的路径FABRIC_CA_CLIENT_TLS_CERTFILES不是绝对路径，它将被解析为相对于FABRIC_CA_CLIENT_HOME指定的 Fabric CA 客户端主目录。在这些说明中，我们使用--tls.certfiles命令上的标志来指定 TLS CA 根证书的位置。FABRIC_CA_CLIENT_MSPDIR- 虽然您可以使用此环境变量来指定证书所在文件夹的名称，但由于客户端与多个 CA 通信，更好的选择是*在注册和注册命令上显式传递--mspdir标志以指定位置。*如果未在命令中指定，则默认位置$FABRIC_CA_CLIENT_HOME/msp将在 Fabric CA 客户端与组织中的多个 CA 服务器进行交易时出现问题。
**提示：**第一次从 CA 客户端发出enroll命令时，如果$FABRIC_CA_CLIENT_HOME目录中尚不存在fabric-ca-client-config.yaml，则会生成它。当您自定义此文件中的值时，它们会由 CA 客户端自动使用，并且不必在后续enroll命令的命令行上传递。
在这些说明中使用单个 Fabric CA 客户端与多个 CA 服务器交互，但不一定是必需的模式。另一种选择是为每个CA 服务器配备一个 Fabric CA 客户端。在这种情况下，当为 CA 服务器管理员发出初始注册命令时，将生成与服务器的 Fabric CA 客户端连接设置并将其存储在fabric-ca-client-config.yaml文件中。
从CLI提交交易
CA 服务器和 CA 客户端二进制文件包含两组 CLI 命令：
- 使用Fabric CA服务器CLI 命令部署和更新 CA 服务器。
- 使用Fabric CA客户端CLI 命令在设置后向您的 CA 服务器提交请求，例如注册、登记或撤销身份。
我们将在整个主题中使用这两个 CLI 命令。
部署CA的顺序
假设您没有部署同时包含 TLS CA 和组织 CA 的双头 CA，您将按以下顺序部署 CA：
-
部署 TLS CA
由于生产网络中需要 TLS 通信，因此必须在每个 CA、对等节点和排序节点上启用 TLS。虽然 CA 操作指南中的示例配置在所有组织之间共享一个 TLS CA，但建议的生产配置是为每个组织部署一个 TLS CA。TLS CA 颁发 TLS 证书，以保护网络上所有节点之间的通信。因此需要先部署它，为节点间发生的TLS握手生成TLS证书。
-
部署组织 CA
这是组织的身份注册 CA，用于注册和注册将从此组织参与网络的身份。
-
部署中间 CA（可选）
如果您决定在您的网络中包括中间 CA，则中间 CA 的父服务器（关联的根 CA）必须在任何中间 CA 之前部署。
部署TLS CA
无论您是要设置 TLS CA、组织 CA 还是中间 CA，该过程都遵循相同的总体步骤。不同之处在于您对 CA 服务器配置 .yaml 文件所做的修改。以下步骤概述了该过程：
当您部署任何节点时，您可以为 TLS 配置提供三个选项：
- 没有 TLS。不推荐用于生产网络。
- 服务器端 TLS。
- 双向 TLS。
此过程将配置启用了服务器端 TLS 的 CA，建议用于生产网络。默认情况下禁用双向 TLS。如果需要使用双向 TLS，请参考TLS 配置设置。
开始之前
您应该已经下载 Fabric CA 服务器二进制文件并将其复制fabric-ca-server到计算机上的一个干净目录中。出于这些说明的目的，我们将二进制文件放在其自己的文件夹中，名为fabric-ca-server-tls.
|
|
将二进制文件fabric-ca-server复制到此文件夹中。
初始化 TLS CA 服务器
部署 CA 服务器的第一步是“初始化”它。运行以下 CA 服务器 CLI 命令以通过指定 CA 的管理员用户 ID 和密码来初始化服务器：
|
|
例如：
|
|
-b( bootstrap identity) 标志将管理员用户名和密码引导到 CA 服务器，这会有效地为您向服务器“注册”CA 管理员用户，因此引导用户不需要显式的 Fabric CA 客户端 CLI 命令register。所有 CA 用户都需要“注册”，然后“注册”到 CA，除了这个 CA 管理员身份，它是通过使用-b标志隐式注册的。注册过程将用户插入 CA 数据库。当配置 LDAP 时，初始化不需要-b选项。
**注意：此示例仅用于说明目的。显然，在生产环境中，您永远不会使用tls-admin和tls-adminpw作为引导用户名和密码。**请务必记录您指定的管理员 ID 和密码。稍后当您对 CA 发出注册和注册命令时需要它们。它可以帮助使用有意义的 ID 来区分您正在与之交易的服务器并遵循安全密码实践。
CA 服务器init命令有什么作用
该init命令实际上并不启动服务器，但会生成所需的元数据（如果服务器尚不存在）：
- 将默认的 CA 主目录（在这些说明中称为
FABRIC_CA_HOME）设置为运行fabric-ca-server init命令的位置。 fabric-ca-server-config.yaml生成用作FABRIC_CA_HOME目录中服务器配置模板的默认配置文件。在这些说明中，我们将此文件称为“配置 .yaml”文件。- 如果 CA 主目录中尚不存在TLS CA 根签名证书文件，则创建
ca-cert.pem文件。这是自签名的根证书，这意味着它是由 TLS CA 本身生成和签名的，而不是来自其他来源。该证书是必须与所有想要与组织中的任何节点进行交易的客户端共享的公钥。当任何客户端或节点向另一个节点提交交易时，它必须将此证书作为交易的一部分。 - 生成 CA 服务器私钥并将其存储在
/msp/keystore下FABRIC_CA_HOME文件夹. - 为服务器初始化一个默认的 SQLite 数据库，尽管您可以修改配置 .yaml 文件中的数据库设置以使用您选择的支持的数据库。每次启动服务器时，它都会从该数据库加载数据。如果您稍后切换到不同的数据库，例如 PostgreSQL 或 MySQL，并且配置 .yaml 文件
registry.identites部分中定义的身份在该数据库中不存在，它们将被注册。 - 通过
-b标志参数<ADMIN_USER>和<ADMIN_PWD>引导CA 服务器管理员的指定服务器 。当 CA 服务器随后启动时，admin 用户将使用配置 .yaml 文件registry部分中提供的 admin 属性进行注册。如果此 CA 将用于注册具有任何这些属性的其他用户，则 CA 管理员用户需要拥有这些属性。换句话说，注册商必须先拥有hf.Registrar.Roles属性，然后才能使用这些属性中的任何一个注册另一个身份。因此，如果此 CA 管理员将用于为中间 CA 注册管理员身份，则此 CA 管理员必须设置hf.IntermediateCA为true即使这可能不是中间 CA 服务器。默认设置已包含这些属性。
重要提示：当您修改配置 .yaml 文件中的设置并重新启动服务器时，不会替换之前颁发的证书。如果希望在服务器启动时重新生成证书，则需要删除它们并运行fabric-ca-server start命令。例如，如果在启动服务器后修改csr值，则需要删除之前生成的证书，然后再运行fabric-ca-server start命令。但是请注意，当您使用新的签名证书和私钥重新启动 CA 服务器时，所有以前颁发的证书将无法再通过 CA 进行身份验证。
修改 TLS CA 服务器配置
现在您已经初始化了您的服务器，您可以编辑生成的fabric-ca-server-config.yaml文件以根据生产 CA 服务器的清单修改您的用例的默认配置设置。
您至少应该执行以下操作：
port- 输入要用于此服务器的端口。这些说明使用7054，但您可以选择您的端口。tls.enabled- 回想一下，默认配置文件中禁用了 TLS。由于这是生产服务器，因此通过将此值设置为true来启用它。将此值设置为true会导致在下一步启动服务器时生成TLS 签名证书文件tls-cert.pem。这tls-cert.pem是服务器将在 TLS 握手期间提供给客户端的证书，然后客户端将使用 TLS CA 的ca-cert.pem.ca.name- 通过编辑参数为 CA 命名，例如tls-ca.csr.hosts- 更新此参数以包括此服务器运行的主机名和 ip 地址，如果它与此文件中已有的不同。在下一步启动服务器时，当服务器创建其自签名 TLS 证书 tls-cert.pem 时，主机名将用于指定主题备用名称。signing.profiles.ca- 由于这是一个不会颁发 CA 证书的 TLS CA，因此ca可以删除配置文件部分。该signing.profiles块应仅包含tls配置文件。operations.listenAddress:- 万一有另一个节点在此主机和端口上运行，则需要更新此参数以使用不同的端口。
删除 TLS CA 服务器证书
在启动服务器之前，如果您修改了配置 .yaml 文件csr块中的任何值，则需要删除该fabric-ca-server-tls/ca-cert.pem文件和整个fabric-ca-server-tls/msp文件夹。当您在下一步中启动 CA 服务器时，将重新生成这些证书。
启动 TLS CA 服务器
运行以下命令启动 CA 服务器：
|
|
服务器成功启动后，您将看到类似以下内容：
|
|
因为您已启用 TLS 通信但未指定 TLS 证书文件，请注意在FABRIC_CA_HOME位置下生成了 TLS 签名证书文件tls-cert.pem。
**提示：**不能用start命令上的-b标志覆盖在init命令上设置的CAADMIN_USER和ADMIN_PWD。当您需要修改 CA 管理员密码时，请使用 Fabric CA 客户端身份命令。
可选标志：
-d- 如果您想在有助于问题诊断的 DEBUG 模式下运行服务器，您可以在启动命令中包含-d标志。但是，通常不建议在启用调试的情况下运行服务器，因为这会导致服务器执行速度变慢。-p- 如果您希望服务器在与配置 .yaml 文件中指定的端口不同的端口上运行，您可以覆盖现有端口。
使用 TLS CA 注册引导管理员身份
现在您的 TLS CA 已配置，在您可以为您的组织部署任何其他节点之前，您需要注册 TLS CA 的引导管理员身份。由于 CA 服务器已启动并正在运行，我们现在使用Fabric CA 客户端 CLI 命令来向 TLS CA 服务器提交注册请求，而不是使用Fabric CA 服务器 CLI 命令。
通过使用 Fabric CA 客户端执行，注册过程用于生成构成 TLS CA 引导管理员身份的证书和私钥对。您应该已经在Fabric CA 客户端部分设置了所需的文件夹。
我们用于这些 Fabric CA 客户端命令的文件夹结构是：
|
|
Fabric CA 客户端使用这些文件夹来：
- 存储在针对 TLS CA 服务器运行 Fabric CA 客户端注册命令以注册 TLS CA 引导管理员身份时颁发的证书。（tls-ca文件夹）
- 了解允许 Fabric CA 客户端与 TLS CA 服务器通信的 TLS CA 根证书所在的位置。（tls-root-cert文件夹）
- 将启动 TLS CA 服务器时生成的TLS CA 根证书文件
fabric-ca-server-tls/ca-cert.pem复制到该fabric-ca-client/tls-root-cert/tls-ca-cert.pem文件夹。请注意，文件名更改为tls-ca-cert.pem以明确这是来自 TLS CA 的根证书。**重要提示：**此 TLS CA 根证书将需要在将针对 TLS CA 运行命令的每个客户端系统上可用。 - Fabric CA 客户端还需要知道 Fabric CA 客户端二进制文件的位置。环境
FABRIC_CA_CLIENT_HOME变量用于设置位置。
|
|
例如，如果您在fabric-ca-client文件夹中，您可以使用：
|
|
- 您已准备好使用 Fabric CA 客户端 CLI 来注册 TLS CA 引导管理员身份。运行命令：
|
|
代替：
<ADMIN>- 使用在init命令中指定 TLS CA 管理员。<ADMIN-PWD>- 使用在init命令中指定 TLS CA 管理员密码。<CA-URL>- 使用TLS CA 配置 .yaml 文件csr部分中指定的主机名。<PORT>- 使用 TLS CA 正在侦听的端口。<RELATIVE-PATH-TO-TLS-CERT>- 使用您从 TLS CA 复制的根 TLS 证书文件的路径和名称。此路径是相对于FABRIC_CA_CLIENT_HOME. 如果您遵循本教程中的文件夹结构，它将是tls-root-cert/tls-ca-cert.pem.
例如：
|
|
在这种情况下，该-d参数以 DEBUG 模式运行客户端，这对于调试注册失败很有用。
请注意，该--mspdir标志在命令中用于指定存储 enroll 命令生成的 TLS CA 管理员证书的位置。
指定--enrollment.profile tls标志是因为我们正在针对 TLS CA 进行注册。使用此标志意味着注册是根据配置 .yaml 文件signing部分中定义的 TLS 配置文件的usage和expiry设置执行的。**注意：**如果您从 TLS CA 配置 .yaml 文件中删除了signing.profiles.ca块，则可以省略--enrollment.profile tls标志。
此命令成功完成后，将生成fabric-ca-client/tls-ca/tlsadmin/msp文件夹，其中包含 TLS CA 引导管理员身份的签名证书和私钥。如果注册命令由于某种原因失败，为避免以后混淆，您应该在重新尝试注册命令之前从fabric-ca-client/tls-ca/admin/msp/keystore文件夹中删除生成的私钥。当需要向 TLS CA 注册其他身份时，我们将在稍后引用此加密材料。
**提示：**从 Fabric CA 客户端发出第一个enroll命令后，检查生成的fabric-ca-client/fabric-ca-client-config.yaml文件的内容以熟悉 Fabric CA 客户端使用的默认设置。因为我们使用单个 Fabric CA 客户端与多个 CA 服务器交互，所以我们需要使用客户端 CLI 命令上的-u标志来定位正确的 CA 服务器。结合起来，该--mspdir标志指示要在register命令上使用的加密材料的位置或在enroll命令上存储生成的证书的位置。
下图是您创建 TLS CA 服务器并使用 Fabric CA 客户端注册引导管理员身份所执行的步骤的概念性摘要：
向 TLS CA 注册并注册组织 CA 引导身份
TLS CA 服务器以引导管理员身份 (tlsadmin) 启动，该身份具有服务器的完全管理员权限。管理员的一项关键能力是注册新身份的能力。组织中将在网络上进行交易的每个节点（orderers, peers、组织 CA）都需要向 TLS CA 注册，以便每个节点都可以注册以获取其 TLS 证书。因此，在我们设置组织CA之前，我们需要使用TLS CA来注册并注册组织CA引导身份以获取其TLS证书和私钥。组织 CA 引导管理员用户将在下一步中被rcaadmin命名，因此我们将使用相同的名称为组织 CA 生成 TLS 身份。以下命令注册组织 CA 引导身份rcaadmin使用TLS CA 的rcaadminpw密码。
|
|
请注意，--mspdir命令上的标志指向我们在上一步中生成的 TLS CA 管理 msp 证书的位置。需要此加密材料才能向 TLS CA 注册节点。
接下来，我们需要将rcaadmin身份注册到 TLS CA，以便为组织 CA 服务器生成 TLS 证书。在这种情况下，我们使用enroll 命令上的--mspdir标志来指定应为rcaadmin身份存储生成的组织 CA TLS 证书的位置。因为这些证书用于不同的身份，所以最好将它们放在自己的文件夹中。因此，我们不会在默认msp文件夹中生成它们，而是将它们放在一个名为的新文件夹rcaadmin中，该文件夹位于该tlsadmin文件夹旁边。另请注意，因为我们正在生成 TLS 证书，所以我们必须通过--csr.hosts在生成的 TLS 证书中指定主题备用名称。主机必须匹配客户端在与组织 CA 服务器通信时将使用的主机名，以便 TLS 握手成功。
|
|
在这种情况下，--mspdir标志的工作方式略有不同。对于 enroll 命令，--mspdir标志指示在哪里存储为rcaadmin身份生成的 TLS 证书。
**重要提示：**组织 CA TLS 签名证书是在fabric-ca-client/tls-ca/rcaadmin/msp/signcert下生成的，私钥在fabric-ca-client/tls-ca/rcaadmin/msp/keystore下可用。在下一步部署组织 CA 时，您需要将这些文件复制到组织 CA 目录下，并在组织 CA 配置 .yaml 文件的tls部分引用它们。为了便于参考，您可以将文件夹中的文件重命名keystore为key.pem.
(可选）向 TLS CA 注册并注册中间 CA 管理员
同样，如果您计划拥有一个可以代表组织 CA 颁发证书的中间 CA，您现在也应该注册并登记中间 CA 管理员用户。以下命令注册中间 CA 管理员 IDicaadmin和icaadminpw并向TLS CA注册。您可以使用您为身份名称和密码选择的任何值。
|
|
同样，register 命令上的--mspdir标志指向 TLS CA admin msp 证书的位置，这些证书需要能够向 TLS CA 注册其他用户。
现在也是通过注册用户为icaadmin用户生成中间 CA TLS 证书的好时机。对于 enroll 命令，我们使用--mspdir标志来指定应为icaadmin用户存储生成的中间 CA TLS 证书的位置。在这种情况下，我们将它们放入一个与tlsadmin文件夹一起命名的新文件夹icaadmin/msp中。
|
|
**重要提示：**中间 CA TLS 签名证书在fabric-ca-client/tls-ca/icaadmin/signcert下生成，私钥在fabric-ca-client/tls-ca/icaadmin/keystore下可用。当您部署中间 CA 时，您需要在中间 CA 配置 .yaml 文件的tls部分中参考这两个文件。为了便于参考，您可以将文件夹中的文件重命名keystore为key.pem.
生成的文件夹结构类似于：
|
|
**提示：**在您向 TLS CA 注册所有节点后，可以安全地关闭它。
部署组织CA
部署过程概述描述了每个组织对组织 CA 和 TLS CA 的需求。TLS CA 颁发允许在组织内进行安全交易的 TLS 证书。组织 CA，也称为“注册 CA”或“eCert CA”，用于为组织颁发身份。您在前面的一组步骤中部署了 TLS CA，现在我们已准备好部署组织 CA。在本主题的后面，您可以选择创建一个中间 CA；因此，此 CA 充当该信任链中的“根 CA”。
因为您已经在上一步中使用 TLS CA 注册并注册了您的组织 CA 引导程序身份rcaadmin，所以您已经拥有组织 CA 的 TLS 证书，并且您已准备好按照所使用的相同步骤模式部署组织 CA当您部署 TLS CA 时。
在你开始之前
- 将 Fabric CA 服务器二进制文件
fabric-ca-server复制到您机器上的一个新目录。出于这些说明的目的，我们将二进制文件放在其自己的文件夹中，名为fabric-ca-server-org1.
|
|
现在，将fabric-ca-server二进制文件复制到此文件夹中。
-
使用以下命令，将您在上一步中生成的组织 CA TLS 证书和密钥对复制到此 CA 服务器可以访问的位置，例如
fabric-ca-server-org1/tls。这些是由 enroll 命令生成的fabric-ca-client/tls-ca/rcaadmin/msp/signcerts/cert.pem和fabric-ca-client/tls-ca/rcaadmin/msp/keystore/文件。**注意：**以下命令假定：
fabric-ca-client/tls-ca/rcaadmin/msp/keystore/下生成的私钥重命名为key.pem.fabric-ca-client和fabric-ca-server-org1文件夹在您的文件结构中处于同一级别。
|
|
生成的文件夹结构类似于下图。（为清楚起见，省略了一些文件夹和文件）：
|
|
初始化 CA 服务器
运行命令以初始化服务器，为 CA 指定新的管理员用户 ID 和密码。我们使用在前一组步骤中向 TLS CA 注册的同一身份rcaadmin作为组织 CA 的引导程序身份。从fabric-ca-server-org1文件夹运行此命令。
|
|
例如：
|
|
修改CA服务器配置
正如我们对 TLS CA 所做的那样，我们需要编辑为组织 CA 生成的fabric-ca-server-config.yaml文件，以根据生产 CA 服务器的清单修改您的用例的默认配置设置。
您至少应该编辑以下字段：
port- 输入要用于此服务器的端口。这些说明使用7055，但您可以选择您的端口。tls.enabled- 通过将此值设置为true启用 TLS 。tls.certfile和tls.keystore- 输入 TLS CA 签名证书和私钥的相对路径和文件名，这些证书和私钥是在该 CA 的引导管理员注册到 TLS CA 时生成的。签名证书cert.pem是使用 Fabric CA 客户端生成的，可以在fabric-ca-client/tls-ca/rcaadmin/msp/signcerts/cert.pem下找到。私钥位于fabric-ca-client/tls-ca/rcaadmin/msp/keystore. 指定的路径名是相对于FABRIC_CA_CLIENT_HOME的，因此如果您遵循这些说明中使用的文件夹结构，您可以简单地为tls.certfile和tls/key.pem指定tls/cert.pem对于tls.keystore，或者您可以指定完全限定的路径名。ca.name- 通过在此参数中指定一个值来为组织 CA 命名，例如org1-ca。csr.hosts- 通常这个参数应该是这个服务器运行的主机名和 ip 地址，这样它就可以被注入到 TLS 证书主题备用名称中，但是在这种情况下，服务器不会生成自己的 TLS 证书（它已经从TLS CA)，因此不需要配置。csr.ca.pathlength：此字段用于限制 CA 证书层次结构。对于根 CA将此值设置为1意味着根 CA 可以颁发中间 CA 证书，但这些中间 CA 不能依次颁发其他CA证书。换句话说，中间 CA 不能注册其他中间 CA，但它可以为用户签发注册证书。默认值为1。signing.profiles.ca.caconstraint.maxpathlen- 该字段表示证书链中可以跟在该证书之后的非自发中间证书的最大数量。**如果这将是中间 CA 的父服务器，并且您希望该中间 CA 充当另一个中间 CA 的父 CA，则此根 CA 需要在配置 .yaml 文件中将此值设置为大于 0。**请参阅签名部分的说明。默认值为0。operations.listenAddress:- 如果有另一个 CA 在此主机上运行，则需要更新此参数以使用不同的端口。
删除 CA 服务器证书
在启动服务器之前，如果您修改了配置 .yaml 文件csr块中的任何值，则需要删除该fabric-ca-server-org1/ca-cert.pem文件和整个fabric-ca-server-org1/msp文件夹。当您在下一步启动 CA 服务器时，将根据配置 .yaml 文件中的新设置重新生成这些证书。
启动 CA 服务器
运行以下命令启动 CA 服务器：
|
|
注册 CA 管理员
部署 CA 的最后一步是注册 CA 管理员引导身份（rcaadmin 用户）。这将生成 rcaadmin 用户的签名证书和私钥。需要密钥对，以便 rcaadmin 用户随后可以在组织中注册和注册其他身份。我们将再次使用 Fabric CA 客户端 CLI 来注册管理员。您应该已经在Fabric CA 客户端部分设置了所需的文件夹。
我们用于这些命令的文件夹结构是：
|
|
Fabric CA 客户端使用这些文件夹来：
- 存储在针对组织 CA 服务器运行 Fabric CA 客户端注册命令时颁发的证书。（org1-ca文件夹）
- 了解允许 Fabric CA 客户端与 TLS CA 服务器通信的 TLS 证书所在的位置。（tls-root-cert文件夹）
- 当您之前使用 Fabric CA 客户端为 TLS CA 生成证书时，您指定了
FABRIC_CA_CLIENT_HOME. 假设仍然设置，您可以继续下一步。否则，您应该在 Fabric CA 客户端二进制文件所在的目录中运行命令：
|
|
- 现在您可以使用 Fabric CA 客户端生成 CA 管理员证书和私钥。您需要此证书和私钥才能使用此 CA 颁发身份。我们使用enroll 命令上的
--mspdir标志来指定存储生成的证书的位置。运行命令：
|
|
代替：
<ADMIN>- 使用在init命令中指定的组织 CA 管理员。<ADMIN-PWD>- 使用在init命令中指定的组织 CA 管理员密码。<CA-URL>- 使用组织 CA 的主机名。<PORT>- 使用组织 CA 正在侦听的端口。<RELATIVE-PATH-TO-TLS-CERT>- 使用您从 TLS CA 复制的 tls-ca-cert.pem 文件的路径。这是相对于FABRIC_CA_CLIENT_HOME的路径。
在这种情况下，-d参数以 DEBUG 模式运行客户端，这对于调试命令失败很有用。
例如：
|
|
当此命令运行时，注册命令会创建fabric-ca-client/org1-ca/rcaadmin/msp文件夹并包含组织 CA 的签名证书和私钥，看起来类似于：
|
|
在哪里：
my-machine-example-com-7055.pem是组织 CA 根证书。60b6a16b8b5ba3fc3113c522cce86a724d7eb92d6c3961cfd9afbd27bf11c37f_sk是组织 CA 管理员身份的**私钥。**此密钥需要受到保护，不应与任何人共享。需要能够向该 CA 注册和注册其他身份。请随意将此文件重命名为更容易引用的名称，例如org1-key.pem.cert.pem是 CA 管理员身份签名的证书。
- （可选）向组织（根）CA 注册中间 CA 引导身份。
如果您计划部署中间 CA，则必须向其根 CA 注册中间 CA 引导身份以形成信任链。回想一下，您已经向 TLS CA 注册了身份icaadmin。您还需要向（根）组织 CA 注册相同的身份。因为这将是一个中间 CA，所以您必须包含该hf.IntermediateCA=true属性。（从您在上一步中注册组织 CA 管理员的同一终端窗口运行此命令。）
|
|
register 命令上的标志--mspdir指向我们在上一步中注册并有权注册新用户的组织 CA 管理员的加密材料。我们不向组织 CA 注册icaadmin身份。而是稍后针对中间 CA 注册此中间 CA 管理员身份。
部署中间CA(可选)
中间 CA 与组织根 CA 形成信任链，可用于将特定组织的注册请求定向到单个 CA，并通过关闭根 CA 来保护信任根。因此，当中间 CA 用于处理所有注册请求时，可以关闭根 CA。
**注意：**本部分假定您已经在 TLS CA 以及父组织 CA 中注册并登记了身份icaadmin（本部分之前的第 3 步）。
在你开始之前
- 将 Fabric CA 服务器二进制文件
fabric-ca-server复制到您机器上的一个新目录。出于这些说明的目的，我们将二进制文件放在其自己的文件夹中，名为fabric-ca-server-int-ca.
|
|
将二进制文件fabric-ca-server复制到此文件夹中。
-
使用以下命令将您在上一步中生成的 CA admin TLS 证书和密钥对复制到此 CA 服务器可以访问的位置，例如
fabric-ca-server-int-ca/tls。这些是由 enroll 命令生成的fabric-ca-client/tls-ca/icaadmin/msp/signcerts/cert.pem和fabric-ca-client/tls-ca/icaadmin/msp/keystore/文件。**注意：**以下命令假定：
fabric-ca-client/tls-ca/icaadmin/keystore/下生成的私钥重命名为key.pem.fabric-ca-client和fabric-ca-server-int-ca文件夹在您的文件结构中处于同一级别。
|
|
-
由于启用了 TLS 通信，中间 CA 需要 TLS CA 根证书才能与父组织 CA 安全通信。因此，需要将TLS CA服务器初始化时生成的
fabric-ca-server-tls/ca-cert.pem文件复制到该tls文件夹中。请注意，文件名更改为tls-ca-cert.pem以明确这是来自 TLS CA 的根证书。1cp ../fabric-ca-server-tls/ca-cert.pem tls/tls-ca-cert.pem
生成的文件夹结构类似于以下结构。（为清楚起见，省略了一些文件夹和文件）：
|
|
因为您已经部署了父组织（根）CA，所以您可以使用以下步骤创建中间 CA：
- 在中间 CA 主目录中，通过运行
init命令并引导您已向 TLS CA 和父组织 CA 注册的icaadminID来初始化 CA。例如：
|
|
- 修改
fabric-ca-server-config.yaml文件。
port：为此服务器指定一个唯一的端口。这些说明使用7056，但您可以选择您的端口。tls.enabled: 必须设置为true。tls.certfile和tls.keystore：输入 TLS CA 签名证书和私钥的路径和文件名。这些是您在 TLS CA注册icaadmin用户时创建的证书和私钥文件。签名的证书，cert.pem可以在fabric-ca-client/tls-ca/icaadmin/msp/signcerts/cert.pem下找到。私钥位于fabric-ca-client/tls-ca/icaadmin/msp/keystore. 指定的路径名是相对于FABRIC_CA_CLIENT_HOME的，因此如果您遵循这些说明中使用的文件夹结构，您可以简单地为tls/cert.pem和tls.certfile指定tls/key.pem为tls.keystore，或者您可以指定完全限定的路径名。ca: 为 ca 指定一个名称。例如ica。signing.profiles.ca.caconstraint.maxpathlen: 将此值设置为 0，表示此下不再有中间 CA。默认值为0。csr.cn: 中间 CA 的公共名称必须为空。csr.ca.pathlength：将此值设置为 0。intermediate.parentserver.url：输入父服务器URL的值，格式https://<ROOT-CA-ADMIN>:<ROOT-CA-ADMIN-PW>@<CA-URL>:<PORT>如https://rcaadmin:rcaadminpw@my-machine.example.com:7055。intermediate.parentserver.caname``caname：输入父组织CA服务器配置.yaml文件中父服务器的值。在本教程中，我们将该 CA 命名为org1-ca.intermediate.enrollment.hosts：输入中间 CA 服务器正在侦听的主机名。intermediate.enrollment.profile：输入签名配置文件的名称，signing.profile以在颁发证书时使用。通常这个值为ca.intermediate.tls.certfiles：输入 TLS CA 根文件的路径和文件名tls-ca-cert.pem。如果您遵循这些说明中使用的文件夹结构，您只需指定tls/tls-ca-cert.pem.operations.listenAddress：如果另一个 CA 在同一主机上运行，您需要指定一个唯一的端口。
-
**重要提示：**您必须删除中间 CA
fabric-ca-server-int-ca/ca-cert.pem和fabric-ca-server-int-ca/msp文件夹，以便使用中间 CA 设置重新生成它们。 -
启动中间 CA 服务器。因为中间 CA 引导身份在服务器启动时注册到父组织（根）CA，所以在启动中间 CA 之前确保父组织 CA 正在运行。
|
|
由于这是一个中间 CA 服务器，请注意生成了一个ca-chain.pem文件。该文件包含证书链，包括中间 CAca-cert.pem和根CAca-cert.pem。
注册中级 CA 管理员
部署中间 CA 的最后一步是注册中间 CA 管理员以生成节点签名证书和私钥，这是该身份能够注册其他身份所必需的。您应该已经在Fabric CA 客户端部分设置了所需的文件夹。
我们用于这些命令的文件夹结构是
|
|
Fabric CA 客户端使用这些文件夹来：
- 存储在针对 TLS CA 服务器运行 Fabric CA 客户端注册命令时颁发的证书。（int-ca文件夹）
- 了解允许 Fabric CA 客户端与 TLS CA 服务器通信的 TLS 证书所在的位置。（tls-root-cert文件夹）
- 当您之前使用 Fabric CA 客户端为 TLS CA 和组织 CA 生成证书时，您指定了
FABRIC_CA_CLIENT_HOME. 假设仍然设置，您可以继续下一步。否则，您应该在 Fabric CA 客户端二进制文件所在的目录中运行命令：
|
|
- 现在您可以使用 Fabric CA 客户端生成 CA 管理员证书和私钥。您需要此证书和私钥才能使用此 CA 颁发身份。我们使用enroll 命令上的
--mspdir标志来指定存储生成的证书的位置。运行命令：
|
|
代替：
<ADMIN>- 使用在init命令中指定的中间 CA 管理员。<ADMIN-PWD>- 使用在init命令中指定的中间 CA 管理员密码。<CA-URL>- 使用中间 CA 配置 .yaml 文件csr部分中指定的主机名。<PORT>- 使用中间 CA 正在侦听的端口。<RELATIVE-PATH-TO-TLS-CERT>- 使用您从 TLS CA 复制的 tls-ca-cert.pem 文件的路径。这是相对于FABRIC_CA_CLIENT_HOME的路径。<CA_HOSTNAME>- 以逗号分隔的主机名列表，证书应该对其有效。如果未指定，则使用fabric-ca-client-config.yaml中的默认值。如果主机名是动态的，您可以为域指定一个通配符。例如，当您包含--csr.hosts 'host1,*.example.com'标志时，这意味着主机名host1以及example.com域中的任何主机都被识别。
例如：
|
|
当注册命令运行时，它会创建fabric-ca-client/int-ca/icaadmin/msp文件夹并包含中间 CA 的签名证书和私钥。请注意，还会创建/intermediatecerts文件夹并使用将此中间 CA 连接到根 CA 的中间 CA 证书进行填充。
**提示：**在中间 CA 成功部署并且您可以注册和注册身份后，您可以安全地关闭父服务器根 CA，即组织 CA。
下一步
至少，您现在应该为您的组织配置了一个 TLS CA 和一个组织 CA。您现在可以使用 Fabric CA 客户端向 TLS CA 注册和注册节点管理员身份、节点身份和组织身份，以生成服务器端 TLS 通信所需的 TLS 证书。同样，您还需要向组织 CA 注册和注册相同的节点管理员和用户，以生成他们的注册证书和 MSP。有关详细信息，请参阅使用 CA 创建身份和 MSP 。如果您确实配置了中间 CA，您现在可以使用该 CA 代替根 CA 为组织注册和登记身份。
**提示：**当您随后使用 Fabric CA 客户端向中间 CA 注册身份时，请确保您指定--mspdir int-ca/icaadmin/msp命令。
CA部署故障排除
Fabric CA 客户端enroll命令失败
**问题：**当使用 Fabric CA 客户端 CLI 运行注册命令时，它失败并显示：
|
|
解决方案:
FABRIC_CA_CLIENT_HOME未设置时会发生此错误。确保您已将FABRIC_CA_CLIENT_HOME环境变量设置为指向 Fabric CA 客户端二进制文件的位置。导航到二进制文件所在的文件夹fabric-ca-client.exe并运行命令：
|
|
请注意，当FABRIC_CA_CLIENT_HOME设置并且注册命令失败时，建议在重新尝试注册命令之前删除生成的FABRIC_CA_CLIENT_HOME/msp文件夹和生成的fabric-ca-client.yaml文件以避免混淆。
中间 CA 服务器启动失败
**问题：**中间 CA 服务器无法启动并出现以下错误：
|
|
您可能还会在根 CA 上看到相关的错误：
|
|
**解决方案：**需要将中间CA配置.yaml文件中的signing.profiles.ca.caconstraint.maxpathlen和csr.ca.pathlength字段的值设置为0。
启动中间 CA 失败
**问题：**当您启动中间 CA 时，它失败并出现错误：
|
|
而根组织 CA，有错误：
|
|
**解决方案：**此问题发生在中间 CA 服务器启动时向根 CA 注册中间 CA 管理员用户的过程中。要解决此问题，请确保中间 CA fabric-ca-server-config.yaml文件intermediate.tls.certfiles部分中指定的 TLS 证书指向 TLS CA 根证书。如果您遵循这些说明，它将是tls/tls-ca-cert.pem。
注册中间 CA 管理员用户失败
**问题：**当您启动中间 CA 并且进程失败并出现以下错误时：
|
|
解决方案：
因为修改了中间CA配置文件的csr区块，所以在启动中间CA服务器之前需要删除中间CA、ca-cert.pem文件和/msp文件夹。
向CA注册和登记身份
听众：组织管理员、节点管理员
如果您阅读了我们关于身份和成员服务提供商 (MSP)的主题，您就会知道在 Hyperledger Fabric 中，证书颁发机构用于生成分配给管理员、节点和用户（客户端应用程序）的身份。虽然任何可以生成 x.509 证书的证书颁发机构都可用于创建构成身份的公钥/私钥对，但 Fabric CA 还可以生成 Hyperledger Fabric 所需的本地和组织 MSP 文件夹结构。
在本主题中，我们将展示使用 Fabric CA 生成身份和 MSP 的“快乐路径”。请注意，您不必使用 Fabric CA 来注册和登记身份。但是，如果您使用不同的 CA，您将需要创建 Fabric 用于构建组织、客户端身份和节点的相关身份和 MSP。我们将在下面展示这些 MSP 的示例。
登记注册概述
虽然 CA 的管理员可以创建身份并将公钥/私钥对提供给带外用户，但此过程将使 CA 管理员可以访问每个用户的私钥。这种安排违反了关于私钥安全的基本安全程序，私钥不应以任何理由公开。
因此，CA 管理员注册用户，在这个过程中，CA 管理员为身份提供注册 ID 和密码（类似于用户名和密码），并为其分配角色和任何必需的属性。CA 管理员然后将此注册 ID 和秘密提供给身份的最终用户。然后，用户可以使用此注册 ID 和密码执行 Fabric CA 客户端注册命令，返回包含 CA 管理员分配的角色和属性的公钥/私钥对。
此过程保留了 CA 的完整性（因为只有 CA 管理员可以注册用户并分配角色和从属关系）和私钥（因为只有身份的用户才能访问它们）。
**虽然管理员身份只需要注册并注册到为管理员和节点生成身份证书的“组织 CA”，但节点也必须注册并注册到 TLS CA。这将创建一个公共/私人 TLS 密钥对，节点使用该密钥对它们的通信进行签名和加密。**如果仅使用“TLS”配置文件创建了 TLS CA，则向组织 CA 注册和注册身份的命令与向 TLS CA 注册和注册的命令相同。如果您使用的 CA 包含这两个配置文件，则在与 CA 通信时必须指定 TLS 配置文件。有关创建只能用作 TLS CA 的 CA 的更多信息，请查看CA 部署指南。
开始之前
在本教程中，我们将假设已使用 CA 设置说明配置和设置 CA 服务器。我们还将展示在注册身份registrar（由 CA 管理员或具有 CA权限的身份处理的任务）和“登记”身份（由身份用户处理的任务）时使用的命令和变量。
在任何一种情况下，fabric-ca-client都必须设置 ，因为它用于调用注册和注册身份的 CA 服务器。如果您在生产环境中操作，您应该启用 TLS，并且需要提供 TLS 证书以保护您与 CA 的通信。TLS 证书将需要来自您启动的 TLS CA 以及用于为节点、管理员和客户端生成身份的“组织”CA，并且此 TLS CA 与您将用于生成证书的 CA 相同（因为节点使用 TLS 相互通信）。
确定文件夹和证书的结构
无论您是在测试环境还是生产环境中运行，保持一致和连贯的结构来管理文件夹和证书至关重要。虽然在任何地方都使用相同的模式并不是严格的 Fabric 必要性（只要您在引用它们时路径是正确的，例如在引导节点时，Fabric 可以使用它们），证书路径错误是最常见的错误之一由织物用户。深思熟虑和一致性可以大大减少这些问题。
请注意，生产部署可能包含我们不会在此处显示的结构。例如，它可能包含一个gateways文件夹，允许管理员轻松查看哪些组织、节点和客户端与每个网络相关联。同样，您可能会看到一个智能合约文件夹，其中包含与网络关联的智能合约。
我们在此处描述的组织文件夹和证书的方法不是强制性的，但您会发现它很有帮助，因为它与本主题的其余部分以及 CA 部署指南一致。最重要的是，它围绕拥有和管理它们的组织来组织您的结构。虽然将您的部署视为围绕同级和排序节点等物理结构进行组织可能很自然，但实际上组织才是中心人物。特别是因为并非所有网络参与者都必须拥有一个节点。
此处介绍的结构和方法也代表了最佳实践，可防止出现以下情况，例如，Fabric 需要调用 MSP 文件夹msp，如果使用不同的名称，则必须在相关 YAML 文件中更改文件夹的名称.
运行 Fabric CA 客户端的文件夹结构
虽然一致的结构对于您将从 CA 取回的证书很重要（您将在创建节点和充当管理员时使用它），但对于那些将使用单个 Fabric CA 客户端连接到多个的人来说也很重要CA 作为管理员。这是因为与组织管理员不同，在组织管理员中，单个身份可以用作您需要的任意多个节点的管理员，每个 CA 都必须有一个单独的管理员，该管理员在启动时注册并稍后注册。
这就是为什么如果您以管理员身份从同一个 CA 客户端连接到不同的 CA 服务器，当您使用--mspdir标志时，您还必须包含-u标志以将正确的 CA 服务器作为目标。这将允许您为要连接的 CA 指定正确的 CA 管理员凭据。
如果您将只使用单个 CA 客户端来定位单个 CA 服务器（对于将成为组织或节点管理员的用户来说更常见的情况），您可以选择在 YAML 文件中指定 CA 服务器CA 客户端。
如果您遵循了 CA 部署指南中描述的过程，您应该有一组与您的 Fabric CA 客户端相关联的文件夹，它们看起来类似于以下内容：
上图显示了与使用单个 Fabric CA 客户端连接到多个 CA 服务器相关联的文件夹结构。
正如您所看到的，每个 CA 服务器在fabric-ca-client文件夹下都有一个单独的文件夹。在每个 CA 文件夹中都有一个msp文件夹，其中包含该 CA 管理员身份的公钥/私钥对。这是--mspdir您在管理 CA 时必须指定的（例如，在注册身份时）。
如果您不是 CA 管理员，而是仅出于注册组织 CA 和 TLS CA 的目的而拥有 Fabric CA 客户端，那么使用单个 Fabric CA 客户端仍然是最佳实践。此 CA 客户端仍需要 TLS 证书（可以使用 CA 部署指南中描述的过程获得），但您不需要指向 CA 管理员证书，因为您不是 CA 管理员。相反，由注册身份的 CA 管理员提供给您的注册 ID 和密码允许您与特定的 CA 服务器交互并接收必要的证书。
您的组织和节点管理员身份的文件夹结构
虽然您使用 Fabric CA 客户端组织 CA 文件夹的方式在很大程度上取决于典型 CA 管理员将与之交互的多个 CA，但您用于组织组织 MSP 的组织方法将部分取决于您预计创建和管理的组织数量。
例如，在 Fabric测试网络中，同时创建了 peer 组织和 orderer 组织。结果，与网络关联的脚本创建了一个名为organizations的文件夹，其中包含一个ordererOrganization和一个peerOrganization文件夹。这些文件夹中的每一个都包含每个组织的文件夹，其中包含该组织的 MSP 和这些组织拥有的每个节点的文件夹。
上图显示了管理员管理的组织结构。
即使您不打算创建排序者组织，这种结构也可以为您的部署提供最高级别的长期灵活性。例如，如果您创建一个新的对等点，您将知道在organizations/<name of org>/<name of new peer>处创建一个文件夹。<name of new peer>文件夹将是对等方的本地 MSP（在注册对等身份时生成）和通过 TLS CA 注册生成的证书的位置。类似地，同级所属组织的 MSP 的位置可以引用组织的msp文件夹（如果使用节点 OU，则包括config.yaml文件以及组织管理员的公共证书，在许多情况下将是同行的管理员）。
上图显示了组织拥有的同级内的子文件夹。注意这里msp文件夹下的peers文件夹。这是对等方的本地 MSP，而不是 MSP 的副本org1.example.com。
最佳做法是在注册身份之前创建这些文件夹，然后在通过--mspdir标志发出注册命令时引用它们。请注意，虽然 –mspdir 标志用于指定 CA 管理员的 MSP 在注册期间的位置，但它在注册期间用于指定文件系统上的位置，CA 返回的文件夹和证书将存储在该位置。
NodeOUs
在以前版本的 Fabric 中，身份只有两种类型：client和peer。该peer类型用于对等节点和排序节点，而该client类型用于客户端（应用程序）和管理员，将client类型放置在特殊admincerts文件夹中使身份成为特定上下文中的管理员。
现在可以并建议，不仅将peer或者client编码，而且将orderer或者admin角色编码到 CA 使用 NodeOU 生成的证书中。这嵌入了身份在证书中的角色。
请注意，一个身份只能具有这些角色之一，并且要启用这些角色，您必须将相关节复制到一个名为config.yaml. Fabric 以不同的方式使用config.yaml文件。在通道 MSP 中，它用于验证组织的admin角色是否具有（这取代了旧版本 Fabric 中使用的admincerts文件夹的使用）。在一个节点的本地MSP中，用于验证admin节点admin的角色和节点自身的peer或者orderer角色。
|
|
或者您可以手动将 Node OU 材料复制到msp文件夹的config.yaml文件中：
|
|
在生产场景中，假设用户将只创建一个组织。但是，最好为该组织建立一个单独的文件夹结构，然后在该组织下为您的msp（定义组织）和您的节点（将具有本地 MSP 和 TLS 部分）创建一个结构。
如果你正在创建一个排序者，你显然不需要将 PeerOUIdentifier 复制到你的 config.yaml 文件中（反之亦然），但为了简单起见，你可能想要使用整个部分——额外的节没有坏处，并且它们允许将相同的 config.yaml 用于与组织关联的多种类型的节点和身份。
注册身份
虽然管理员（或其他用户）使用的身份和节点使用的身份有不同的目的，但它们基本上都是身份：公钥/私钥对，其中公钥为他人所知，私钥用于签名，生成可以验证来自私钥的输出，即使私钥本身从未公开过。
如上所述，身份首先由 CA 管理员向 CA 注册。该身份随后由该身份的用户注册。如果您使用的是 Fabric CA 客户端，则此注册命令如下所示（无论您注册的身份类型和 CA 类型如何）：
|
|
其中变量如下：
ID_NAME：身份的注册 ID。 该名称将提供给带外用户，用户将在注册时使用它。ID_SECRET：身份的秘密（类似于密码）。 这个秘密也将与注册 ID 一起提供给用户，以便在注册时使用。CA_URL：CA 的 URL，端口7054（除非默认端口已更改）。CA_ADMIN：CA 管理员证书位置的路径。ID_TYPE：身份的类型（或角色）。 有四种可能的类型：peer、orderer、admin和client（用于应用程序）。 此类型必须链接到相关的 NodeOU。 如果没有使用 NodeOU，您可以忽略 type 和--id.type标志。ID_ATTRIBUTE：为此身份指定的任何属性。 有关属性的更多信息，请查看基于属性的访问控制。 这些属性也可以作为 JSON 数组添加，因此$ID_ATTRIBUTE并不代表单个属性，而是任何和所有属性，这些属性应该放在 register 命令中的--id.attrs标志之后。- TLSCERT：您的 TLS CA 根签名证书的相对路径（在创建 TLS CA 时生成）。
请注意，该-d标志启用调试模式，这对于注册失败时的调试很有用。
以下是管理员身份的示例注册命令：
|
|
身份成功注册后，CA 管理员会将注册 ID ( org1admin) 和注册密码 ( org1adminpw) 提供给将注册为管理员的用户。
如果您正在创建节点所需的证书，请确保也注册并注册与组织关联的 TLS CA。
登记身份
一旦设置了注册 CA 并注册了身份，CA 管理员将需要联系将在带外注册的用户，向他们提供他们在注册身份时使用的注册 ID 和密码。然后，使用这个 ID 和秘密，用户可以使用他们自己的 Fabric CA 客户端副本注册身份，以联系相关的 CA（这将是一个组织 CA，用于创建管理员和节点身份，或一个 TLS CA，用于生成节点需要的 TLS 证书）。请注意，如果启用了 TLS，则此用户将需要获取 TLS CA 根签名证书以在注册时包括在内。
虽然可以在注册管理员之前注册节点身份，但在注册节点（无论是对等节点还是排序节点）之前先注册管理员并建立组织的 MSP 更有意义。在启动节点之前，您当然需要注册管理员身份并将其证书放在节点的本地 MSP 中。
该命令如下所示：
|
|
使用这些变量：
ENROLL_ID：注册此身份时指定的注册 ID。这将必须在带外传达给该身份的用户。ENROLL_SECRET：注册此身份时指定的注册密码。这将必须在带外传达给该身份的用户。CA_URL: CA 的 URL，包括端口（默认为 7054）。如果您在同一位置配置了两个 CA，您还必须在标志后面指定一个 CA 名称--caname，但在本教程中，我们假设您使用的是 [CA 部署教程] 中指定的 CA 配置。PORT：您注册的 CA 使用的端口。MSP_FOLDER：文件系统上 MSP 的路径（本地 MSP，如果注册节点，或组织 MSP，如果注册管理员）。如果您没有指定-mspdir标志来指定位置，证书将被放置在一个名为msp您当前位置的文件夹中（如果该文件夹尚不存在，将创建它）。CSR_HOSTNAME：仅与节点身份相关，这将对节点的域名进行编码。例如，MagnetoCorp 可能会选择主机名peer0.mgntoorg.magnetocorp.com.TLS_CERT：与该组织关联的 TLS CA 的 TLS CA 根签名证书的相对路径。
这是一个示例注册命令，对应于我们之前使用的示例注册命令：
|
|
与典型的 CA 不同，其中注册命令将仅返回公钥/私钥对，Fabric CA 返回一个称为 MSP 的文件夹结构。这个 MSP 然后可以用来创建一个结构，在创建节点或将组织添加到通道时，Fabric 可以使用该结构。在注册管理员的情况下，MSP 构成了组织的基础。在注册节点身份的情况下，它构成了该节点的本地 MSP 的基础。请注意，此文件夹结构也将由 TLS CA 返回。但是，只需要相关的 TLS 证书。
以下是您注册身份后将返回的 MSP 示例：
上图显示了注册返回的子文件夹。
在证书命名中，使用有助于您跟踪您引用的是公共证书还是私钥的约定会很有帮助。鉴于两者都有.pem扩展名，请考虑以下命名公钥和私钥的约定：
- 将公共证书从
cert.pem（这是 Fabric CA 将赋予公共证书的默认名称）重命名为有意义的名称。例如，“Org1”管理员的公共证书可以命名为org1-admin-cert.pem. - 将私钥从
94u498f9r9fr98t49t345545345_sk重命名为有意义的名称，例如org1-admin-key.pem.
在此约定中，名称中附加 .pem 扩展名之前的最后一个词将是 cert 或 key 以帮助您记住哪个是哪个。
从登记身份创建MSP
正如我们所注意到的，向 Fabric CA 注册一个身份会生成输出，其中不仅包括公钥/私钥对，还包括 Fabric 网络需要使用的许多相关文件夹和证书。
但是，这并不意味着这些文件夹可以简单地放入通道配置（将组织加入通道）或放入节点的本地配置（创建本地 MSP）。在创建可以添加到频道的组织 MSP 的情况下，您需要删除管理员的私钥。对于本地 MSP，您需要添加管理员的公共证书。
有关组织 MSP（也称为“通道 MSP”，因为它已添加到通道）和节点的本地 MSP 中所需的文件夹和证书的更多信息，请查看 MSP结构。
创建将组织添加到频道所需的组织 MSP
Fabric 网络中的组织在物理意义上并不像节点那样存在。相反，它们作为通道配置中的文件夹和证书结构存在。这些证书标识相关的根 CA、中间 CA（如果使用了一个）、TLS CA 和至少一个管理员身份。正如您从上面的成员资格主题和注册和注册步骤中回忆的那样，这些文件夹和证书在注册管理员身份时由 Fabric CA 客户端返回，这就是注册管理员和“创建组织”行为的原因密切相关。
以下是您要将组织添加到频道时需要创建的文件夹结构示例（结构可能会略有不同，具体取决于您将组织添加到频道所使用的方法，但无论使用哪种方法，这些都是您需要的文件和文件夹）：
|
|
文件夹和证书在哪里：
- cacerts：注册和注册管理员身份的组织 CA 的根证书 (ca-cert.pem)。
intermediatecerts：中间 CA 的根证书（如果使用的话）。- tlscacerts：已向与该组织关联的节点颁发证书的 TLS CA 的根证书 (ca-cert.pem)。
tlsintermediatecerts：中间 TLS CA 的根证书（如果使用的话）。
请注意，虽然证书本身可以随意命名，但您不应更改文件夹本身的名称，因为 Fabric 期望使用具有特定名称的文件夹。
有关如何为该组织生成 config.yaml 文件的说明，请参阅 NodeOU。 在旧版本的 Fabric 中，config.yaml 文件不会在这里，并且需要一个额外的文件夹 admincerts，其中将放置标识该组织管理员的证书。 由于节点 OU，这不再是必需的。 config.yaml 中列出的 CA 赋予 admin 节点 OU 的任何身份都可以管理组织。
创建节点的本地 MSP
虽然组织的 MSP 用作组织在通道配置上的表示，但节点的本地 MSP 是参数的逻辑集合，与其他参数一起用作节点创建的一部分。
如上所述，必须使用注册证书（标识节点的公钥/私钥对）和加密节点间通信层的 TLS 证书来引导节点。这种“引导”是通过在创建节点时引用的相关 YAML 配置文件中列出这些证书的位置来实现的。这意味着必须先创建节点的本地 MSP，然后才能创建节点本身。请注意，节点的注册证书是通过列出包含它们的 MSP 的位置来指定的，而 TLS 证书是通过每个证书位置的绝对路径来标识的。
作为参考，这里有一个示例peer配置文件。
这是一个示例排序节点配置文件。
请注意，这些配置文件要求提供相关本地 MSP 文件夹的位置。对于对等方，这是通过mspConfigPath. 对于订购者，它是LocalMSPDir. 在此位置找到的文件夹将用于定义节点的本地 MSP，包括节点在签署其操作时将使用的私钥以及节点至少一位管理员的公钥。
另一方面，TLS 证书是单独定义的，而不是指向一个文件夹，并且可以在 YAML 的 TLS settings部分中找到。 这意味着 TLS 证书不需要像本地 MSP 那样保存在严格的文件夹结构中（特别是与将使用外部 CA 生成 TLS 证书的用户相关——使用示例 YAML 文件作为这些证书的指南） 用于）。 当您使用 TLS CA 注册节点时，生成的 TLS 公钥可以在 /signcerts 文件夹中找到，TLS 私钥可以在 /keystore 文件夹中找到。 当你建立一个启用了 TLS 的节点时，你需要从 YAML 配置文件中的相关字段指向这些文件。
与节点的 YAML 文件中的所有配置参数一样，您可以选择在 YAML 本身或通过使用环境变量来指定msp文件夹和 TLS 证书位置。
如果您正在使用容器化解决方案来运行您的网络（出于显而易见的原因，这是一种流行的选择），最好的做法是将这些文件夹（卷）挂载到节点本身运行的容器外部。如果节点容器出现故障、损坏或重新启动，这将允许使用证书创建新节点。
要查看示例本地 MSP，请查看MSP 结构。请注意，仅通过注册对等身份，您不会收到所有这些证书。例如，您需要创建users子文件夹，并在引导之前将管理节点的身份的公共证书放入文件夹中。您还需要一个操作证书（根据您的网络配置，这可能来自单独的操作 CA）。有关运营服务的更多信息，请查看运营服务。
这是一个示例本地 MSP，当节点已注册并添加了其他字段时，它可能看起来像：
|
|
文件夹和证书在哪里：
cacerts：注册和注册管理员身份的组织 CA 的根证书。intermediatecerts：中间 CA 的根证书（如果使用的话）。keystore：节点的私钥。这是节点用来签署其通信的密钥。signcerts：节点的公钥。该证书提供给进行传入通信的节点，允许发起通信的节点知道它正在与正确的节点对话。tlscacerts：已向与该组织关联的 CA 或节点颁发证书的 TLS CA 的根证书。tlsintermediatecerts：中间 TLS CA 的根证书（如果使用的话）。operationscerts：与操作服务交互所需的证书。
请注意，虽然证书本身可以随意命名，但您不应更改文件夹本身的名称，因为 Fabric 期望使用具有特定名称的文件夹。
正如节点 OU 不再需要在组织 MSP 中包含管理员证书一样，也不需要包含节点管理员的公共证书来管理节点。 config.yaml 中列出的 CA 赋予 admin 节点 OU 的任何身份都可以管理该组织拥有的任何节点，而无需将该管理员的公共证书放在组织 MSP 或本地 MSP 中。