证书如何从 hyperledger 的 hfc-key-store 中的真实 fabric-ca-server 证书中获取？
how certificates get derived from the real fabric-ca-server certificate in hfc-key-store in hyperledger?
我想先解释一下我理解正确的地方，如果我是对的，请告诉我真相，如果我错了，也请告诉我我错了。我的解释是关于超级账本网络和节点sdk如何协同工作以及节点sdk如何连接到超级账本网络。
让我们开始吧。当我启动 hyperledger 网络时，它所做的是在端口 7054 上创建 fabric-ca-server docker 图像和容器。在该端口上，它注册了一个用户 "admin with the password : "adminpwd”。这意味着还有为此用户制作的证书。现在假设我想从节点 sdk 创建一个新用户。我想我需要做的是拥有管理员证书，以便我可以签署我的请求并且网络知道我是管理员和部分网络的代码。代码所做的是首先写入 getUserContext("admin")，如果找不到，则尝试使用用户名和密码（admin 和 adminpwd）注册。我的理解是 getUserContext 会到 hfc-key-store 文件夹并尝试为管理员找到证书。如果找不到，就会发生注册，然后发生 createUser 函数，它将来自 fabric-ca-server docker 图像的证书放入hfc-key-store，这样当管理员尝试再次注册时，它不必转到 fabric-ca-server docker 图像。我说得对吗 f啊？我现在就问我的问题。
问题：
我知道在尝试注册时，它不会从 fabric-ca-server docker 图像中获取管理员的原始证书，因为如果它被盗，整个网络都会被盗搞砸了。所以它所做的是从原始证书中派生出某种 public/private 和证书，我可以进行其他操作。问题是：如果有人偷了我的 hfc-key-store 文件夹，其中有管理员证书怎么办。他可以在不注册的情况下进行操作，因为 getUserContext("admin") 会 return true 并且它会让它做任何事情。如果有人偷了那个文件夹怎么办？不危险吗？
我完全不明白 getUserContext() 和 setUserContext() 以及 createUser() 函数的含义。如果可以的话，请用一种非常容易理解的语言来描述它们，因为我已经很久没有尝试解决这个问题了，但没有运气。为什么我们需要这些功能，它们对我们有什么帮助等等。
为什么cryptogen工具不能用于生产，而fabric-ca-server可以用于生产？
您的问题有多个部分；我会尝试从头开始。
run/operateFabric 对等节点或排序节点不需要 Fabric CA。默认安全机制基于使用椭圆曲线的标准 X509 PKI（p256 是默认值）。您可以使用以任何方式颁发的 X509 证书。 Fabric CA 就是这样一种实现。
Fabric CA 有多个 API，但最主要的两个是 Register 和 Enroll。注册是颁发 X509 证书的过程。您必须先注册 users/nodes，然后才能注册。首次启动 Fabric CA 时，您必须创建一个 "bootstrap" 管理员用户。该用户在启动时自动注册，但尚未注册。您通过生成私钥和证书签名请求向 Fabric CA 注册，并使用注册 ID 和 Secret 提交。如果成功，您将收到由 Fabric CA 签名的 X509 证书。
为方便起见，Fabric Node SDK 提供了一个 fabric-ca-client 包，它提供了用于向 Fabric CA 注册和注册用户的包装器 API。这允许您从 Fabric CA
但是，fabric-client 包不需要您从 Fabric CA 获取凭据。您可能拥有自己的私钥和 X509 证书，这些证书由其他机构颁发（甚至由 cryptogen 生成）。
fabric-client 提供了一个 "pluggable" 密钥库来存储凭据。默认是基于文件的密钥存储。
在内部，fabric-client 实际上使用User class 来表示当前用户。这很重要，因为有几种方法可以填充此结构：
createUser() - 此函数允许您从预先存在的 private/public(X509) 密钥对User.setEnrollment() - this allows you to directly add there required info to the structure ... this is commonly used with the response from CertificateAuthority.enroll()
- 一旦你有了一个
User 对象，你需要告诉 fabric-client 使用它。这是您使用 Client.setUserContext() 的地方。您传入 User 对象，默认情况下这将被保留。
- 然后您可以使用
Client.getUserContext() - 它从配置的密钥库中加载用户信息 - 用于在您启动客户端应用程序时的未来请求。
关于您关于 cryptogen 的问题，您没有理由不能在生产中使用生成的加密材料...只是因为它是一个真正旨在帮助开发和测试的工具到 bootstrap 个网络。它不是 PKI 基础设施，不包括证书吊销等内容。
希望这对您有所帮助。
我喜欢你提出的所有问题，最近我在为 HLF 开发 Node SDK 时遇到了完全相同的问题。
我会尽力回答。
- 在区块链世界中，保护私钥是重中之重。如果您将私钥泄露给某人，这意味着您已经失去了对您的私钥解锁的任何实体的所有权。在 Hyperledger Fabric 中，您必须确保密钥的安全，无论是管理员密钥还是用户密钥。如果它以任何方式被盗，则意味着您已受到威胁。请记住，“能力越大，责任越大”。此外，“getUserContext("admin")”并不总是 return 'admin' 用户上下文。我会在下一个回答中解释。
API 文档在此处解释了所有技术细节：
getUserContext setUserContext createUser
所有这些方法都可以在 'client' class on NodeSDK 上找到。这些
方法允许 'user' 管理。当你说 Hyperledger 中的用户时
Fabric 世界，默认情况下它带有一个 public 和一个私钥
参考。它具有所有其他字段，例如从属关系、身份、
角色等也是如此。阅读更多：User
createUser 创建 User class 的实例，其中 all/any 提供了上述属性。这个实例将被使用
做所有相关的操作。如果用户具有“admin”访问权限，
它可以在 Hyperledger Fabric 中执行 'admin' 级别的功能
世界等其他角色。
getUserContext 和 setUserContext gets/sets client 实例的上下文。通过设置适当的用户上下文，您
验证 客户端 并继续客户端实例可以
使用此上下文来签署请求。
除此之外，这两种方法reads/writes对一些
持久存储（如果已配置）。对于 Node SDK，它是
hfc-key-store。如果你检查这个文件夹的内容，你会发现你所有的用户身份都存储在这里。如果需要的文件是
在此文件夹下找不到（或配置的任何文件夹
crypto-suite), getUserContext 会失败然后你必须
手动从文件系统中读取证书并创建用户
从这些证书中取出，然后将其用于 setUserContext.
cryptogen 工具本质上是静态的。而 Fabric CA 服务器
支持使用 Fabric CA Client 通过 REST APIs 进行通信或
面料 SDK。这使得它在生产环境中非常有用
您需要在其中生成新身份（读取证书）的位置
走。使用 cryptogen 工具在这里会变得很麻烦。
好像问题很多。让我一步一步地解释它。如有不妥之处或不清楚的地方请大家指正。
Fabric设计为Consortium Blockchain System，广泛应用于企业业务场景。在 Fabric 业务网络中，每个组织通常包含至少一个 peer，并且可选 ca.
想想这样的业务场景。几家公司想一起做生意。然而，他们对彼此的信任不够。所以他们决定使用 Fabric 来解决他们的痛点。假设这个网络包含 3 个公司（组织），每个公司（组织）有一个 peer 和一个 ca.
现在业务网络已经设置好了。
首先，让我解释一下注册的概念。
- 每个组织的 ca 都有一个 bootstrap 用户，由用户名和密码组成，通常样本会使用 admin/adminpw。在 ca 服务器设置期间，这个 bootstrap 用户被写入 CA 的数据库。设置后，bootstrap 用户已注册。但未注册。
- 接下来是
enroll the bootstrap user。在这一步中，fabric-sdk（后面我会用到sdk）会先生成一个private/public密钥对，然后生成一个csr（certificate signing request），最后用私钥对csr进行签名，将签名的 csr 发送到 fabric-ca 服务器。
- 当 fabric-ca 服务器收到签名的 csr 时。它为此用户生成一个证书。证书包含用户的 public 密钥。 Fabric-ca 将使用其私钥签署此请求并将其签名附加到证书中。
- sdk 从 fabric-ca 服务器获得响应（来自 3 的证书）。 fabric-sdk 将证书和用户的私钥放在一起（我们称之为注册）作为方法
enroll(). 的响应
- 现在 bootstrap 用户已注册，可以使用此注册访问 fabric 网络。
我们可以使用 bootstrap 用户在这个组织中注册和注册新用户。这就是为什么我们称联盟链系统为许可链系统。
其次，让我解释一下sdk KVS（key-value-store）的概念。
我们已经从上面的步骤中得到了用户的私钥和证书。那么我们如何持久化这些数据呢？有几种选择，存储在应用层数据库，一些硬件加密钱包，一些基于云的HSM等
Fabric-sdk 提供了一个 KVS 来做这个。这是一个可选的选择，您可以选择使用或不使用它。坦率地说，我不建议在生产系统中使用它。如果你只是想尝试一些东西或测试一些东西，这很好，因为它非常简单。
默认情况下，fabirc-sdk-node 将使用文件系统 KVS。它将凭据存储在磁盘中，这就是您提到的 hfc-key-store 文件夹。
那么KVS被盗了会怎样呢？
所有注册都被盗了。所有的证书和私钥都被盗了。攻击者可以使用这些证书和私钥以这些证书中的身份访问区块链系统。这是一场灾难。
createUser() 有什么用？
而不是将这些注册存储在文件系统中。将其存储在应用层数据库中是更好的选择。每次我们要访问区块链系统，都可以先从数据库中查询，得到证书和私钥。然后使用createUser()接口创建一个新的User实例。此User实例用作访问区块链系统的身份。
最后，让我解释一下fabric中的交易流程
我们没有有效的用户证书和私钥。我们如何将交易发送到结构网络？ fabric-peer如何验证交易并知道我是谁？
- 每笔交易都包含用户的身份。如果您想在
userA 之前提交交易，那么您应该在进一步的背书调用之前调用 setUserContext(userA)。
- 交易提议在消息头包含用户证书。并且在交易发送到fabric-peer之前，sdk会使用当前用户的私钥签署这个交易提案。
- 在对端。当 peer 收到 endorse 请求时，peer 将使用 fabric-ca 的根证书来验证此请求中的证书，以便 peer 知道此请求来自已知 CA 颁发的身份，此时证书是可信的。然后对等方将解析证书并获取身份的 public 密钥，然后使用此 public 密钥验证交易的签名（我上面描述的 tx 是由私钥签名的，现在它由 public 密钥验证），现在交易是可信的。
从交易流程中，我们了解到交易必须与用户的证书一起发送，并由用户的私钥签名。这就是为什么我们在 fabirc-sdk 设计了 setUserContext() 接口。
加密工具
此工具用于在系统设置时生成 private/public 密钥对和相应的证书。之后我们需要一个动态的 add/remove 身份机制。解决方案是 Fabric-ca.
Note, fabric-ca is optional, you may use any other CA.
我想先解释一下我理解正确的地方，如果我是对的，请告诉我真相，如果我错了，也请告诉我我错了。我的解释是关于超级账本网络和节点sdk如何协同工作以及节点sdk如何连接到超级账本网络。
让我们开始吧。当我启动 hyperledger 网络时，它所做的是在端口 7054 上创建 fabric-ca-server docker 图像和容器。在该端口上，它注册了一个用户 "admin with the password : "adminpwd”。这意味着还有为此用户制作的证书。现在假设我想从节点 sdk 创建一个新用户。我想我需要做的是拥有管理员证书，以便我可以签署我的请求并且网络知道我是管理员和部分网络的代码。代码所做的是首先写入 getUserContext("admin")，如果找不到，则尝试使用用户名和密码（admin 和 adminpwd）注册。我的理解是 getUserContext 会到 hfc-key-store 文件夹并尝试为管理员找到证书。如果找不到，就会发生注册，然后发生 createUser 函数，它将来自 fabric-ca-server docker 图像的证书放入hfc-key-store，这样当管理员尝试再次注册时，它不必转到 fabric-ca-server docker 图像。我说得对吗 f啊？我现在就问我的问题。
问题：
我知道在尝试注册时，它不会从 fabric-ca-server docker 图像中获取管理员的原始证书，因为如果它被盗，整个网络都会被盗搞砸了。所以它所做的是从原始证书中派生出某种 public/private 和证书，我可以进行其他操作。问题是：如果有人偷了我的 hfc-key-store 文件夹，其中有管理员证书怎么办。他可以在不注册的情况下进行操作，因为 getUserContext("admin") 会 return true 并且它会让它做任何事情。如果有人偷了那个文件夹怎么办？不危险吗？
我完全不明白 getUserContext() 和 setUserContext() 以及 createUser() 函数的含义。如果可以的话，请用一种非常容易理解的语言来描述它们，因为我已经很久没有尝试解决这个问题了，但没有运气。为什么我们需要这些功能，它们对我们有什么帮助等等。
为什么cryptogen工具不能用于生产，而fabric-ca-server可以用于生产？
您的问题有多个部分；我会尝试从头开始。
run/operateFabric 对等节点或排序节点不需要 Fabric CA。默认安全机制基于使用椭圆曲线的标准 X509 PKI（p256 是默认值）。您可以使用以任何方式颁发的 X509 证书。 Fabric CA 就是这样一种实现。
Fabric CA 有多个 API，但最主要的两个是 Register 和 Enroll。注册是颁发 X509 证书的过程。您必须先注册 users/nodes，然后才能注册。首次启动 Fabric CA 时，您必须创建一个 "bootstrap" 管理员用户。该用户在启动时自动注册，但尚未注册。您通过生成私钥和证书签名请求向 Fabric CA 注册，并使用注册 ID 和 Secret 提交。如果成功，您将收到由 Fabric CA 签名的 X509 证书。
为方便起见，Fabric Node SDK 提供了一个 fabric-ca-client 包，它提供了用于向 Fabric CA 注册和注册用户的包装器 API。这允许您从 Fabric CA
获取和使用凭据
但是，fabric-client 包不需要您从 Fabric CA 获取凭据。您可能拥有自己的私钥和 X509 证书，这些证书由其他机构颁发（甚至由 cryptogen 生成）。
fabric-client 提供了一个 "pluggable" 密钥库来存储凭据。默认是基于文件的密钥存储。
在内部，fabric-client 实际上使用User class 来表示当前用户。这很重要，因为有几种方法可以填充此结构：
createUser()- 此函数允许您从预先存在的 private/public(X509) 密钥对 创建用户
User.setEnrollment()- this allows you to directly add there required info to the structure ... this is commonly used with the response fromCertificateAuthority.enroll()
- 一旦你有了一个
User对象，你需要告诉 fabric-client 使用它。这是您使用Client.setUserContext()的地方。您传入User对象，默认情况下这将被保留。 - 然后您可以使用
Client.getUserContext()- 它从配置的密钥库中加载用户信息 - 用于在您启动客户端应用程序时的未来请求。
关于您关于 cryptogen 的问题，您没有理由不能在生产中使用生成的加密材料...只是因为它是一个真正旨在帮助开发和测试的工具到 bootstrap 个网络。它不是 PKI 基础设施，不包括证书吊销等内容。
希望这对您有所帮助。
我喜欢你提出的所有问题，最近我在为 HLF 开发 Node SDK 时遇到了完全相同的问题。
我会尽力回答。
- 在区块链世界中，保护私钥是重中之重。如果您将私钥泄露给某人，这意味着您已经失去了对您的私钥解锁的任何实体的所有权。在 Hyperledger Fabric 中，您必须确保密钥的安全，无论是管理员密钥还是用户密钥。如果它以任何方式被盗，则意味着您已受到威胁。请记住，“能力越大，责任越大”。此外，“getUserContext("admin")”并不总是 return 'admin' 用户上下文。我会在下一个回答中解释。
API 文档在此处解释了所有技术细节： getUserContext setUserContext createUser
所有这些方法都可以在 'client' class on NodeSDK 上找到。这些 方法允许 'user' 管理。当你说 Hyperledger 中的用户时 Fabric 世界，默认情况下它带有一个 public 和一个私钥 参考。它具有所有其他字段，例如从属关系、身份、 角色等也是如此。阅读更多：User
createUser 创建 User class 的实例，其中 all/any 提供了上述属性。这个实例将被使用 做所有相关的操作。如果用户具有“admin”访问权限， 它可以在 Hyperledger Fabric 中执行 'admin' 级别的功能 世界等其他角色。
getUserContext 和 setUserContext gets/sets client 实例的上下文。通过设置适当的用户上下文，您 验证 客户端 并继续客户端实例可以 使用此上下文来签署请求。
除此之外，这两种方法reads/writes对一些 持久存储（如果已配置）。对于 Node SDK，它是 hfc-key-store。如果你检查这个文件夹的内容，你会发现你所有的用户身份都存储在这里。如果需要的文件是 在此文件夹下找不到（或配置的任何文件夹 crypto-suite), getUserContext 会失败然后你必须 手动从文件系统中读取证书并创建用户 从这些证书中取出，然后将其用于 setUserContext.
cryptogen 工具本质上是静态的。而 Fabric CA 服务器 支持使用 Fabric CA Client 通过 REST APIs 进行通信或 面料 SDK。这使得它在生产环境中非常有用 您需要在其中生成新身份（读取证书）的位置 走。使用 cryptogen 工具在这里会变得很麻烦。
好像问题很多。让我一步一步地解释它。如有不妥之处或不清楚的地方请大家指正。
Fabric设计为Consortium Blockchain System，广泛应用于企业业务场景。在 Fabric 业务网络中，每个组织通常包含至少一个 peer，并且可选 ca.
想想这样的业务场景。几家公司想一起做生意。然而，他们对彼此的信任不够。所以他们决定使用 Fabric 来解决他们的痛点。假设这个网络包含 3 个公司（组织），每个公司（组织）有一个 peer 和一个 ca.
现在业务网络已经设置好了。
首先，让我解释一下注册的概念。
- 每个组织的 ca 都有一个 bootstrap 用户，由用户名和密码组成，通常样本会使用 admin/adminpw。在 ca 服务器设置期间，这个 bootstrap 用户被写入 CA 的数据库。设置后，bootstrap 用户已注册。但未注册。
- 接下来是
enroll the bootstrap user。在这一步中，fabric-sdk（后面我会用到sdk）会先生成一个private/public密钥对，然后生成一个csr（certificate signing request），最后用私钥对csr进行签名，将签名的 csr 发送到 fabric-ca 服务器。 - 当 fabric-ca 服务器收到签名的 csr 时。它为此用户生成一个证书。证书包含用户的 public 密钥。 Fabric-ca 将使用其私钥签署此请求并将其签名附加到证书中。
- sdk 从 fabric-ca 服务器获得响应（来自 3 的证书）。 fabric-sdk 将证书和用户的私钥放在一起（我们称之为注册）作为方法
enroll(). 的响应
- 现在 bootstrap 用户已注册，可以使用此注册访问 fabric 网络。
我们可以使用 bootstrap 用户在这个组织中注册和注册新用户。这就是为什么我们称联盟链系统为许可链系统。
其次，让我解释一下sdk KVS（key-value-store）的概念。
我们已经从上面的步骤中得到了用户的私钥和证书。那么我们如何持久化这些数据呢？有几种选择，存储在应用层数据库，一些硬件加密钱包，一些基于云的HSM等
Fabric-sdk 提供了一个 KVS 来做这个。这是一个可选的选择，您可以选择使用或不使用它。坦率地说，我不建议在生产系统中使用它。如果你只是想尝试一些东西或测试一些东西，这很好，因为它非常简单。
默认情况下，fabirc-sdk-node 将使用文件系统 KVS。它将凭据存储在磁盘中，这就是您提到的 hfc-key-store 文件夹。
那么KVS被盗了会怎样呢？
所有注册都被盗了。所有的证书和私钥都被盗了。攻击者可以使用这些证书和私钥以这些证书中的身份访问区块链系统。这是一场灾难。
createUser() 有什么用？
而不是将这些注册存储在文件系统中。将其存储在应用层数据库中是更好的选择。每次我们要访问区块链系统，都可以先从数据库中查询，得到证书和私钥。然后使用createUser()接口创建一个新的User实例。此User实例用作访问区块链系统的身份。
最后，让我解释一下fabric中的交易流程
我们没有有效的用户证书和私钥。我们如何将交易发送到结构网络？ fabric-peer如何验证交易并知道我是谁？
- 每笔交易都包含用户的身份。如果您想在
userA之前提交交易，那么您应该在进一步的背书调用之前调用setUserContext(userA)。 - 交易提议在消息头包含用户证书。并且在交易发送到fabric-peer之前，sdk会使用当前用户的私钥签署这个交易提案。
- 在对端。当 peer 收到 endorse 请求时，peer 将使用 fabric-ca 的根证书来验证此请求中的证书，以便 peer 知道此请求来自已知 CA 颁发的身份，此时证书是可信的。然后对等方将解析证书并获取身份的 public 密钥，然后使用此 public 密钥验证交易的签名（我上面描述的 tx 是由私钥签名的，现在它由 public 密钥验证），现在交易是可信的。
从交易流程中，我们了解到交易必须与用户的证书一起发送，并由用户的私钥签名。这就是为什么我们在 fabirc-sdk 设计了 setUserContext() 接口。
加密工具
此工具用于在系统设置时生成 private/public 密钥对和相应的证书。之后我们需要一个动态的 add/remove 身份机制。解决方案是 Fabric-ca.
Note, fabric-ca is optional, you may use any other CA.