User Tools

Site Tools

| 原文 | 作者 | 审核修正 | | --- | --- | —--- | | 原文 | Dinghao Liu | Yunxiao Wang, Bei Wang |

成员服务提供者 (MSP)

The document serves to provide details on the setup and best practices for MSPs.


Membership service provider (MSP) is a component that aims to offer an abstraction of a membership operation architecture.


In particular, MSP abstracts away all cryptographic mechanisms and protocols behind issuing and validating certificates, and user authentication. An MSP may define their own notion of identity, and the rules by which those identities are governed (identity validation) and authenticated (signature generation and verification).


A Hyperledger Fabric blockchain network can be governed by one or more MSPs. This provides modularity of membership operations, and interoperability across different membership standards and architectures.

一个Hyperledger Fabric区块链网络可以被一个或多个MSP管理。这提供了模块化的成员操作,以及兼容不同成员标准与架构的互操作性。

In the rest of this document we elaborate on the setup of the MSP implementation supported by Hyperledger Fabric, and discuss best practices concerning its use.

接下来我们将详细说明在Hyperledger Fabric支持下的MSP的实现步骤,并讨论其使用方面的最佳实践方式。


To setup an instance of the MSP, its configuration needs to be specified locally at each peer and orderer (to enable peer, and orderer signing), and on the channels to enable peer, orderer, client identity validation, and respective signature verification (authentication) by and for all channel members.


Firstly, for each MSP a name needs to be specified in order to reference that MSP in the network (e.g. msp1, org2, and org3.divA). This is the name under which membership rules of an MSP representing a consortium, organization or organization division is to be referenced in a channel. This is also referred to as the MSP Identifier or MSP ID. MSP Identifiers are required to be unique per MSP instance. For example, shall two MSP instances with the same identifier be detected at the system channel genesis, orderer setup will fail.

首先, 为了方便地在网络中引用MSP,每个MSP都需要一个特定的名字(例如msp1org2org3.divA)。在一个channel中,当MSP的成员管理规则表示一个团体,组织或组织分工时,该名称会被引用。这又被成为MSP标识符或MSP ID。对于每个MSP实例,MSP标识符都必须独一无二。举个例子:系统channel创建时如果检测到两个MSP有相同的标识符,那么orderer节点的启动将以失败告终。

In the case of default implementation of MSP, a set of parameters need to be specified to allow for identity (certificate) validation and signature verification. These parameters are deduced by RFC5280, and include:


  • A list of self-signed (X.509) certificates to constitute the root of trust

    • 一个自签名的证书列表(满足X.509标准)以构成信任源
  • A list of X.509 certificates to represent intermediate CAs this provider considers for certificate validation; these certificates ought to be certified by exactly one of the certificates in the root of trust; intermediate CAs are optional parameters

    • 一个用于表示该MSP验证过的中间CA的X.509的证书列表,用于证书的校验。这些证书应该被信任源的一个证书所认证;中间的CA则是可选参数
  • A list of X.509 certificates with a verifiable certificate path to exactly one of the certificates of the root of trust to represent the administrators of this MSP; owners of these certificates are authorized to request changes to this MSP configuration (e.g. root CAs, intermediate CAs)

    • 一个具有可验证路径的X.509证书列表(该路径通往信任源的一个证书),以表示该MSP的管理员。这些证书的所有者对MSP配置的更改要求都是经过授权的(例如根CA,中间CA)
  • A list of Organizational Units that valid members of this MSP should include in their X.509 certificate; this is an optional configuration parameter, used when, e.g., multiple organisations leverage the same root of trust, and intermediate CAs, and have reserved an OU field for their members

    • 一个组织单元列表,该MSP的合法成员应该将其包含进他们的X.509证书。这是一个可选的配置参数,举个例子:当多个组织使用相同信任源、中间CA以及组织为他们的成员保留了一个OU区的时候,会配置此参数
  • A list of certificate revocation lists (CRLs) each corresponding to exactly one of the listed (intermediate or root) MSP Certificate Authorities; this is an optional parameter

    • 一个证书吊销列表(CRLs)的清单,清单的每一项对应于一个已登记的(中间的或根)MSP证书颁发机构(CA),这是一个可选的参数
  • A list of self-signed (X.509) certificates to constitute the TLS root of trust for TLS certificate.

    • 一个自签名的证书列表(满足X.509标准)以构成TLS信任源,服务于TLS证书
  • A list of X.509 certificates to represent intermediate TLS CAs this provider considers; these certificates ought to be certified by exactly one of the certificates in the TLS root of trust; intermediate CAs are optional parameters.

    • 一个表示该provider关注的中间TLS CA的X.509证书列表。这些证书应该被TLS信任源的一个证书所认证;中间的CA则是可选参数

