Corda网络的证书签发

Corda网络准入要求

https://docs.corda.net/permissioning.html

Corda 是一种联盟链技术，联盟链一般也被称为许可链，这意味着每个节点都需要唯一的身份。在生产环境的网络中，每个准入的节点都应该经过严格的KYC（Know Your Customer）审查流程，才能够获取唯一的被认可的身份。这个身份在Corda网络中使用数字证书标识。

在技术上，一个Corda节点为了接入联盟网络，需要在安装节点的时候包含两个keystore文件和一个truststore文件。这些文件都被放置在节点的certificates/目录下。

1. nodekeystore.jks 存储标识节点身份的密钥对和数字证书（所有的数字证书都只会保存公钥），用于实际交易的签名；
2. sslkeystore.jks 存储节点的TLS密钥对和数字证书，用于节点之间的加密通讯；
3. truststore.jks 存储Corda网络中的Root CA的公钥和数字证书，跟浏览器的根证书用途一致，但是除了帮助节点之间建立可信连接，还用于验证交易对手方身份的真实性。

从Corda的设计中不难看出，它的身份体系是构建在PKI之上。其中truststore.jks代表了Root CA，nodekeystore.jks表示Node CA以及Well-Known identity，而sslkeystore.jks存储了TLS certificate.

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: SUN

Your keystore contains 2 entries

Alias 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的区别