本文是MSP详解的第二部分，我们通过第一部分对MSP有了初步的认识，下面我们来通过peer和order节点来对MSP做一个详细的讲解
本文会以下面的结构展开：
一，生成公私钥和证书信息
生成证书和公私钥的过程
Fabric中有两种类型的公私钥和证书，一种是给节点之间，为了通讯安全而准备的TLS证书，另一种是用户登录和权限控制的用户证书。这些证书本来应该是由CA来颁发，但是我们这里是测试环境，并没有启用CA节点，这里我们使用：cryptogen来生成这两种证书。我们生成的公私钥和证书是依据配置文件crypto-config.yaml文件来生成的。关于该文件的详细介绍，参见《HyperLedger-Fabric1.0原理-Fabric网络搭建过程之配置文件》一文，这里不再赘述。
1 cryptogen generate --config=./crypto-config.yaml
e2e_cli例子中，生成的的网络拓扑结构如下图所示。
该命令会生成一个名为crypto-config的文件夹，该文件夹是基于Fabric网络的拓扑结构而来的：
二，目录解析
生成的文件都保存到crypto-config文件夹，我们可以进入该文件夹查看生成了哪些文件：
查看当前目录下的crypto-config目录，生成ordererOrganizations和peerOrganizations两棵组织树。
以peerOrganizations为例，该目录下有两个目录org1.example.com和org2.example.com。分别对应通道中Org1和Org2的相关证书和签名。
每个组织树下都包括ca、msp、orderers（或peers）、tlsca、users五个子目录。
org1.example.com表示Org1组织。
在peers目录下，有两个子目录peer0.org1.example.com和peer1.org1.example.com包含了这两个节点的msp配置信息。
接下来以org1.example.com组织树为例，每个目录和文件对应的功能讲解。
org1.example.com/
├── ca # 存放组织Org1的根证书和对应的私钥文件，默认采用EC算法，证书为自签名。组织内的实体将基于该根证书作为证书根。
│ ├── ca.org1.example.com-cert.pem
│ └── dfb841b77804d726eea25231ae5e89a31901ca0538688a6d764731148f0bdc5b_sk
├── msp # 存放代表该组织的身份信息。
│ ├── admincerts # 组织管理员的身份验证证书，被根证书签名。
│ │ └── Admin@org1.example.com-cert.pem
│ ├── cacerts # 组织的根证书，同ca目录下文件。
│ │ └── ca.org1.example.com-cert.pem
│ └── tlscacerts # 用于TLS的CA证书，自签名。
│ └── tlsca.org1.example.com-cert.pem
├── peers # 存放属于该组织的所有Peer节点
│ ├── peer0.org1.example.com # 第一个peer的信息，包括其msp证书和tls证书两类。
│ │ ├── msp # msp相关证书
│ │ │ ├── admincerts # 组织管理员的身份验证证书。Peer将基于这些证书来认证交易签署者是否为管理员身份。
│ │ │ │ └── Admin@org1.example.com-cert.pem
│ │ │ ├── cacerts # 存放组织的根证书
│ │ │ │ └── ca.org1.example.com-cert.pem
│ │ │ ├── keystore # 本节点的身份私钥，用来签名
│ │ │ │ └── 59be216646c0fb18c015c58d27bf40c3845907849b1f0671562041b8fd6e0da2_sk
│ │ │ ├── signcerts # 验证本节点签名的证书，被组织根证书签名
│ │ │ │ └── peer0.org1.example.com-cert.pem
│ │ │ └── tlscacerts # TLS连接用到身份证书，即组织TLS证书
│ │ │ └── tlsca.org1.example.com-cert.pem
│ │ └── tls # tls相关证书
│ │ ├── ca.crt # 组织的根证书
│ │ ├── server.crt # 验证本节点签名的证书，被组织根证书签名
│ │ └── server.key # 本节点的身份私钥，用来签名
│ └── peer1.org1.example.com # 第二个peer的信息，结构类似。（此处省略。）
│ ├── msp
│ │ ├── admincerts
│ │ │ └── Admin@org1.example.com-cert.pem
│ │ ├── cacerts
│ │ │ └── ca.org1.example.com-cert.pem
│ │ ├── keystore
│ │ │ └── 82aa3f8f9178b0a83a14fdb1a4e1f944e63b72de8df1baeea36dddf1fe110800_sk
│ │ ├── signcerts
│ │ │ └── peer1.org1.example.com-cert.pem
│ │ └── tlscacerts
│ │ └── tlsca.org1.example.com-cert.pem
│ └── tls
│ ├── ca.crt
│ ├── server.crt
│ └── server.key
├── tlsca # 存放tls相关的证书和私钥。
│ ├── 00e4666e5f56804274aadb07e2192db2f005a05f2f8fcfd8a1433bdb8ee6e3cf_sk
│ └── tlsca.org1.example.com-cert.pem
└── users # 存放属于该组织的用户的实体
├── Admin@org1.example.com # 管理员用户的信息，其中包括msp证书和tls证书两类。
│ ├── msp # msp相关证书
│ │ ├── admincerts # 组织根证书作为管理员身份验证证书
│ │ │ └── Admin@org1.example.com-cert.pem
│ │ ├── cacerts # 存放组织的根证书
│ │ │ └── ca.org1.example.com-cert.pem
│ │ ├── keystore # 本用户的身份私钥，用来签名
│ │ │ └── fa719a7d19e7b04baebbe4fa3c659a91961a084f5e7b1020670be6adc6713aa7_sk
│ │ ├── signcerts # 管理员用户的身份验证证书，被组织根证书签名。要被某个Peer认可，则必须放到该Peer的msp/admincerts目录下
│ │ │ └── Admin@org1.example.com-cert.pem
│ │ └── tlscacerts # TLS连接用的身份证书，即组织TLS证书
│ │ └── tlsca.org1.example.com-cert.pem
│ └── tls # 存放tls相关的证书和私钥。
│ ├── ca.crt # 组织的根证书
│ ├── server.crt # 管理员的用户身份验证证书，被组织根证书签名
│ └── server.key # 管理员用户的身份私钥，被组织根证书签名。
└── User1@org1.example.com # 第一个用户的信息，包括msp证书和tls证书两类
├── msp # msp证书相关信息
│ ├── admincerts # 组织根证书作为管理者身份验证证书。
│ │ └── User1@org1.example.com-cert.pem
│ ├── cacerts # 存放组织的根证书
│ │ └── ca.org1.example.com-cert.pem
│ ├── keystore # 本用户的身份私钥，用来签名
│ │ └── 97f2b74ee080b9bf417a4060bfb737ce08bf33d0287cb3eef9b5be9707e3c3ed_sk
│ ├── signcerts # 验证本用户签名的身份证书，被组织根证书签名
│ │ └── User1@org1.example.com-cert.pem
│ └── tlscacerts # TLS连接用的身份证书，被组织根证书签名。
│ └── tlsca.org1.example.com-cert.pem
└── tls # 组织的根证书
├── ca.crt # 组织的根证书
├── server.crt # 验证用户签名的身份证书，被根组织证书签名
└── server.key # 用户的身份私钥用来签名。
上面目录结构中的所有文件，就是我们用cryptogen工具来生成的MSP需要用到的证书和相关文件。主要包括各种证书和相关的签名。
三，Peer&Orderer配置MSP
在上面，使用工具已经为我们生成了相关的目录和对应的文件。如果没有工具，需要我们手动建立目录，以及手动配置MSP，该怎么做呢？
主要分成两步：
第一步：
在peer / orderer 对应的目录下，建立几个子文件夹，放入对应的证书，签名等相关信息。
第二步：
在Peer/orderer的配置文件中，设置证书和签名的路径。
节点的配置文件如下:（peer对应的是core.yaml文件 , orderer对应的是orderer.yaml）。
配置过程介绍
第一步详细过程
要想（为peer节点或orderer节点）建立本地MSP，管理员应创建一个文件夹（如$MY_PATH/mspconfig）并在其下包含6个子文件夹与一个文件：
- 文件夹admincerts包含PEM文件：每个PEM文件对应于一个管理员证书。
- 文件夹cacerts包含PEM文件：每个PEM文件对应于一个根CA的证书。
- 一个文件夹signcerts包含节点的X.509证书的PEM文件。
- （可选）文件夹intermediatecerts包含一些PEM文件：每个PEM文件对应于一个中间CA的证书。
- （可选）一个文件夹，tlscacerts以包含每个对应于TLS根CA证书的PEM文件
- （可选）文件夹crls包含相关CRL。
- 文件夹keystore包含一个PEM文件及节点的签名密钥；我们必须强调：现阶段还不支持RSA密钥。
- （可选）文件夹tlscacerts包含如下PEM文件：每个PEM文件对应于一个根TLS根CA的证书
- （可选）文件夹tlsintermediatecerts包含如下PEM文件：每个PEM文件对应于一个中间TLS CA的证书
在e2e_cli中，该Org1组织中的有两个节点，一个是管理员peer0，另一个是用户peer1。
这两个节点的文件路径如下：
peers文件夹下有两个文件，分别他们是peer0和peer1的本地MSP配置文件所在：
进入peer0.org1.example.com文件夹下，可以看到如下两个文件夹
此时，文件的当前目录为：
该目录即为peer0.org1节点进行msp配置的文件目录。
一般情况，存放msp配置的相关信息的文件夹可以命名为mspconfig 或者 msp。
其中，msp的文件目录结构如下所示：
这五个文件夹下分别放了Peer0节点完成证书与签名认证所需要的相关文件。
至此，完成了Peer&Orderer配置MSP的第一步了。
第二步详细过程
第一步的主要目的，是准备相关的证书和签名。第二步，就是要将这些文件路径配置到Peer | Orderer的配置文件中。这样，在启动节点时，就能够找到相应的证书和签名进行认证。
在节点的配置文件中，
peer对应的是core.yaml文件；
orderer对应的是orderer.yaml。
我们需要在这些配置文件中指定mspconfig文件夹的路径和节点MSP的MSP标识符。
那么到底如何来指定呢？
下面将逐一讲解：
1>peer节点配置
当Peer节点作为服务端启动时，会按照优先级从高到低的顺序依次尝试从命令行参数、环境变量或配置文件中读取配置信息。这里，我们主要通过配置文件的方式来对Peer进行配置。
读取配置信息的顺序
- Peer节点默认的配置文件读取路径为$FABRIC_CFG_PATH/core.yaml；
- 如果没找到，则尝试查找当前目录下的./core.yaml文件；
- 如果还没有找到，则尝试查找默认的/etc/hyperledger/fabric/core.yaml文件。
在结构上，core.yaml文件中一般包括logging、peer、vm、chaincode、ledger五大部分，其中，与MSP配置相关的主要是peer部分。下面见介绍如何对Peer部分进行配置，实现MSP。
peer部分包括了许多跟服务直接相关的核心配置，内容也比较多，包括msp配置、gossip、events、tls等多个配置部分，如下图所示：
下面将着重介绍通用配置中的MSP配置：
打开core.yaml文件，以下部分是关于MSP的配置
配置------>·mspConfigPath：
MSP目录所在的路径，可以为绝对路径，或相对配置目录的路径，一般建议为/etc/hyperledger/fabric/msp；本例中，写的是相对路径msp
配置------->localMspId：
Peer所关联的MSP的ID，一般为组织单位名称，需要与联盟配置中的名称一致；
到这里，就已经完成了对Peer节点的LocalMSP配置。
2>Orderer节点配置
orderer节点对应的配置文件是orderer.yaml。
Orderer节点可以组成集群来在Fabric网络中提供排序服务。类似地，支持从命令行参数、环境变量或配置文件中读取配置信息。
当从环境变量中读入配置时，需要以ORDERER_前缀开头，例如配置文件中的general.ListenAddress项，对应到环境变量ORDERER_GENERAL_LISTENADDRESS。
在结构上，orderer.yaml文件中一般包括General、FileLedger、RAMLedger、Kafka四大部分，其中，涉及MSP配置的部分在General。General部分的配置如下所示：
其中，LocalMSPDir,LocalMSPID为配置本地msp的主要部分。进入该orderer.yaml文件，该部分如下图所示：
配置------>LocalMSPDir：
MSP目录所在的路径，可以为绝对路径或相对路径，一般建议为$FABRIC_CFG_PATH/msp；
配置------>localMspId：
Orderer所关联的MSP的ID，需要与联盟配置中的组织的MSP名称一致；
到这里，就已经完成了对Orderer节点的LocalMSP配置。
四、总结
在这一篇文章中，我们发现Fabric的配置是一门很大的学问。这里，对msp的实现，就是通过配置文件来实现的。
我们通过相关工具，生成了系统中所需要的证书和签名等。
这一部分涉及crypro-config.yaml文件。
利用该配置文件，我们可以定义网络拓扑，以及生成相关证书。
生成MSP相关证书和文件后，我们对Peer和Orderer进行了MSP配置。这一部分也是通过配置文件来实现的。
core.yaml 是Peer节点的配置文件，通过对Peer部分的mspConfigPath和localMspId字段，来完成msp配置。
Orderer.yaml是Orderer节点的配置文件，通过对General部分的LocalMSPDir和localMspId字段，来完成msp配置。
到目前为止，我们了解了MSP的基本组成，基本功能，以及对Peer&Orderer节点的配置。
总结下来，MSP的peer&Orderer节点配置就是，在每一个Peer节点和排序服务节点上设置MSP目录，放入相关的证书和签名公私钥，然后在对应的配置文件中，设置msp文件路径。Peer节点和排序服务节点就有了签名证书，在通道节点之间传输数据时，要验证节点的签名，从而实现证书的验证和签名。
org1.example.com/
├── ca # 存放组织Org1的根证书和对应的私钥文件，默认采用EC算法，证书为自签名。组织内的实体将基于该根证书作为证书根。
│ ├── ca.org1.example.com-cert.pem
│ └── dfb841b77804d726eea25231ae5e89a31901ca0538688a6d764731148f0bdc5b_sk
├── msp # 存放代表该组织的身份信息。
│ ├── admincerts # 组织管理员的身份验证证书，被根证书签名。
│ │ └── Admin@org1.example.com-cert.pem
│ ├── cacerts # 组织的根证书，同ca目录下文件。
│ │ └── ca.org1.example.com-cert.pem
│ └── tlscacerts # 用于TLS的CA证书，自签名。
│ └── tlsca.org1.example.com-cert.pem
├── peers # 存放属于该组织的所有Peer节点
│ ├── peer0.org1.example.com # 第一个peer的信息，包括其msp证书和tls证书两类。
│ │ ├── msp # msp相关证书
│ │ │ ├── admincerts # 组织管理员的身份验证证书。Peer将基于这些证书来认证交易签署者是否为管理员身份。
│ │ │ │ └── Admin@org1.example.com-cert.pem
│ │ │ ├── cacerts # 存放组织的根证书
│ │ │ │ └── ca.org1.example.com-cert.pem
│ │ │ ├── keystore # 本节点的身份私钥，用来签名
│ │ │ │ └── 59be216646c0fb18c015c58d27bf40c3845907849b1f0671562041b8fd6e0da2_sk
│ │ │ ├── signcerts # 验证本节点签名的证书，被组织根证书签名
│ │ │ │ └── peer0.org1.example.com-cert.pem
│ │ │ └── tlscacerts # TLS连接用到身份证书，即组织TLS证书
│ │ │ └── tlsca.org1.example.com-cert.pem
│ │ └── tls # tls相关证书
│ │ ├── ca.crt # 组织的根证书
│ │ ├── server.crt # 验证本节点签名的证书，被组织根证书签名
│ │ └── server.key # 本节点的身份私钥，用来签名
│ └── peer1.org1.example.com # 第二个peer的信息，结构类似。（此处省略。）
│ ├── msp
│ │ ├── admincerts
│ │ │ └── Admin@org1.example.com-cert.pem
│ │ ├── cacerts
│ │ │ └── ca.org1.example.com-cert.pem
│ │ ├── keystore
│ │ │ └── 82aa3f8f9178b0a83a14fdb1a4e1f944e63b72de8df1baeea36dddf1fe110800_sk
│ │ ├── signcerts
│ │ │ └── peer1.org1.example.com-cert.pem
│ │ └── tlscacerts
│ │ └── tlsca.org1.example.com-cert.pem
│ └── tls
│ ├── ca.crt
│ ├── server.crt
│ └── server.key
├── tlsca # 存放tls相关的证书和私钥。
│ ├── 00e4666e5f56804274aadb07e2192db2f005a05f2f8fcfd8a1433bdb8ee6e3cf_sk
│ └── tlsca.org1.example.com-cert.pem
└── users # 存放属于该组织的用户的实体
├── Admin@org1.example.com # 管理员用户的信息，其中包括msp证书和tls证书两类。
│ ├── msp # msp相关证书
│ │ ├── admincerts # 组织根证书作为管理员身份验证证书
│ │ │ └── Admin@org1.example.com-cert.pem
│ │ ├── cacerts # 存放组织的根证书
│ │ │ └── ca.org1.example.com-cert.pem
│ │ ├── keystore # 本用户的身份私钥，用来签名
│ │ │ └── fa719a7d19e7b04baebbe4fa3c659a91961a084f5e7b1020670be6adc6713aa7_sk
│ │ ├── signcerts # 管理员用户的身份验证证书，被组织根证书签名。要被某个Peer认可，则必须放到该Peer的msp/admincerts目录下
│ │ │ └── Admin@org1.example.com-cert.pem
│ │ └── tlscacerts # TLS连接用的身份证书，即组织TLS证书
│ │ └── tlsca.org1.example.com-cert.pem
│ └── tls # 存放tls相关的证书和私钥。
│ ├── ca.crt # 组织的根证书
│ ├── server.crt # 管理员的用户身份验证证书，被组织根证书签名
│ └── server.key # 管理员用户的身份私钥，被组织根证书签名。
└── User1@org1.example.com # 第一个用户的信息，包括msp证书和tls证书两类
├── msp # msp证书相关信息
│ ├── admincerts # 组织根证书作为管理者身份验证证书。
│ │ └── User1@org1.example.com-cert.pem
│ ├── cacerts # 存放组织的根证书
│ │ └── ca.org1.example.com-cert.pem
│ ├── keystore # 本用户的身份私钥，用来签名
│ │ └── 97f2b74ee080b9bf417a4060bfb737ce08bf33d0287cb3eef9b5be9707e3c3ed_sk
│ ├── signcerts # 验证本用户签名的身份证书，被组织根证书签名
│ │ └── User1@org1.example.com-cert.pem
│ └── tlscacerts # TLS连接用的身份证书，被组织根证书签名。
│ └── tlsca.org1.example.com-cert.pem
└── tls # 组织的根证书
├── ca.crt # 组织的根证书
├── server.crt # 验证用户签名的身份证书，被根组织证书签名
└── server.key # 用户的身份私钥用来签名。