Valid identities for this MSP instance are required to satisfy the following conditions:


  • They are in the form of X.509 certificates with a verifiable certificate path to exactly one of the root of trust certificates

    • 它们应符合X.509证书标准,且具有一条可验证的路径(该路径通往信任源的一个证书)
  • They are not included in any CRL

    • 它们没有包含在任何CRL中
  • And they list one or more of the Organizational Units of the MSP configuration in the OU field of their X.509 certificate structure.

    • 它们列出了一个或多个MSP配置的组织单元(列出的位置是它们X.509证书结构的OU区内)。

For more information on the validity of identities in the current MSP implementation we refer the reader to MSP Identity Validity Rules.

关于当前MSP实现过程中身份验证的更多信息,我们隆重推荐各位读者阅读MSP Identity Validity Rules

In addition to verification related parameters, for the MSP to enable the node on which it is instantiated to sign or authenticate, one needs to specify:


  • The signing key used for signing by the node (currently only ECDSA keys are supported), and

    • 用于节点签名的签名密钥(目前只支持ECDSA密钥)
  • The node’s X.509 certificate, that is a valid identity under the verification parameters of this MSP

    • 节点的X.509证书,对MSP验证参数机制而言是一个有效的身份

It is important to note that MSP identities never expire; they can only be revoked by adding them to the appropriate CRLs. Additionally, there is currently no support for enforcing revocation of TLS certificates.



To generate X.509 certificates to feed its MSP configuration, the application can use Openssl. We emphasise that in Hyperledger Fabric there is no support for certificates including RSA keys.

要想生成X.509证书以满足MSP配置,应用程序可以使用Openssl。我们必须强调:在Hyperledger Fabric中,不支持包括RSA密钥在内的证书。

Alternatively one can use cryptogen tool, whose operation is explained in Getting Started.


Hyperledger Fabric CA can also be used to generate the keys and certificates needed to configure an MSP.

Hyperledger Fabric CA也可用于生成配置MSP所需的密钥及证书。

peer&orderer侧 MSP 的设置

To set up a local MSP (for either a peer or an orderer), the administrator should create a folder (e.g. $MY_PATH/mspconfig) that contains six subfolders and a file:


  • a folder admincerts to include PEM files each corresponding to an administrator certificate

    • 文件夹admincerts包含如下PEM文件:每个PEM文件对应于一个管理员证书
  • a folder cacerts to include PEM files each corresponding to a root CA’s certificate

    • 文件夹cacerts包含如下PEM文件:每个PEM文件对应于一个根CA的证书
  • (optional) a folder intermediatecerts to include PEM files each corresponding to an intermediate CA’s certificate

    • (可选)文件夹intermediatecerts包含如下PEM文件:每个PEM文件对应于一个中间CA的证书
  • (optional) a file config.yaml to include information on the considered OUs; the latter are defined as pairs of <Certificate,OrganizationalUnitIdentifier> entries of a yaml array called OrganizationalUnitIdentifiers, where Certificate represents the relative path to the certificate of the certificate authority (root or intermediate) that should be considered for certifying members of this organizational unit (e.g. ./cacerts/cacert.pem), and OrganizationalUnitIdentifier represents the actual string as expected to appear in X.509 certificate OU-field (e.g. “COP”)

    • (可选)文件config.yaml包含相关OU的信息;后者作为<Certificate,OrganizationalUnitIdentifier>(一个被称为OrganizationalUnitIdentifiers的yaml数组的项)的一部分被定义;其中Certificate表示通往(根或中间)CA的证书的相对路径,这些CA用于为组织成员发证(如./cacerts/cacert.pem);OrganizationalUnitIdentifier表示预期会出现在X.509证书中的实际字符串(如“COP”)
  • (optional) a folder crls to include the considered CRLs

    • (可选)文件夹crls包含相关CRL
  • a folder keystore to include a PEM file with the node’s signing key; we emphasise that currently RSA keys are not supported

    • 文件夹keystore包含一个PEM文件及节点的签名密钥;我们必须强调:现阶段还不支持RSA密钥
  • a folder signcerts to include a PEM file with the node’s X.509 certificate

    • 文件夹signcerts包含一个PEM文件及节点的X.509证书
  • (optional) a folder tlscacerts to include PEM files each corresponding to a TLS root CA’s certificate

    • (可选)文件夹tlscacerts包含如下PEM文件:每个PEM文件对应于一个根TLS根CA的证书
  • (optional) a folder tlsintermediatecerts to include PEM files each corresponding to an intermediate TLS CA’s certificate

    • (可选)文件夹tlsintermediatecerts包含如下PEM文件:每个PEM文件对应于一个中间TLS CA的证书

