Corda doc 3.2 - Permissioning Structure

证书签发过程

在开发模式下，即节点的配置文件 node.conf 中devMode=true，如果nodekeystore.jks和sslkeystore.jks不存在，节点启动时会自动生成。这样设计的初衷是为了让开发者快速验证，但同时也会导致对生产要求的忽视。

几乎所有企业都有一套自己完善的证书管理机制和审批流程，所以利用现有的机制和流程加固证书安全也是一项不容忽视的任务。这也是我们选用Corda的原因之一 —— 充分利用现有的基础设施。

理想的情况下，企业的cert部门会包揽上图中所有的任务，每个节点需要做的事情就是提交CSR（Certificate Signing Request）文件，然后等待一封邮件，附件中包含申请的数字证书、中间CA（Intermediated CA）证书和根CA（Root CA）证书。

当然更理想的情况是，Doorman（见上图）这个服务正式上线。而事实上，Corda3.2以及预览版的企业版Corda都还没有Doorman服务的实现，官方文档中还只有一套不成熟的REST接口标准。为啥说它不成熟呢？因为这个接口标准在release-M14.0还存在，但是最新的Corda3.2却不见了踪影。

Request method	Path	Description
POST	/api/certificate	Create new certificate request record and stored for further approval process, server will response with a request ID if the request has been accepted.
GET	/api/certificate/{requestId}	Retrieve certificates for requestId, the server will return HTTP 204 if request is not yet approved or HTTP 401 if it has been rejected.

模拟Root CA 签发证书

遗憾的是，我们不太可能在开发阶段直接找企业的cert部门给我签发证书。为了尽早验证集成企业的证书签发体系，我们可以先模拟企业的Root CA签发节点的证书。

创建Root CA

1. 生成私钥

首先使用rsa算法生成3072位长度的私钥。

openssl genrsa -des3 -passout pass:x -out ca.pass.key 3072-> Generating RSA private key, 3072 bit long modulus ....................++ ............................................................................................++ e is 65537 (0x10001) 

为什么要求私钥的key size是3072呢？因为Corda文档中有明确的要求：

The root network CA, doorman CA and node CA keys, as well as the node TLS keys, must follow one of the following schemes:

• ECDSA using the NIST P-256 curve (secp256r1)
• RSA with 3072-bit key size

在椭圆曲线签名算法（ECDSA）和RSA算法两者选择其一，而RSA算法要求私钥的长度必须是3072位。

2. 删除第一步des3算法产生的passphase

openssl rsa -passin pass:x -in ca.pass.key -out ca.key-> writing RSA key 

上面生成的私钥是有passphase的，这一步就是将原来的passphasepass:x从ca.pass.key文件中去除，得到ca.key文件，方便接下来直接使用明文的私钥。

3. 生成CSR文件

openssl req -new -key ca.key -out ca.csr \ -subj '/C=US/ST=California/L=Los Angeles/O=Mystic Coders, LLC/ \ OU=Information Technology/CN=ws.mysticcoders.com \ emailAddress=fakeemail AT gmail DOT com/ \ subjectAltName=DNS.1=endpoint.com'->Subject Attribute OU has no known NID, skipped Subject Attribute subjectAltName has no known NID, skipped 

当执行完这一步，当前目录下会出现三个文件：ca.csr, ca.key, ca.pass.key。其中ca.csr文件（Certificate Signing Request）是待签发的证书请求文件。

4. 自签发证书（使用自己的私钥签发自己的证书）

openssl x509 -req -days 365 -in ca.csr -signkey ca.key -out ca.crt-> Signature ok subject=/C=US/ST=California/L=Los Angeles/O=Mystic Coders, LLC/CN=ws.mysticcoders.com \x0AemailAddress=fakeemail AT gmail DOT com Getting Private key 

这步操作结束之后，ca.crt文件就顺利生成，它代表了Root CA的证书。我们接下来就能利用这个证书及其私钥签发SSL证书和Node Well-Known identity 证书。

---

keytool工具生成keystore和truststore文件

这里以生成Corda必需的sslkeystore.jks文件为例，Corda对此给出了几点标准要求：

Creating the node TLS keystores

1. For each node, create a new keypair
2. Create a certificate for the keypair signed with the node CA key. The basic constraints extension must be set to false
3. Create a new Java keystore named sslkeystore.jks and store the key and certificates in it using the alias cordaclienttls

• The node will store this keystore locally to sign its TLS certificates

1. 创建keystore文件及其私钥

keytool -genkeypair -alias cordaclienttls -keyalg RSA-ext BC=ca:FALSE -keysize 3072 -keystore sslkeystore.jks -storepass changeit -v-> ... Generating 3,072 bit RSA key pair and self-signed certificate (SHA256withRSA) with a validity of 90 days for: CN=Qian, OU=Software engineer, O=ThoughtWorks, L=Chengdu, ST=Sichuan, C=CN Enter key password for <cordaclienttls> (RETURN if same as keystore password): [Storing sslkeystore.jks] 

