本文基于hyperledger identity、MSP介绍，x509基础知识、tls内容，对hyperledger的身份系统有一个原理上的基础介绍。对x509证书内容有一个基础介绍和如何在hyperledger中使用的。
1. 基础知识
1.1 hyperledger 身份系统基础介绍
1.1.1 什么是身份
在hyperledger区块链网络中包括不同的参与者：peers, orderers, client，admin等等。这些参与者中的每一个（网络内部或者外部能有使用服务的有效元素），都具有封装在X.509数字证书中的数字身份。这些身份确实很重要，因为它们确定了对资源的确切权限以及对参与者在区块链网络中拥有的信息的访问权限。（具体如何实现的将在后面介绍）
为了使证书是可验证的，它必须来自可信任的机构。hyperledger fabric（后文中以hyperledger代指）中是通过MSP（ membership service provider）来实现的。MSP是定义管理该组织的有效身份的规则的组件。对于身份部分更具体的说，MSP定义了一个信任域例如组织应该信任哪些根 ca和中间 ca来定义自己的成员。hyperledger中的默认MSP实现使用X.509证书作为身份，采用传统的公钥基础结构（PKI）分层模型（稍后将详细介绍PKI）。
1.1.2 什么是PKI
PKI是公钥基础结构（public key infrastructure）的缩写。是可在网络中提供安全通信的互联网技术集合。https中的s就是是PKI来提供的。在hyperledger中PKI是由证书颁发机构（Certificate Authorities，缩写CA）（注：这里的机构就是一个通用名词代指，跟hyperledger实际的结构及组织没有关系，只有当它被赋予特殊的业务含义的时候才会发生联系）组成。证书颁发机构向参与者（例如，服务的用户，服务提供商）颁发证书，参与者使用证书在与其环境（hyperledger系统）交换的消息中对自己进行身份验证。
PKI有四个关键要素：
数字证书
公钥和私钥
证书颁发机构
证书撤销列表
PKI在hyperledger中更像是上述行为集合一个逻辑概念，没有必要单独进行更加深入的了解。如果想了解更多细节，维基百科是一个很好地开始的地方。
1.1.3 数字证书
数字证书是包含与证书持有者有关的一组属性（attributes）的文档（document）。最常见的证书类型是符合X.509标准的证书，X.509允许在其结构中编码使用方的识别细节（allows the encoding of a party’s identifying details in its structure）。
例如, Mary Morris是美国密歇根州（Michigan）的Manufacturing的Mitchell Cars部门，她可能拥有一个身份证书，证书的subject属性是C=US, ST=Michigan, L=Detroit, O=Mitchell Cars, OU=Manufacturing, CN=Mary Morris /UID=123456。Mary的证书类似于她的政府身份证 - 它提供了有关玛丽的信息，她可以用来证明关于她的关键信息。X.509证书中还有许多其他属性，但在hyperledger中身份证书的使用集中在这些。
这是描述一个叫Mary Morris的人的数字证书。Mary是证书的SUBJECT（主题），突出显示的SUBJECT文本显示了关于Mary的重要事实。如您所见，证书还包含更多信息。最重要的是，Mary的公钥是在她的证书中分发的，而她的私人签名密钥则不是。此签名密钥必须保密。
重要的是，玛丽的所有属性都可以使用称为密码学（字面意思，“ 秘密写作 ”）的数学技术进行记录，这样篡改将使证书无效。只要对方信任证书颁发者（称为证书颁发机构（CA）），密码学就允许Mary将证书提交给其他人以证明其身份。只要CA安全地保存某些加密信息（意味着CA自己的私人签名密钥，或者说用于签名的私钥），任何阅读证书的人都可以确定有关Mary的信息没有被篡改 - 它将始终具有Mary Morris的特定属性。你可以将Mary的X.509证书想象成一个无法改变的数字身份证。
1.1.4 公私钥，身份验证
在上一小节中，我们说到身份证书中包含公钥信息，同时与公钥有关的签名私钥是需要保密的。接下来会大致介绍什么是公私钥，以及身份验证。
公钥和私钥是一一对应的，每一个私钥都有一个唯一对应的公钥。用公钥加密后的信息只有私钥能解开，反之亦然。
身份验证和消息完整性是安全通信中的重要概念。身份验证要求确保交换消息的各方具有创建特定消息的身份。完整性意味着消息在其传输期间不能被修改。例如，你可能希望确保与真正的Mary而不是伪装者沟通。或者，如果Mary向你发送了一条消息，你可能希望确保其在传输过程中没有被其他任何人篡改过。
传统的身份验证机制依赖于数字签名，顾名思义，它允许一方对其消息进行数字签名。数字签名还可以保证签名消息的完整性。
从技术上讲，数字签名机制要求每一方保留两个具有加密关系的密钥：一个公钥可以广泛传播用于验证功能，一个私钥用于在特定信息上产生数字签名。数字签名信息的收件人可以使用预期公钥来检查附加在信息上的签名是否有效来验证收到邮件的来源和完整性。（这里有个问题可以提前思考一下：我如何有效的验证一个身份证书是Mary的还是伪造的呢）
在上面的示例中，Mary使用她的私钥对信息进行签名。任何使用她的公钥查看签名消息的人都可以验证签名。
1.1.5 证书颁发机构CA
除非是Mary线下给我一个证书，说这是她的证书，我有什么其他手段获得证书并且能够验伪吗？（例如Mary给我证书的时候被拦截了，给我一个伪造的，或者两个人都自称是Mary给我一个证书我怎么知道哪个是真的）。这个时候就引入了证书机构的概念。
如果你对hyperledger有了解，你就会发现一个人或者一个节点能够通过由系统信任的机构为其发布的数字身份参与区块链网络。在最常见的情况下，数字身份（或简称身份）具有符合X.509标准并由证书颁发机构（CA）颁发的经加密验证的数字证书的形式。
证书颁发机构向不同的参与者分发证书。这些证书由CA进行数字签名，并将参与者与参与者的公钥绑定在一起（并且可能具有一系列比较全面的属性）。因此，如果一个人信任CA（并且知道其公钥，公钥会放在证书中），则可以信任特定参与者绑定到证书中包含的公钥，并通过验证参与者证书上的CA签名来验证拥有所包含的属性（CA签名保证身份信息不被修改，或者说修改后签名就不再匹配）。
证书可以被广泛传播，因为它包含拥有者的公钥（公钥本来就需要分发给验证者，所以仅仅是传播给验证者或者潜在的验证者即满足了使用要求），但是不包含拥有者的私钥（所以广泛传播而不是只传播给验证者不会造成安全隐患）。
1.1.6 根CA，中间CA和信任链
是不是只要有证书颁发机构就行了呢？如果是个野鸡证书颁发机构发的证书呢，怎么验伪？那么是不是要有个颁发机构的颁发机构，然后接下来就是一个无限套娃的过程。证书协议的制定并不解决这个问题，而是需要有一个原始证书需要被信任，这个证书就是根证书（从技术上来讲，这就是个自签名的证书，只不过这个证书属于一个可被信任的根机构，这个机构用这个证书为自己代言）。（证书权威机构通过任何手段分发自己证书，报纸、官网、终端系统内置等等）
CA的有两种形式：根CA和中间CA。由于Root CA必须安全地向互联网用户分发数亿个证书，因此将此流程分散到所谓的中间CA中是有意义的（分流和降低root ca暴露风险）。这些中间CA具有由根CA或其他中间机构颁发的证书，这整个流程为任何由CA颁发的证书建立起“信任链”。追溯到根CA的这种能力不仅允许CA的功能扩展，同时仍然提供安全性。允许使用证书的组织充满信心地使用中间CA--它限制了根CA的暴露，如果受到损害，将会危及整个信任链；如果中级CA受到损害，则危害量会小得多。
只要每个中间CA的证书的颁发CA是根CA本身或具有对根CA信任链的中间CA，就在根CA和一组中间CA之间建立信任链。
在跨多个组织颁发证书时，中间CA提供了巨大的灵活性，这在许可的区块链系统（如Fabric）中非常有用。例如，您将看到不同的组织可能使用不同的根CA，或使用具有不同中间CA的相同根CA - 它确实取决于网络的需求（实际上最佳的实践是每个组织一个根ca，不然在八卦协议和组织内成员认证的时候需要一些额外的工作）。
1.2 MSP
个人理解，PKI和MSP之间的联系与区分：PKI体系定义证书的颁发、验证、撤销协议；MSP是在PKI基础上结合具体的业务逻辑，进行身份认证和权限管理。
参考文献：
hyperledger中的MSP
有关MSP的设置和最佳实践
成员服务提供者（MSP）是一个旨在提供成员操作体系结构抽象的组件。MSP抽象出发布和验证证书以及用户身份验证背后的所有加密机制和协议。MSP可以定义他们自己的身份概念，以及管理这些身份（身份验证）和身份验证（签名生成和验证）的规则。
一个区块链网络可以由多个MSP管理，这提供了成员资格操作的模块化，以及跨不同成员标准和体系结构的互操作性。一个MSP包含如下组件：
- identity格式，即证书格式，以及可选的生成生identity的算法
- 与identity对应的签名的算法，将identity序列化的方法。
- 签名验证算法，算法输入identity，消息，签名，判断签名和identity是否匹配，匹配就输出“接受”，否则输出“拒绝”。
- 一组判断identity是否符合MSP要求的验证规则。
- 一组管理者identity，管理者可以修改MSP的配置信息。
1.2.1 MSP配置
要设置MSP的实例，需要在每个对等方和订货方本地指定其配置（以启用对等方和订货方签名），并在通道上指定其配置，以启用对等方，订货方，客户端标识验证以及相应的签名验证（身份验证） ）和所有渠道成员。
首先，对于每一个MSP名称需要以引用MSP在网络中指定（例如msp1，org2和org3.divA）。这是在一个渠道中引用代表联合体，组织或组织部门的MSP的成员资格规则的名称。这也称为MSP标识符或MSP ID。MSP标识符必须是每个MSP实例唯一的。例如，在系统通道创建时，不应检测到具有相同标识符的两个MSP实例，否则设置器将失败。
在默认实现MSP的情况下，需要指定一组参数以允许身份（证书）验证和签名验证。这些参数由RFC5280推导 ，包括：
- 构成信任根的自签名（X.509）证书列表
- 用于表示此提供程序考虑用于证书验证的中间CA的X.509证书列表; 这些证书应该由信任根证书中的一个证书进行认证; 中间CA是可选参数
- 具有可验证证书路径的X.509证书列表，该证书路径恰好是信任根证书之一，代表此MSP的管理员; 这些证书的所有者被授权请求更改此MSP配置（例如，根CA，中间CA）
- 本MSP的有效成员应在其X.509证书中包含的组织单位列表; 这是一个可选的配置参数，用于例如多个组织利用相同的信任根和中间CA，并为其成员保留OU字段时
- 证书撤销列表（CRL）列表，每个列表对应于列出的（中间或根）MSP证书颁发机构中的一个; 这是一个可选参数
- 自签名（X.509）证书列表，构成TLS证书的TLS信任根。
- 用于表示此提供程序考虑的中间TLS CA的X.509证书列表; 这些证书应该由TLS信任根证书中的一个证书进行认证; 中间CA是可选参数。
此MSP实例的有效标识需要满足以下条件：
- 它们采用X.509证书的形式，具有可验证的证书路径，其中只有一个信任证书的根目录;
- 它们不包括在任何CRL中;
- 并且他们在X.509证书结构的字段中列出了MSP配置的一个或多个组织单位
OU（在启用node_ou情况下）。
有关当前MSP实施中身份有效性的更多信息，我们将读者引用到MSP身份有效性规则。
除了与验证相关的参数之外，为了使MSP能够对其实例化的节点进行签名或认证，需要指定：
- 用于节点签名的签名密钥（目前仅支持ECDSA密钥），以及
- 节点的X.509证书，即此MSP验证参数下的有效标识。
值得注意的是，MSP身份永不过期(x509证书上带有有效期，但是对于msp来说，如果我不校验它们的有效期信息，那么它们就是“不过期”的，需要确定下他是不是这个意思，可能出于的考虑是替换一套根证书非常麻烦); 它们只能通过将它们添加到适当的CRL来撤销。此外，目前不支持强制撤销TLS证书。
1.2.2 peer和orderer的msp设置（local msp设置）
要设置本地MSP（针对同级或订购者），管理员应创建一个$MY_PATH/mspconfig包含六个子文件夹和一个文件的文件夹（例如）：
一个admincerts文件夹，其中包含每个对应于管理员证书的PEM文件（1.4.3版本后启用node_ou后，带admin的ou即会被认为是admin证书，可以不配置在channel设置中）
一个cacerts文件夹，其中包含了每个对应于根CA证书的PEM文件
一个intermediatecerts文件夹（可选），其中包含对应每个中间CA的证书的PEM文件
一个config.yaml文件（可选），其中配置了所有的OUs（组织单元）信息，OUs也就是yaml文件中定义的OrganizationalUnitIdentifier（组织单元ID）数组的集合，即OrganizationalUnitIdentifiers。其中需要考虑到如何证实成员们属于组织成员，证书授权配置了的证书的相对路径（例如,/cacerts/cacert.pem），并且在X.509证书的OU（ Organizational Units/组织单元）字段中将出现OrganizationalUnitIdentifier代表的实际的字符串（例如“COP”）。（这个文件会被global msp生成工具消费，最终格式化成全局msp的内容项）
一个crls文件夹（可选），其中包含了被考虑的CRLs
一个keystore文件夹，其中包含了一个带有节点签名密钥的PEM文件；官方强调当前的RSA密钥不受支持
一个signcerts文件夹，其中包含了一个带有节点的X.509证书的PEM文件
一个tlscacerts文件夹（可选），其中包含了对应于每个TLS根CA证书的PEM文件
一个tlsintermediatecerts文件夹（可选），其中包含了对应于每个TLS中间CA证书的PEM文件
在节点的配置文件（对等方的core.yaml文件，订购者的orderer.yaml）中，需要指定mspconfig文件夹的路径以及节点MSP的MSP标识符。到mspconfig文件夹的路径被预期为相对于FABRIC_CFG_PATH和被提供作为参数值mspConfigPath的对等体，以及LocalMSPDir 用于订货人。节点MSP的标识符作为localMspId对等体和LocalMSPID对于订购者。可以通过环境使用对等方的CORE前缀（例如CORE_PEER_LOCALMSPID）和订购者的ORDERER前缀（例如ORDERER_GENERAL_LOCALMSPID）在环境中覆盖这些变量。请注意，对于订购者设置，需要生成一个并将其提供给订购者系统通道的创始块。下一节将详细介绍此模块的MSP配置需求。
重新配置 “本地” MSP只能手动进行，并且需要重新启动对等方或订购方过程。在后续版本中，我们旨在提供在线/动态重新配置（即，无需通过使用节点管理的系统链码来停止节点）【注：当前版本为2.0alpha还未提供此功能 2019.10.31】。
1.2.3 本地msp与全局msp
全局msp（channel msp和联盟msp）是本地 msp公共部分的集合。一个本地 msp里的内容只有包含在全局msp配置里才能在系统中生效。
本地msp 是peer和orderer在工作是需要的自己的证书等信息。比如对peer来说包含它自己的tls证书，包括peer的x509证书和私钥用于背书时签名，包括ca的根证书等等。
1.2.2身份分类
默认的MSP实现允许组织根据其x509证书的OU进一步将身份分类为client，admin，peer和orderer。
- 如果身份在网络上进行交易，则应将其归类为client。
- 如果标识处理管理任务（例如将对等方加入通道或签署通道配置更新事务），则应将其归类为admin。
- 如果身份背书交易，则应将其归类为peer。
- 如果属于ordering 节点，则应将标识归类为orderer。
1.2.3 channel MSP设置
在系统的起源时，需要指定网络中出现的所有MSP的验证参数，并将其包含在系统通道的创建块中。回想一下，MSP验证参数包括MSP标识符，信任证书根，中间CA和管理证书，以及OU规范和CRL。系统创建块在其设置阶段提供给订货人，并允许他们验证通道创建请求。如果后者包括两个具有相同标识符的MSP，那么Orderers将拒绝系统创建块，因此网络的引导将失败。
对于应用程序通道，仅管理通道的MSP的验证组件需要驻留在通道的创建块中。我们强调，应用程序有责任确保在指示一个或多个对等方加入信道之前，将正确的MSP配置信息包含在信道的创世块（或最新的配置块）中。
在configtxgen工具的帮助下引导通道时，可以通过在mspconfig文件夹中包含MSP的验证参数并在相关部分中设置该路径来配置通道MSP configtx.yaml。
在通道上重新配置 MSP，包括与该MSP的CA相关联的证书撤销列表的通知，是通过MSP config_update的一个管理员证书的所有者创建对象来实现的。然后，管理员管理的客户端应用程序会将此更新通知给出现此MSP的通道。
1.3 msp与权限控制
以channel为例来讲。后面内容展开叙述比较复杂，就先在这里提一下
1.3.1 principle与msp
principle可以看做身份类型。定义的是一个具体身份证书与msp中定义的身份类型的对应规则。
1.3.2 acl与policy
policy定义的的是一个策略由哪几种身份类型组合、门限签名规则。
acl定义某个权限点对应到哪个policy。
某个调用（接口、功能）检查哪个权限点是在代码里写死的。
2. x509介绍
2.1 x509协议
2.1.1 证书结构
X.509 v3 数字证书的结构如下：
- 证书
- 版本号
- 序列号
- 签名算法ID
- 发行人名称
- 有效期
- 在此时间之后：时间
- 再此时间之前：时间
- 主题名称
- 主题公钥信息
- 公钥算法
- 主题公钥
- 发行人唯一标识符（可选）
- 主题唯一标识符（可选）
- 扩展（可选）
- ...
- 证书签名算法
- 证书签名
每个扩展都有自己的ID，表示为对象标识符，它是一组值，以及关键或非关键指示。如果证书使用系统遇到无法识别的关键扩展，或者包含无法处理的信息的关键扩展，则必须拒绝该证书。如果无法识别，则可以忽略非关键扩展，但如果识别则必须进行处理。[4]
版本3中引入了扩展.CA可以使用扩展仅为特定目的颁发证书（例如，仅用于签署数字对象）。在所有版本中，特定CA颁发的每个证书的序列号必须是唯一的（如RFC 5280中所述）。
2.1.2 hyperledger证书结构
hyperledger证书示例：
{"name":"admin","mspid":"org1MSP","roles":null,"affiliation":"","enrollmentSecret":"","enrollment":{"signingIdentity":"854a70865d8657d1bd961a7ff5cfcbf622e0017fdcbdb22f10fb38a948b59d41","identity":{"certificate":"-----BEGIN CERTIFICATE-----\nMIICAjCCAaigAwIBAgIUUxvuFVOuFGBtqQeWj6t2xhZF7XQwCgYIKoZIzj0EAwIw\nczELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNh\nbiBGcmFuY2lzY28xGTAXBgNVBAoTEG9yZzEuZXhhbXBsZS5jb20xHDAaBgNVBAMT\nE2NhLm9yZzEuZXhhbXBsZS5jb20wHhcNMTkwOTAzMDI0MDAwWhcNMjAwOTAyMDI0\nNTAwWjAhMQ8wDQYDVQQLEwZjbGllbnQxDjAMBgNVBAMTBWFkbWluMFkwEwYHKoZI\nzj0CAQYIKoZIzj0DAQcDQgAEyxdVePjjQWmpmfUnePtl9xcCOkUK+3aXSaCfM6KR\nF9940nI87STkvFzHJktngrWMUYejdtHpcbKQOA7AjAV9baNsMGowDgYDVR0PAQH/\nBAQDAgeAMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFPtNazUxWF7V29nvpc8mSqQ2\nxtYiMCsGA1UdIwQkMCKAIK3H2QbihBwpsni3sE7DjJSL87hrWEdfgAFqnWhd1/hz\nMAoGCCqGSM49BAMCA0gAMEUCIQDuHLQGuo5RNodb9dPvkl+pSQqjsAJUEivgGMek\nwxNThgIgQ7jS4o6UIAxs4TAnq0sOBJgndMPX2Ug0fOAEYR+VV6E=\n-----END CERTIFICATE-----\n"}}}
除了x509证书信息外还会包含一些用于业务的辅助信息。
- signingIdentity对应的是公私钥证书文件索引。
- 其中身份证书（identity certificate）部分（对于hyperledger来说，链上接口获取到的是mspid+identity certificate），存的是x509证书，将证书信息解析后形成如下可读形式，其中//后的部分是为了解释各个字段后来加的备注信息。
Certificate:
Data:
Version: 3 (0x2)
Serial Number://序列号，对同一CA所颁发的证书，序列号唯一标识证书
53:1b:ee:15:53:ae:14:60:6d:a9:07:96:8f:ab:76:c6:16:45:ed:74
Signature Algorithm: ecdsa-with-SHA256
Issuer: C=US, ST=California, L=San Francisco, O=org1.example.com, CN=ca.org1.example.com//签发者信息
Validity//有效期信息
Not Before: Sep 3 02:40:00 2019 GMT
Not After : Sep 2 02:45:00 2020 GMT
Subject: OU=client, CN=admin//自己的证书主要信息
Subject Public Key Info://公钥信息，包括签名算法
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:cb:17:55:78:f8:e3:41:69:a9:99:f5:27:78:fb:
65:f7:17:02:3a:45:0a:fb:76:97:49:a0:9f:33:a2:
91:17:df:78:d2:72:3c:ed:24:e4:bc:5c:c7:26:4b:
67:82:b5:8c:51:87:a3:76:d1:e9:71:b2:90:38:0e:
c0:8c:05:7d:6d
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions://扩展信息
X509v3 Key Usage: critical//证书作用Digital Signature:表明此证书只能对数据进行签名(除此之外还有certificate signing、 CRL signing；Key Encipherment。其中Key Encipherment代表可以进行秘钥传输即ssl通信)
Digital Signature
X509v3 Basic Constraints: critical//指示证书是否为证书颁发机构（Certificate Authority），此条表明此证书不是ca不能签发下级证书，
CA:FALSE
X509v3 Subject Key Identifier: //SKI本证书的秘钥标志符，通常由公钥信息生成，可以唯一标记对应到本证书，
FB:4D:6B:35:31:58:5E:D5:DB:D9:EF:A5:CF:26:4A:A4:36:C6:D6:22
X509v3 Authority Key Identifier: //AKI授权密钥标识符，颁发证书的SKI值，可以唯一对应(校验)到颁发证书
keyid:AD:C7:D9:06:E2:84:1C:29:B2:78:B7:B0:4E:C3:8C:94:8B:F3:B8:6B:58:47:5F:80:01:6A:9D:68:5D:D7:F8:73
//标识扩展是一种标识，表示在证书中标识为颁发者名称一部分的组织。The Logotype extension is a logotype representing the organization identified as part of the issuer name in the certificate.
//1.2.3.4.5.6.7.8.1:
//{"attrs":{"hf.Affiliation":"org1","hf.EnrollmentID":"3","hf.Type":"client"}}
Signature Algorithm: ecdsa-with-SHA256//发证的ca的签名
30:45:02:21:00:ee:1c:b4:06:ba:8e:51:36:87:5b:f5:d3:ef:
92:5f:a9:49:0a:a3:b0:02:54:12:2b:e0:18:c7:a4:c3:13:53:
86:02:20:43:b8:d2:e2:8e:94:20:0c:6c:e1:30:27:ab:4b:0e:
04:98:27:74:c3:d7:d9:48:34:7c:e0:04:61:1f:95:57:a1
- Subject Key Identifier
SKI通常是公钥信息hash
2.2 以tls为例讲解证书发放、验证过程
本部分内容主要是讲解验证是什么流程格式，hyperledger中证书链的获取形式与浏览器获取网页的不同。
以下内容大部分整理自这里
发放
如果用户想得到一份属于自己的证书，他应先向 CA 提出申请。在 CA 判明申请者的身份后，便为他分配一个公钥，并且 CA 将该公钥与申请者的身份信息绑在一起，并为之签名后，便形成证书发给申请者。
如果一个用户想鉴别另一个证书的真伪，他就用签发那个证书CA 的公钥对那个证书上的签字进行验证，一旦验证通过，该证书就被认为是有效的。
根认证机构的构建
- 根认证机构「CA」生成公钥 ca_KeyPub 和私钥 ca_KeyPri，以及基本信息表 ca_Info。ca_Info 中一般包含了「CA」的名称、证书的有效期等信息。
- 根认证机构「CA」对（ca_KeyPub + ca_Info）进行散列运算，得到散列值 ca_Hash。
- 根认证机构「CA」使用其私钥 ca_KeyPri 对 ca_Hash 进行非对称加密，得到加密的散列值 enc_ca_Hash。
- 根认证机构「CA」将（ca_KeyPub + ca_Info + enc_ca_Hash）组合生成自签名的数字证书「ca_Cert」。这张证书称之为根证书，也就是说根证书实质上是一个自签名的证书。
根证书「ca_Cert」包含的内容：ca_KeyPub + ca_Info + enc_ca_Hash。
单级认证机构是签名是由根证书签名的，二级认证机构是证书是由中间证书签名的。因此只介绍下二级和多级认证机构的构建。
二级（或以上）认证机构的构建
- 二级认证机构「CA2」生成公钥 ca2_KeyPub 和私钥 ca2_KeyPri，以及基本信息表 ca2_Info。ca2_Info 中一般包含了「CA2」的名称、证书要求的有效期、证书功能扩展等信息。
- 二级认证机构「CA2」将 ca2_KeyPub、ca2_Info 送给根认证机构「CA」。
- 根认证机构「CA」通过某种方式验证「CA2」的身份之后，再加上根认证机构自己的一些信息 ca_Info（Issuer，AKI），然后对它们（ca2_KeyPub + ca2_Info + ca_Info）进行散列运算，得到散列值 ca2_Hash。
- 根认证机构「CA」使用其私钥 ca_KeyPri 对 ca2_Hash 进行非对称加密，得到加密的散列值 enc_ca2_Hash。
- 根认证机构「CA」将（ca2_KeyPub + ca2_Info + ca_Info + enc_ca2_Hash）组合签署成数字证书「ca2_Cert」并回送给「CA2」。
二级认证机构证书「ca2_Cert」包含的内容：ca2_KeyPub + ca2_Info + ca_Info + enc_ca2_Hash。
「ca2_Cert」可用于签署下一级的证书。
二级（或以上）认证机构的证书签署
- 服务器「S2」生成公钥 s2_KeyPub 和私钥 s2_KeyPri，以及基本信息表 s2_Info。s2_Info 中一般包含了「S2」的名称、证书要求的有效期等信息。
- 服务器「S2」将 s2_KeyPub、s2_Info 送给二级认证机构「CA2」。
- 二级认证机构「CA2」通过某种方式验证「S2」的身份之后，再加上根认证机构自己的一些信息 ca2_Info，然后对它们（s2_KeyPub + s2_Info + ca2_Info）进行散列运算，得到散列值 s2_Hash。
二级认证机构「CA2」使用其私钥 ca2_KeyPri 对 s2_Hash 进行非对称加密，得到加密的散列值 enc_s2_Hash。 - 二级认证机构「CA2」将（s2_KeyPub + s2_Info + ca2_Info + enc_s2_Hash）组合签署成数字证书「s2_Cert」并回送给「S2」。
- 服务器证书「s2_Cert」包含的内容：s2_KeyPub + s2_Info + ca2_Info + enc_s2_Hash。
「s2_Cert」不可用于签署下一级的证书。
从上面可以看出，证书签署的流程是：「ca_Cert」-> 「ca2_Cert」->「s2_Cert」。它是一条完整的链条，我们把它称之为 「证书链」。
验证
收方在收到信息后用如下的步骤验证您的签名：
- 使用自己的私钥将信息转为明文；
- 使用发信方的公钥从数字签名部分得到原摘要；
- 收方对您所发送的源信息进行hash运算，也产生一个摘要；
- 收方比较两个摘要，如果两者相同，则可以证明信息签名者的身份。
如果两摘要内容不符，会说明什么原因呢？
可能对摘要进行签名所用的私钥不是签名者的私钥，这就表明信息的签名者不可信；也可能收到的信息根本就不是签名者发送的信息，信息在传输过程中已经遭到破坏或篡改。
作用：
- 保密性 - 只有收件人才能阅读信息。
- 认证性 - 确认信息发送者的身份。
- 完整性 - 信息在传递过程中不会被篡改。
- 不可抵赖性 - 发送者不能否认已发送的信息。
单级认证机构的验证
（假设根认证机构「CA」的根证书「ca_Cert」已经安装到操作系统中且被信任。下同。）
- 服务器「S」下发证书「s_Cert」给客户端「C」。
- 客户端「C」检查到「s_Cert」中的 ca_Info，发现它是由「CA」签署的。
- 客户端「C」取出「ca_Cert」中的 ca_KeyPub，对「s_Cert」中的 enc_s_Hash 进行解密得到 s_Hash。
- 客户端「C」对「s_Cert」中的（s_KeyPub + s_Info + ca_Info）进行散列运算，得到散列值 s_Hash_tmp。
- 客户端「C」判断 s_Hash 和 s_Hash_tmp 是否相等。如果两者相等，则证明「s_Cert」是由「ca_Cert」签署的。
- 客户端「C」检查「ca_Cert」，发现该证书是根证书，且已经被系统信任，身份验证通过。
二级（或以上）认证机构的验证
- 服务器「S2」下发证书「s2_Cert」、「ca2_Cert」给客户端「C」。
- 客户端「C」检查到「s2_Cert」中的 ca2_Info，发现它是由「CA2」签署的。
- 客户端「C」取出「ca2_Cert」中的 ca2_KeyPub，对「s2_Cert」中的 enc_s2_Hash 进行解密得到 s2_Hash。
- 客户端「C」对「s2_Cert」中的（s2_KeyPub + s2_Info + ca2_Info）进行散列运算，得到散列值 s2_Hash_tmp。
- 客户端「C」判断 s2_Hash 和 s2_Hash_tmp 是否相等。如果两者相等，则证明「s2_Cert」是由「ca2_Cert」签署的。
- 客户端「C」检查到「ca2_Cert」中的 ca_Info，发现它是由「CA」签署的。
- 客户端「C」取出「ca_Cert」中的 ca_KeyPub，对「ca2_Cert」中的 enc_ca2_Hash 进行解密得到 ca2_Hash。
- 客户端「C」对「ca2_Cert」中的（ca2_KeyPub + ca2_Info + ca_Info）进行散列运算，得到散列值 ca2_Hash_tmp。
- 客户端「C」判断 ca2_Hash 和 ca2_Hash_tmp 是否相等。如果两者相等，证明「ca2_Cert」是由「ca_Cert」签署的。
- 客户端「C」检查「ca_Cert」，发现该证书是根证书，且已经被系统信任，身份验证通过。
3. fabric ca介绍
因为CA非常重要，Fabric提供了一个内置的CA组件，允许您在您构成的区块链网络中创建CA。此组件（称为Fabric CA）是一个私有根CA管理程序，能够管理具有X.509证书形式的Fabric参与者的数字身份。由于Fabric CA是针对Fabric的根CA需求的自定义CA，因此它本身无法为浏览器中的常规/自动使用提供SSL证书。但是，由于某些 CA必须用于管理身份（即使在测试环境中），因此可以使用Fabric CA来提供和管理证书。使用公共/商业根或中间CA来提供识别也是可能的 - 并且完全合适。
如果您有兴趣，可以在CA文档部分中阅读有关Fabric CA的更多信息 。
注：fabric ca并没有实现全部功能，部分信息的同步需要手动在ca和hyperledger网络中，比如crl和中间ca的信息同步。