In the configuration file of the node (core.yaml file for the peer, and orderer.yaml for the orderer), one needs to specify the path to the mspconfig folder, and the MSP Identifier of the node’s MSP. The path to the mspconfig folder is expected to be relative to FABRIC_CFG_PATH and is provided as the value of parameter mspConfigPath for the peer, and LocalMSPDir for the orderer. The identifier of the node’s MSP is provided as a value of parameter localMspId for the peer and LocalMSPID for the orderer. These variables can be overriden via the environment using the CORE prefix for peer (e.g. CORE_PEER_LOCALMSPID) and the ORDERER prefix for the orderer (e.g. ORDERER_GENERAL_LOCALMSPID). Notice that for the orderer setup, one needs to generate, and provide to the orderer the genesis block of the system channel. The MSP configuration needs of this block are detailed in the next section.

在节点的配置文件中(对peer节点而言配置文件是core.yaml文件,对orderer节点而言则是orderer.yaml文件),我们需要指定到mspconfig文件夹的路径,以及节点的MSP的MSP标识符。到mspconfig文件夹的路径预期是一个对FABRIC_CFG_PATH的相对路径,且会作为参数mspConfigPathLocalMSPDir的值分别提供给peer节点和orderer节点。节点的MSP的MSP标识符则会作为参数localMspIdLocalMSPID的值分别提供给peer节点和orderer节点。运行环境可以通过为peer使用CORE前缀(例如CORE_PEER_LOCALMSPID)及为orderer使用ORDERER前缀(例如 ORDERER_GENERAL_LOCALMSPID)对以上变量进行覆写。注意:对于orderer的设置,我们需要生成并为orderer提供系统channel的创世区块。MSP配置对该区块的需求详见后面的章节。

Reconfiguration of a “local” MSP is only possible manually, and requires that the peer or orderer process is restarted. In subsequent releases we aim to offer online/dynamic reconfiguration (i.e. without requiring to stop the node by using a node managed system chaincode).


Channel MSP 的设置

At the genesis of the system, verification parameters of all the MSPs that appear in the network need to be specified, and included in the system channel’s genesis block. Recall that MSP verification parameters consist of the MSP identifier, the root of trust certificates, intermediate CA and admin certificates, as well as OU specifications and CRLs. The system genesis block is provided to the orderers at their setup phase, and allows them to authenticate channel creation requests. Orderers would reject the system genesis block, if the latter includes two MSPs with the same identifier, and consequently the bootstrapping of the network would fail.


For application channels, the verification components of only the MSPs that govern a channel need to reside in the channel’s genesis block. We emphasise that it is the responsibility of the application to ensure that correct MSP configuration information is included in the genesis blocks (or the most recent configuration block) of a channel prior to instructing one or more of their peers to join the channel.


