fabric ca
fabric-ca-client enroll -u http://admin:adminpw@localhost:7054
登录命令会存储一个登录证书（ECert），相对应的私钥，还有CA证书链PEM文件
注册一个新的身份只有在上面admin用户状态下才能才能发起新用户的注册请求
export FABRIC_CA_CLIENT_HOME=$HOME/fabric-ca/clients/admin
fabric-ca-client register --id.name admin2 --id.type user --id.affiliation org1.department1 --id.attr hf.Revoker=true
ECerts 1，长期有效(静态登记证书)
2，包含所有者的身份/注册ID
3，为TCert请求提供名义实体的身份验证
4，Enroll阶段产生
TCerts 1，每个交易的短期证书
2，不包含所有者的身份/注册ID·(为了匿名，但是可以配置有注册信息的形式)
3，Transaction阶段产生
※现阶段还没有Tcert(ibm留下的坑。。。。)
ECerts包含两个密钥对的公共部分： 一个签名密钥对和一个加密密钥对
TLS证书(TLS-Certs) TLS-Certs 是用于系统/组件到系统/组件间通讯所使用的证书。
他们包含所有者的身份信息，使用是为了保证网络基本的安全
-------------------------------------------------------------------
证书(TCerts)里包含下面信息(v1.0还不支持)
1，用户身份
2，加密用公钥-私钥(签名私钥和验证公钥)
3，签名用公钥-私钥(加密公钥和解密私钥)
4，颁发机构
※0.6简化Tcerts设计使用对称密钥加密来提供交易保密性
-------------------------------------------------------------------
每个组织都配置了唯一的根证书(ca-cert)
Hyperledger Fabric中的交易和通信是通过存储在keystore中的实体的私钥签名，然后通过公钥手段进行验证
MSP文件夹，用来存储每个组织在orderer genesis block中指定的根证书
Org1的私钥：crypto-config/peerOrganizations/org1.example.com/ca/
Org2的私钥：crypto-config/peerOrganizations/org2.example.com/ca/
Hyperledger Fabric中的交易和通信是通过存储在keystore中的实体的私钥签名，然后通过公钥手段进行验证（signcerts）
--------------------------------------------------------------------------
orderer和peer需要具备签名的能力。为了做到这一点，节点的管理员在节点启动的时候指定签名Identity的信息。
这里的MSP实现了签名Identity， 我们称之为SignerMSP。
创建后，只有节点的管理员可以更新，各个节点可以不同。
简单描述，在V1.0中，假设关键一个类型为Fabric的MSP， 管理员需要在节点的指定目录拷贝下面四类文件
cacerts: PEM格式的MSP的根CA证书
admincerts： MSP的管理员证书
keystore: 节点的签名私钥
signcerts:验证本节点签名的证书(由ca根证书签名生成的证书，证书里面包含该节点私钥对应的公钥)
https://github.com/yeasy/hyperledger_code_fabric/blob/master/common/tools/cryptogen/main_go.md
pem文件，它里面的内容可能是certificate也可能是key，也可能两个都有，要看具体情况.
--------------------------------------------------------------------------------------------
orderer系统channel中指定的msp，可以定义对channel的访问策略，管理相关成员，
包括：reader（向channel发获取请求），writer（向channel发送广播请求），
chainCreator（发送创建链代码请求），admin（可以发送重新配置channel请求）。
应用链或者channel中指定的msp，可以定义访问策略，管理相关成员：reader， writer，admins，
chaincodeAdmin(可以发送链代码实例化请求)。 显然，链内的msp具有签名验证角色，
与本地msp提供的签名角色相反。更详细的说，peer和orderer需要在channel（orderer 系统channel）
和chain上下文中 启动msp，来认证交易或者配置相关的请求，具备生成签名的能力。
------------------------------------------------------------------------------------------------------------------
##管理员身份自认证
首先，修改配置文件，其中 csr.cn 字段必须与自认证的身份名称相同。
通过调用监听在本地 7054 端口的服务端，对 ID：admin 与 PWD：adminpw 的管理员身份进行了自认证
--------
export FABRIC_CA_CLIENT_HOME=$HOME/fabric-ca/clients/admin
fabric-ca-client enroll -u http://admin:adminpw@localhost:7054
--------
enroll 命令会将生成的 ECert（enrollment certificate），
以及对应的私钥及、CA 证书链（PEM 格式）存储在子目录 msp 中，
命令执行成功后提示这些文件的存储位置
------------------------------------------------------------------------------------------------------------------
一个X.509证书包含了一个公钥，和一个身份标识（一个主机名，或一个组织，或一个个人），
然后被CA（certificate authority）签名，或者自签名。
当一个证书被CA签名后，或者其它方式验证后，持有该证书的人，就可以依靠其中包含的公钥，
来和外界建立安全的通信；或者验证那些通过证书中公钥对应的私钥数字签名后的文档
------------------------------------------------------------------------------------------------------------------
在register时候，下面命令里面的参数-M的意思是，拥有执行register权限用户的MSP路径
fabric-ca-client register -M admin/msp --id.name user01 --id.type peer --id.affiliation org1.department1 --id.secret user01pw
在enroll时候，下面命令里面的参数-M的意思是，enroll时发行的key的保存场所
fabric-ca-client enroll -u http://user01:user01pw@fabric-ca:7054 -M user01/msp
------------------------------------------------------------------------------------------------------------------
docker run 启动cli时，要设定下面关联
../crypto-config/peerOrganizations/org1.example.com/users/[email protected]/msp:/etc/hyperledger/fabric-ca-client
环境变量:
-e FABRIC_CA_CLIENT_TLS_CERTFILES=/etc/hyperledger/fabric-ca-client/ca.org1.example.com-cert.pem ->ca的root证书
-e FABRIC_CA_CLIENT_TLS_CLIENT_CERTFILE=/etc/hyperledger/fabric-ca-client/signcerts/[email protected] ->包含公钥
-e FABRIC_CA_CLIENT_TLS_CLIENT_KEYFILE=/etc/hyperledger/fabric-ca-client/keystore/XXXXXX_sk ->私钥
启动ca服务器的时候，下面的参数，如果只设定其中一个，会出现[Public key and private key do not match]异常
FABRIC_CA_SERVER_CA_KEYFILE设置的是私有key
FABRIC_CA_SERVER_CA_CERTFILE设置认证证书，其里面还包含了公有key
------------------------------------------------------------------------------------------------------------------
在一个父ca服务里面可以启动多个子ca，通过设定fabric-ca-server-config.yaml有两种方法。
第一种是设定cacount，比如[cacount:2]，代表启动2个子ca.
子ca的配置，是根据默认ca配置来设定。
在这种模式下，父ca的启动参数里面不能设置[FABRIC_CA_SERVER_CA_KEYFILE,FABRIC_CA_SERVER_CA_CERTFILE]
这两个参数，因为子ca创建完成后，会把子ca的证书和父ca的csr部分进行对比，如果一样的话，会报异常。
第二种是设定cafiles，内容如下。在启动父ca的时候，把外部ca配置文件需要挂载到父ca容器里面.
另外要注意的是，这两个子ca配置文件中csr.cn要设置不同的值，以便于父ca识别。
cafiles:
- ca/ca1/fabric-ca-server-config.yaml
- ca/ca2/fabric-ca-server-config.yaml
以上的方法实质上共启动了3个ca服务，一个父带两个子。
在调用的时候需要指定--caname这个参数，如下
fabric-ca-client enroll -u http://admin:adminpw@ca-server:7054 -M admin/msp --caname subca01
fabric-ca-client register -M admin/msp --caname subca01 --id.name tom --id.type orderer --id.affiliation org1.department1 --id.secret tomPW
父CA的所属情报会保存到子CA的表affiliations中。
子CA的root证书和私有key会根据cafiles设定的config文件内容生成，如下
/etc/hyperledger/fabric-ca-server/ca/ca01.ca-cert.pem
/etc/hyperledger/fabric-ca-server/ca/ca01/msp/keystore/fasdfadsfafdasdxxxxx_sk
从上面可以看出，如果父ca启动的时候，不指定在generateArtifacts.sh生成的初期key的话，可以根据配置文件自己生成新的初始key
关于fabric-ca-server-config配置文件
bccsp区域，用来生成私有key
csr区域，用来生成CA证明书的请求书
signing区域，根据(CA证明书的请求书)生成CA证明书
-------------------------------------------------------------------------------------------------------------------
一个关于数字签名的说明
http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html
-------------------------------------------------------------------------------------------------------------------
一个关于ca链的说明
http://www.cnblogs.com/midfielder/p/7173121.html
--------------------------------------------------------------------------------------------------------------------
参考网站
http://www.cnblogs.com/hadex/p/6825264.html
--------------------------------------------------------------------------------------------------------------------
复数ca，中间ca的生成参照
http://www.cnblogs.com/midfielder/p/7173121.html