在 Hyperledger Fabric CA 中添加/配置 CA 证书的使用者备用名称
我有几个 Hyperledger Fabric 网络（1.4 和 2.3+ 版本）工作正常，但我有一个恼人的 CA 配置问题。
我的工件生成的 CA 证书 (configtx.yaml) 和 (crypto-config.yaml) 的 CN 值是“ca.myorg.org”。这意味着 CA 仅接受对该主机地址的请求。如果我请求主机“ca”（这是 Kubernetes 集群创建的主机名），我会收到
来自 CA 实例的“hyperledger 客户端与任何主题备用名称不匹配”错误。
我使用 Kubernetes 部署网络，服务名称为“ca”、“peer1”、... 所以我不能简单地将 ca.myorg.org 设置为服务名称...这意味着我必须：
- 在 Kubernetes 内部 DNS 中添加自定义 DNS 别名来映射 ca -> ca.myorg.org，这样我就可以从 Chaincode Java 客户端 pod 运行对 ca.myorg.org 的请求。 （对“ca”的请求将被 CA 拒绝。
- 当我从 Kubernetes 网络外部运行测试时，我需要使用 Kubefwd，这没问题，但这会在我的计算机中创建一个本地主机条目“ca”...每次我也需要手动将该别名添加到主机文件中。
我的问题是...如何配置工件，以便“ca”也被接受为 CA 生成的证书中的主题备用名称？ 作为解决
办法，我也可以吗？ 。
当然，在创建 Hyperledger Fabric 网络时，我可能会遗漏所有这些工件证书生成的内容 将 CA 部署在 Kubernetes 中时要采取的方法。
I have a couple of Hyperledger Fabric networks (1.4 and 2.3+ versions) working OK but I have a annoying configuration problem with the CA.
The certificate for the CA that my artifacts generate (configtx.yaml) and (crypto-config.yaml) has as CN value "ca.myorg.org". This means that the CA only accepts requests to that host address. If I do a request to host "ca" (which is the host name created by the Kubernetes cluster) I get:
"hyperledger client doesn't match any of the subject alternative names" error from the CA instance.
I use Kubernetes to deploy the network and the service name are "ca", "peer1", ...
so I cannot simply set ca.myorg.org as service name... this implies that I have to:
- Add a custom DNS alias in the Kubernetes inner DNS to map ca -> ca.myorg.org so I can run requests to ca.myorg.org from the Chaincode Java client pod. (requests to "ca" will be rejected by CA.
- When I run tests from outside the Kubernetes network, I need to use Kubefwd, which is OK, but that will create a local hosts entry "ca" in my computer... everytime I need to manually add that alias too to the hosts file. Very annoying.
My question is... how can I configure the artifacts so "ca" is also accepted as a Subject Alternative Name in the generated certificate for the CA? That would solve my problem.
As a work around, can I also alter the certificate adding the "ca" subject alternative name, after it's generated? That would work.
Of course, maybe I am missing something on all this artifact certificate generation when creating the Hyperledger Fabric network. I'm all ears for suggestions on what approach to take when the CA is going to be deployed in Kubernetes.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论