When bootstrapping a channel with the help of the configtxgen tool, one can configure the channel MSPs by including the verification parameters of MSP in the mspconfig folder, and setting that path in the relevant section in configtx.yaml.

在configtxgen工具的帮助下引导架设channel时,我们这样来配置channel MSP:将MSP的验证参数加入mspconfig文件夹,并将该路径加入到configtx.yaml文件的相关部分。

Reconfiguration of an MSP on the channel, including announcements of the certificate revocation lists associated to the CAs of that MSP is achieved through the creation of a config_update object by the owner of one of the administrator certificates of the MSP. The client application managed by the admin would then announce this update to the channels in which this MSP appears.



In this section we elaborate on best practices for MSP configuration in commonly met scenarios.


1) Mapping between organizations/corporations and MSPs


We recommend that there is a one-to-one mapping between organizations and MSPs. If a different mapping type of mapping is chosen, the following needs to be to considered:


  • One organization employing various MSPs. This corresponds to the case of an organization including a variety of divisions each represented by its MSP, either for management independence reasons, or for privacy reasons. In this case a peer can only be owned by a single MSP, and will not recognize peers with identities from other MSPs as peers of the same organization. The implication of this is that peers may share through gossip organization-scoped data with a set of peers that are members of the same subdivision, and NOT with the full set of providers constituting the actual organization.

    • 一个组织对应多个MSP。这对应于下面这种情况:(无论出于独立管理的原因还是私人原因)一个组织有各种各样的部门,每个部门以其MSP为代表。在这种情况下,一个peer节点只能被单个MSP拥有,且不会识别相同组织内标识在其他MSP的节点。这就是说,peer节点可以与相同子分支下的一系列其他peer节点共享组织数据,而不是所有构成组织的节点。
  • Multiple organizations using a single MSP. This corresponds to a case of a consortium of organisations that are governed by similar membership architecture. One needs to know here that peers would propagate organization-scoped messages to the peers that have an identity under the same MSP regardless of whether they belong to the same actual organization. This is a limitation of the granularity of MSP definition, and/or of the peer’s configuration.

    • 多个组织对应一个MSP。这对应于下面这种情况:一个由相似成员结构所管理的组织联盟。这时,peer节点可以与相同MSP下的其他节点互发组织范围的数据,节点是否属于同一组织并不重要。这对于MSP的定义及peer节点的配置是个限制。

2) One organization has different divisions (say organizational units), to which it wants to grant access to different channels.



  • Define one MSP to accommodate membership for all organization’s members. Configuration of that MSP would consist of a list of root CAs, intermediate CAs and admin certificates; and membership identities would include the organizational unit (OU) a member belongs to. Policies can then be defined to capture members of a specific OU, and these policies may constitute the read/write policies of a channel or endorsement policies of a chaincode. A limitation of this approach is that gossip peers would consider peers with membership identities under their local MSP as members of the same organization, and would consequently gossip with them organisation-scoped data (e.g. their status).

    • 定义一个MSP来容纳所有组织的全部成员。MSP的配置包含一个根CA、中间CA和管理员证书的列表;成员身份会包含一个组织单元(OU)的所属关系。接下来可以定义用于获取特定OU成员的策略,这些策略可以建立channel的读写策略或者chaincode的背书策略。这种方法的局限是gossip peer节点会本地MSP下的其他peer节点当做相同组织内的成员,并与之分享组织范围内的数据。
  • Defining one MSP to represent each division. This would involve for each division, a set of certificates for root CAs, intermediate CAs, and admin specifying Certs, such that there is no overlapping certification path across MSPs. This would mean that, for example, a different intermediate CA per subdivision is employed. Here the disadvantage is the management of more than one MSPs instead of one, but this circumvents the issue present in the previous approach. One could also define one MSP for each division by leveraging an OU extension of the MSP configuration.

    • 定义一个MSP来表示每个分支。这需要为每个分支引入一组根CA证书、中间CA证书和管理员证书,这样每条通往MSP的路径都不会重叠。这意味着,每个子分支的不同中间CA都会被利用起来。这样做的缺点是要管理多个MSP,不过这避免了前面方法出现的问题。我们也可以利用MSP配置的OU扩展来为每个分支定义一个MSP。