特别要注意的是-ext BC=ca:FALSE，Corda文档中着重强调

• The basic constraints extension must be set to false

查看sslkeystore.jks，可以使用下面的命令

keytool -list -v -keystore sslkeystore.jks 

2. 创建CSR

keystore文件和私钥产生之后，就想传统向CA机构提交申请一样，需要准备CSR文件。

keytool -certreq -alias cordaclienttls -keystore sslkeystore.jks -file sslkeystore.csr -v-> Enter keystore password: Certification request stored in file <sslkeystore.csr> Submit this to your CA 

keytool的这条命令指定sslkeystore.jks文件中别名为cordaclienttls的entry产生对应的sslkeystore.csr文件。

查看sslkeystore.csr中的内容，可以使用下面的命令

openssl req -in sslkeystore.csr -noout -text 

3. 从CA机构处获取证书 用模拟的Root CA签发证书

正如标题所示，从CA机构获取证书是比较正式的做法。着重强调，证书的安全性非常重要。这里使用模拟的Root CA签发只是为了验证假设的可行性，这个假设就是Corda的证书体系可以融合企业现存的证书体系。

openssl x509 -req -days 365 -in sslkeystore.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out sslkeystore.crt-> Signature ok subject=/C=CN/ST=Sichuan/L=Chengdu/O=ThoughtWorks/OU=Software sector/CN=Yan Qian Getting CA Private Key 

根证书一般不会直接用于签发数字证书的，总会存在Intermediate CA给使用者签发，这样做的目的是保证根证书的安全。总的来说，使用频率越少，出现失误的可能性就越小。而且从证书的信任链角度考虑，根证书是PKI体系信任的源头，一旦遭遇破坏，整个信任体系就得崩溃，后果很严重。

4. 根证书导入ssl keystore

keytool -importcert -trustcacerts -alias cordarootca -file ca.crt -keystore sslkeystore.jks 

如果真的有中间CA的证书，同样也需要导入到这个keystore文件。

keytool -importcert -trustcacerts -alias cordaintermediateca -file Intermediateca.crt -keystore sslkeystore.jks 

5. ssl证书导入ssl keystore

keytool -importcert -alias cordaclienttls -file sslkeystore.crt -keystore sslkeystore.jks 

注意这一步操作，如果根证书没有事先导入，会出现下面的错误

Enter keystore password: keytool error: java.lang.Exception: Public keys in reply and keystore don't match 

解决方法是提前导入Root CA和Intermediate CA（如果有的话）的证书。

此时，查看sslkeystore.jks的内容

keytool -list -v -keystore sslkeystore.jks-> Enter keystore password: Keystore type: JKS Keystore provider: SUNYour keystore contains 2 entriesAlias name: cordaclienttls Creation date: Sep 26, 2018 Entry type: PrivateKeyEntry Certificate chain length: 2 Certificate[1]: Owner: CN=Yan Qian, OU=Software sector, O=ThoughtWorks, L=Chengdu, ST=Sichuan, C=CN Issuer: CN="ws.mysticcoders.com ... Certificate[2]: Owner: CN="ws.mysticcoders.com ... Alias name: cordarootca Creation date: Sep 27, 2018 Entry type: trustedCertEntry 

这个文件包含了两个entry，一个是cordaclienttls，另一个就是cordarootca。注意其中cordaclienttls的Entry type是PrivateKeyEntry，而cordarootca的Entry type是trustedCertEntry。keystore文件除了存储证书之外，也可以存储私钥（这也是很多人诟病Corda的地方，私钥理应离线存储，不过Corda官方也有自己的解释）。另外，cordaclienttls的证书链长度为2，从自己的证书上溯到根证书。

8. Root CA的证书导入truststore

keytool -importcert -trustcacerts -alias cordarootca -file ca.crt -keystore truststore.jks 

keystore和truststore的文件格式是一致的，之所以划分成keystore和truststore，只是在概念上做了区分。Truststore决定是否信任远程的认证信息，Keystore则决定哪个认证信息可以被发送到远端。简而言之，truststore是CA证书的本地存储，类似于浏览器中的根证书；keystore是身份和对应private key的存储，类似服务端的ssl数字证书和private key。

9. 节点安装证书

每个节点都需要将下面的文件拷贝到自己的证书目录，即<workspace>/certificates/

1. nodekeystore.jks，和sslkeystore的生成过程类似，可以参考Corda文档，改变个别配置项，比如：alias, -ext BC=ca:TRUE
2. sslkeystore.jks
3. Root CA truststore.jks

---

于2018-09-26

---

参考链接
[1] keystore和truststore的区别

本页内容由塔灯网络科技有限公司通过网络收集编辑所得，所有资料仅供用户学习参考，本站不拥有所有权，如您认为本网页中由涉嫌抄袭的内容，请及时与我们联系，并提供相关证据，工作人员会在5工作日内联系您，一经查实，本站立刻删除侵权内容。本文链接:https://www.dengtar.com/20476.html