我已经用cryptogen生成了证书。
并且检查了使用openssl生成的证书，并注意到该证书缺少可用于区分对等角色和客户端角色的信息。我相信admin是可以区分的，因为admincerts是用区块链编写的，但是没有有关客户端和对等方的信息。
Certificate:
Data:
Version: 3 (0x2)
Signature Algorithm: ecdsa-with-SHA256
Issuer: C = US, ST = California, L = San Francisco, O = test.com, CN = ca.test.com
Validity
Not Before: Sep 19 01:49:00 2019 GMT
Not After : Sep 16 01:49:00 2029 GMT
Subject: C = US, ST = California, L = San Francisco, CN = [email protected]
...
Certificate:
Data:
Version: 3 (0x2)
Signature Algorithm: ecdsa-with-SHA256
Issuer: C = US, ST = California, L = San Francisco, O = test.com, CN = ca.test.com
Validity
Not Before: Sep 19 01:49:00 2019 GMT
Not After : Sep 16 01:49:00 2029 GMT
Subject: C = US, ST = California, L = San Francisco, CN = p0.test.com
...
（（我所看到的唯一区别是主题的CN，密钥和ID相关的事物）
我想知道的原因是，尽管无法区分它们的角色，但由于加入频道时CSCC失败，因此无法使用客户端的MSP来支持节点设置。
Error: proposal failed (err: bad proposal response 500: access denied for [JoinChain][testc]: [Failed verifying that proposal's creator satisfies local MSP principal during channelless check policy with policy [Admins]: [This identity is not an admin]])
（（其他拥有MSP的同行成功加入了btw频道）
所以角色系统按预期工作，但是CSCC实际上是如何认识证书角色的？有隐藏的机制吗？
它非常简单，没有什么复杂或隐藏的机制，众所周知，它是一个PKI。
每个实体对等方，订购者都有其自己的MSP
所以MSP中有什么
.
├── admincerts
├── cacerts
├── keystore
├── signcerts
└── tlscacerts
如您所见，每个对等方都会因本地MSP而产生信任，在对等MSP的上述结构中，我们具有admincerts，因此我们提到的任何对等身份都将假定该身份为管理员，并且您需要签署创建频道，加入频道或使用该管理员凭据安装链码事务
如果您更改凭据，对等方将抱怨。
相同方式cacerts：对等方将假定cacerts文件夹中存在的任何rootCA证书链，它将接受来自客户端的具有该ca颁发的身份的任何请求
来到您的客户和同事：
嘿，当您注册一个身份时，您将以attribute的形式提到它的角色，它用于许多用例，当您使用fabric-ca而不是cryptogen工具生成证书时，您将获得更多的见解。
检查this
管理员的证书存储在admincerts的msp目录中。如果可以验证交易的签名，则可以说交易的发送者是admincerts。简而言之，Fabric从不是证书本身而是Msp来了解证书角色。
[这是超级账本结构平台自行处理的事情。我们只需要处理基于客户端证书的Hyperledger Fabric支持属性的证书。因此您可以通过其属性来识别其他证书。
在Fabric网络中，每个组件都有其自己的标识。这意味着每个组件都有其自己的证书，该证书由面料自行处理。