3) Separating clients from peers of the same organization.


In many cases it is required that the “type” of an identity is retrievable from the identity itself (e.g. it may be needed that endorsements are guaranteed to have derived by peers, and not clients or nodes acting solely as orderers).


There is limited support for such requirements.


One way to allow for this separation is to to create a separate intermediate CA for each node type - one for clients and one for peers/orderers; and configure two different MSPs - one for clients and one for peers/orderers. Channels this organization should be accessing would need to include both MSPs, while endorsement policies will leverage only the MSP that refers to the peers. This would ultimately result in the organization being mapped to two MSP instances, and would have certain consequences on the way peers and clients interact.


Gossip would not be drastically impacted as all peers of the same organization would still belong to one MSP. Peers can restrict the execution of certain system chaincodes to local MSP based policies. For example, peers would only execute “joinChannel” request if the request is signed by the admin of their local MSP who can only be a client (end-user should be sitting at the origin of that request). We can go around this inconsistency if we accept that the only clients to be members of a peer/orderer MSP would be the administrators of that MSP.

由于所以同一组织的peer节点仍属于相同的MSP,所以通讯不会受到严重影响。peer节点可以把特定系统chaincode的执行控制在本地MSP的策略范围内。例如:只有请求被本地MSP的管理员签署(其只能是一个客户),peer节点才会执行“joinChannel”的请求(终端用户应该处于该请求的起点)。如果我们接受这样一个前提:只有客户成为MSP peer节点或orderer节点的一员,才能成员MSP的管理员,那么我们就可以绕过这个矛盾。

Another point to be considered with this approach is that peers authorize event registration requests based on membership of request originator within their local MSP. Clearly, since the originator of the request is a client, the request originator is always doomed to belong to a different MSP than the requested peer and the peer would reject the request.


4) Admin and CA certificates.


It is important to set MSP admin certificates to be different than any of the certificates considered by the MSP for root of trust, or intermediate CAs. This is a common (security) practice to separate the duties of management of membership components from the issuing of new certificates, and/or validation of existing ones.


5) Blacklisting an intermediate CA.


As mentioned in previous sections, reconfiguration of an MSP is achieved by reconfiguration mechanisms (manual reconfiguration for the local MSP instances, and via properly constructed config_update messages for MSP instances of a channel). Clearly, there are two ways to ensure an intermediate CA considered in an MSP is no longer considered for that MSP’s identity validation:


  • Reconfigure the MSP to no longer include the certificate of that intermediate CA in the list of trusted intermediate CA certs. For the locally configured MSP, this would mean that the certificate of this CA is removed from the intermediatecerts folder.

    • 重新配置MSP并使它的信任中间CA证书列表不再包含该中间CA的证书。对于本地重新配置的MSP,这意味着该CA的证书从intermediatecerts文件夹中被删除了。
  • Reconfigure the MSP to include a CRL produced by the root of trust which denounces the mentioned intermediate CA’s certificate.

    • 重新配置MSP并使它包含由信任源产生的CRL,该CRL会通知MSP废止中间CA证书的使用。

In the current MSP implementation we only support method (1) as it is simpler and does not require blacklisting the no longer considered intermediate CA.


**5) CAs and TLS CAs

**5) CA 和 TLS CA

MSP identities’ root CAs and MSP TLS certificates’ root CAs (and relative intermediate CAs) need to be declared in different folders. This is to avoid confusion between different classes of certificates. It is not forbidden to reuse the same CAs for both MSP identities and TLS certificates but best practices suggest to avoid this in production.

MSP 身份的根CA及MSP TLS证书的根CA(以及相关的中间CA)需要在不同的文件夹中声明。这是为了避免混淆不同等级的证书。且MSP身份与TLS证书都允许重用相同的CA,不过我们建议最好在实际中避免这样做。

groups/twgc/fabric-doc/ · Last modified: 2017/09/07 13:18 by Dinghao Liu