https://docs.corda.net/permissioning.html
Corda 是一种联盟链技术,联盟链一般也被称为许可链,这意味着每个节点都需要唯一的身份。在生产环境的网络中,每个准入的节点都应该经过严格的KYC(Know Your Customer)审查流程,才能够获取唯一的被认可的身份。这个身份在Corda网络中使用数字证书标识。
在技术上,一个Corda节点为了接入联盟网络,需要在安装节点的时候包含两个keystore文件和一个truststore文件。这些文件都被放置在节点的certificates/目录下。
从Corda的设计中不难看出,它的身份体系是构建在PKI之上。其中truststore.jks代表了Root CA,nodekeystore.jks表示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. |
遗憾的是,我们不太可能在开发阶段直接找企业的cert部门给我签发证书。为了尽早验证集成企业的证书签发体系,我们可以先模拟企业的Root CA签发节点的证书。
首先使用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)和RSA算法两者选择其一,而RSA算法要求私钥的长度必须是3072位。
openssl rsa -passin pass:x -in ca.pass.key -out ca.key
->
writing RSA key
上面生成的私钥是有passphase的,这一步就是将原来的passphasepass:x
从ca.pass.key文件中去除,得到ca.key文件,方便接下来直接使用明文的私钥。
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)是待签发的证书请求文件。
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 Identity证书。
这里以生成Corda必需的sslkeystore.jks文件为例,Corda对此给出了几点标准要求:
false
sslkeystore.jks
and store the key and certificates in it using the alias cordaclienttls
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文档中着重强调
查看sslkeystore.jks,可以使用下面的命令
keytool -list -v -keystore nodekeystore.jks
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
正如标题所示,从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体系信任的源头,一旦遭遇破坏,整个信任体系就得崩溃,后果很严重。
keytool -import -trustcacerts -alias cordarootca -file ca.crt -keystore sslkeystore.jks
如果真的有中间CA的证书,同样也需要导入到这个keystore文件。
keytool -import -trustcacerts -alias cordaintermediateca -file Intermediateca.crt -keystore sslkeystore.jks
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。同时cordaclienttls
的证书链长度为2。
keytool -import -trustcacerts -alias cordarootca -file ca.crt -keystore truststore.jks
keystore和truststore的文件格式是一致的,之所以划分成keystore和truststore,只是在概念上做了区分。Truststore决定是否信任远程的认证信息,Keystore则决定哪个认证信息可以被发送到远端。简而言之,truststore是CA证书的本地存储,类似于浏览器中的根证书;keystore是身份和对应private key的存储,类似服务端的ssl数字证书和private key。
每个节点都需要将下面的文件拷贝到自己的证书目录,即<workspace>/certificates/
于2018-09-26
参考链接 [1] keystore和truststore的区别