"证书 -- 为公钥加上数字签名"
要开车得先考驾照.驾照上面记有本人的照片、姓名、出生日期等个人信息.以及有效期、准驾车辆的类型等信息,并由公安局在上面盖章。我们只要看到驾照,就可以知道公安局认定此人具有驾驶车辆的资格。 公钥证书(Public-Key Certificate,PKC)其实和驾照很相似,里面记有姓名、组织、邮箱地址等个人信息,以及属于此人的公钥,并由认证机构(Certification Authority、Certifying Authority, CA)施加数字签名。只要看到公钥证书,我们就可以知道认证机构认定该公钥的确属于此人。公钥证书也简称为证书(certificate)。 可能很多人都没听说过认证机构,认证机构就是能够认定 “公钥确实属于此人”,并能够生成数字签名的个人或者组织。认证机构中有国际性组织和政府所设立的组织,也有通过提供认证服务来盈利的一般企业,此外个人也可以成立认证机构。
下面我们来通过证书的代表性应用场景来理解证书的作用。 下图展示了Alice向Bob发送密文的场景,在生成密文时所使用的Bob的公钥是通过认证机构获取的。 认证机构必须是可信的,对于“可信的第三方”,下图中会使用Trent这个名字,这个词是从trust(信任)一词演变而来的。
下面让我们对照着上图来看一看这些步骤具体都做了些什么。
等级越高,身份确认越严格。
上面就是利用认证机构Trent进行公钥密码通信的流程。其中1、2、3这几个步骤仅在注册新公钥时才会进行,并不是每次通信都需要。此外,步骤 4 仅在Alice第一次用公钥密码向Bob发送消息时才需要进行,只要Alice将Bob的公钥保存在电脑中,在以后的通信中就可以直接使用了。
证书是由认证机构颁发的,使用者需要对证书进行验证,因此如果证书的格式千奇百怪那就不方便了。于是,人们制定了证书的标准规范,其中使用最广泛的是由ITU(International TelecommumcationUnion,国际电信联盟)和ISO(IntemationalOrganizationforStandardization, 国际标准化组织)制定的X.509规范。很多应用程序都支持x.509并将其作为证书生成和交换的标准规范。 X.509是一种非常通用的证书格式。所有的证书都符合ITU-T X.509国际标准,因此(理论上)为一种应用创建的证书可以用于任何其他符合X.509标准的应用。X.509证书的结构是用ASN1(Abstract Syntax Notation One)进行描述数据结构,并使用ASN.1语法进行编码。 在一份证书中,必须证明公钥及其所有者的姓名是一致的。对X.509证书来说,认证者总是CA或由CA指定的人,一份X.509证书是一些标准字段的集合,这些字段包含有关用户或设备及其相应公钥的信息。X.509标准定义了证书中应该包含哪些信息,并描述了这些信息是如何编码的(即数据格式) 一般来说,一个数字证书内容可能包括基本数据(版本、序列号) 、所签名对象信息( 签名算法类型、签发者信息、有效期、被签发人、签发的公开密钥)、CA的数字签名,等等。
前使用最广泛的标准为ITU和ISO联合制定的X.509的 v3版本规范 (RFC5280), 其中定义了如下证书信息域:
此外,证书的颁发者还需要对证书内容利用自己的私钥添加签名, 以防止别人对证书的内容进行篡改。
X.509规范中一般推荐使用PEM(Privacy Enhanced Mail)格式来存储证书相关的文件。证书文件的文件名后缀一般为 .crt 或 .cer 。对应私钥文件的文件名后缀一般为 .key。证书请求文件的文件名后綴为 .csr 。有时候也统一用pem作为文件名后缀。 PEM格式采用文本方式进行存储。一般包括首尾标记和内容块,内容块采用Base64进行编码。 编码格式总结:
例如,一个PEM格式(base64编码)的示例证书文件内容如下所示:
-----BEGIN CERTIFICATE-----
MIIDyjCCArKgAwIBAgIQdZfkKrISoINLporOrZLXPTANBgkqhkiG9w0BAQsFADBn
MSswKQYDVQQLDCJDcmVhdGVkIGJ5IGh0dHA6Ly93d3cuZmlkZGxlcjIuY29tMRUw
EwYDVQQKDAxET19OT1RfVFJVU1QxITAfBgNVBAMMGERPX05PVF9UUlVTVF9GaWRk
bGVyUm9vdDAeFw0xNzA0MTExNjQ4MzhaFw0yMzA0MTExNjQ4MzhaMFoxKzApBgNV
BAsMIkNyZWF0ZWQgYnkgaHR0cDovL3d3dy5maWRkbGVyMi5jb20xFTATBgNVBAoM
DERPX05PVF9UUlVTVDEUMBIGA1UEAwwLKi5iYWlkdS5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDX0AM198jxwRoKgwWsd9oj5vI0and9v9SB9Chl
gZEu6G9ZA0C7BucsBzJ2bl0Mf6qq0Iee1DfeydfEKyTmBKTafgb2DoQE3OHZjy0B
QTJrsOdf5s636W5gJp4f7CUYYA/3e1nxr/+AuG44Idlsi17TWodVKjsQhjzH+bK6
8ukQZyel1SgBeQOivzxXe0rhXzrocoeKZFmUxLkUpm+/mX1syDTdaCmQ6LT4KYYi
soKe4f+r2tLbUzPKxtk2F1v3ZLOjiRdzCOA27e5n88zdAFrCmMB4teG/azCSAH3g
Yb6vaAGaOnKyDLGunW51sSesWBpHceJnMfrhwxCjiv707JZtAgMBAAGjfzB9MA4G
A1UdDwEB/wQEAwIEsDATBgNVHSUEDDAKBggrBgEFBQcDATAWBgNVHREEDzANggsq
LmJhaWR1LmNvbTAfBgNVHSMEGDAWgBQ9UIffUQSuwWGOm+o74JffZJNadjAdBgNV
HQ4EFgQUQh8IksZqcMVmKrIibTHLbAgLRGgwDQYJKoZIhvcNAQELBQADggEBAC5Y
JndwXpm0W+9SUlQhAUSE9LZh+DzcSmlCWtBk+SKBwmAegbfNSf6CgCh0VY6iIhbn
GlszqgAOAqVMxAEDlR/YJTOlAUXFw8KICsWdvE01xtHqhk1tCK154Otci60Wu+tz
1t8999GPbJskecbRDGRDSA/gQGZJuL0rnmIuz3macSVn6tH7NwdoNeN68Uj3Qyt5
orYv1IFm8t55224ga8ac1y90hK4R5HcvN71aIjMKrikgynK0E+g45QypHRIe/z0S
/1W/6rqTgfN6OWc0c15hPeJbTtkntB5Fqd0sfsnKkW6jPsKQ+z/+vZ5XqzdlFupQ
29F14ei8ZHl9aLIHP5s=
-----END CERTIFICATE-----
使用openssl 工具命令:openssl x509 -in ca-cert.pem -inform pem -noout -text
证书中的解析出来的内容:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
10:e6:fc:62:b7:41:8a:d5:00:5e:45:b6
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA-SHA256-G2
Validity
Not Before: Nov 21 08:00:00 2016 GMT
Not After : Nov 22 07:59:59 2017 GMT
Subject: C=US, ST=California, L=San Francisco, O=Wikimedia Foundation, Inc., CN=*.wikipedia.org
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:c9:22:69:31:8a:d6:6c:ea:da:c3:7f:2c:ac:a5:
af:c0:02:ea:81:cb:65:b9:fd:0c:6d:46:5b:c9:1e:
ed:b2:ac:2a:1b:4a:ec:80:7b:e7:1a:51:e0:df:f7:
c7:4a:20:7b:91:4b:20:07:21:ce:cf:68:65:8c:c6:
9d:3b:ef:d5:c1
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Agreement
Authority Information Access:
CA Issuers - URI:http://secure.globalsign.com/cacert/gsorganizationvalsha2g2r1.crt
OCSP - URI:http://ocsp2.globalsign.com/gsorganizationvalsha2g2
X509v3 Certificate Policies:
Policy: 1.3.6.1.4.1.4146.1.20
CPS: https://www.globalsign.com/repository/
Policy: 2.23.140.1.2.2
X509v3 Basic Constraints:
CA:FALSE
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl.globalsign.com/gs/gsorganizationvalsha2g2.crl
X509v3 Subject Alternative Name:
DNS:*.wikipedia.org, DNS:*.m.mediawiki.org, DNS:*.m.wikibooks.org, DNS:*.m.wikidata.org, DNS:*.m.wikimedia.org, DNS:*.m.wikimediafoundation.org, DNS:*.m.wikinews.org, DNS:*.m.wikipedia.org, DNS:*.m.wikiquote.org, DNS:*.m.wikisource.org, DNS:*.m.wikiversity.org, DNS:*.m.wikivoyage.org, DNS:*.m.wiktionary.org, DNS:*.mediawiki.org, DNS:*.planet.wikimedia.org, DNS:*.wikibooks.org, DNS:*.wikidata.org, DNS:*.wikimedia.org, DNS:*.wikimediafoundation.org, DNS:*.wikinews.org, DNS:*.wikiquote.org, DNS:*.wikisource.org, DNS:*.wikiversity.org, DNS:*.wikivoyage.org, DNS:*.wiktionary.org, DNS:*.wmfusercontent.org, DNS:*.zero.wikipedia.org, DNS:mediawiki.org, DNS:w.wiki, DNS:wikibooks.org, DNS:wikidata.org, DNS:wikimedia.org, DNS:wikimediafoundation.org, DNS:wikinews.org, DNS:wikiquote.org, DNS:wikisource.org, DNS:wikiversity.org, DNS:wikivoyage.org, DNS:wiktionary.org, DNS:wmfusercontent.org, DNS:wikipedia.org
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Subject Key Identifier:
28:2A:26:2A:57:8B:3B:CE:B4:D6:AB:54:EF:D7:38:21:2C:49:5C:36
X509v3 Authority Key Identifier:
keyid:96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C
Signature Algorithm: sha256WithRSAEncryption
8b:c3:ed:d1:9d:39:6f:af:40:72:bd:1e:18:5e:30:54:23:35:
...
证书是用来证明某某东西确实是某某东西的东西(是不是像绕口令?)。通俗地说,证书就好比上文里面的公章。通过公章,可以证明对应的证件的真实性。 理论上,人人都可以找个证书工具,自己做一个证书。那如何防止坏人自己制作证书出来骗人捏?请看后续 CA 的介绍。 CA是Certificate Authority的缩写,也叫“证书授权中心”。 它是负责管理和签发证书的第三方机构, 好比一个可信任的中介公司。一般来说,CA必须是所有行业和所有公众都信任的、认可的。因此它必须具有足够的权威性。就好比A、B两公司都必须信任C公司,才会找 C 公司作为公章的中介。
处于最顶上的树根位置的那个证书,就是“根证书”。除了根证书,其它证书都要依靠上一级的证书,来证明自己。那谁来证明“根证书”可靠捏?实际上,根证书自己证明自己是可靠滴(或者换句话说,根证书是不需要被证明滴)。 聪明的同学此刻应该意识到了:根证书是整个证书体系安全的根本。所以,如果某个证书体系中,根证书出了问题(不再可信了),那么所有被根证书所信任的其它证书,也就不再可信了。
大多数知名的网站,如果用了 HTTPS 协议,其证书都是可信的(也就不会出现上述警告)。所以,今后你如果上某个知名网站,发现浏览器跳出上述警告,你就要小心啦!
一般来说,签名列表中,有且仅有一个签名。选中它,点“详细信息”按钮。跳出如下界面: 通常这个界面会显示一行字:“该数字签名正常”(图中红圈标出)。如果有这行字,就说明该文件从出厂到你手里,中途没有被篡改过(是原装滴、是纯洁滴)。如果该文件被篡改过了(比如,感染了病毒、被注入木马),那么对话框会出现一个警告提示“该数字签名无效”
从后一个界面,可以看到刚才说的证书信任链。图中的信任链有3层:
目前大多数知名的公司(或组织机构),其发布的可执行文件(比如软件安装包、驱动程序、安全补丁),都带有数字签名。你可以自己去看一下。 建议大伙儿在安装软件之前,都先看看是否有数字签名?如果有,就按照上述步骤验证一把。一旦数字签名是坏的,那可千万别装。
仅制定证书的规范还不足以支持公钥的实际运用,我们还需要很多其他的规范,例如证书应该由谁来颁发,如何颁发,私钥泄露时应该如何作废证书,计算机之间的数据交换应采用怎样的格式等。这一节我们将介绍能够使公钥的运用更加有效的公钥基础设施。
公钥基础设施(Public-Key infrastructure)是为了能够更有效地运用公钥而制定的一系列规范和规格的总称。公钥基础设施一般根据其英语缩写而简称为PKI。 PKI只是一个总称,而并非指某一个单独的规范或规格。例如,RSA公司所制定的PKCS(Public-Key Cryptography Standards,公钥密码标准)系列规范也是PKI的一种,而互联网规格RFC(Requestfor Comments)中也有很多与PKI相关的文档。此外,X.509这样的规范也是PKI的一种。在开发PKI程序时所使用的由各个公司编写的API(Application Programming Interface, 应用程序编程接口)和规格设计书也可以算是PKI的相关规格。 因此,根据具体所采用的规格,PKI也会有很多变种,这也是很多人难以整体理解PKI的原因之一。 为了帮助大家整体理解PKI,我们来简单总结一下PKI的基本组成要素(用户、认证机构、仓库)以及认证机构所负责的工作。
PKI的组成要素主要有以下三个:
用户就是像Alice、Bob这样使用PKI的人。用户包括两种:一种是希望使用PKI注册自己的公钥的人,另一种是希望使用已注册的公钥的人。我们来具体看一下这两种用户所要进行的操作。
注册公钥的用户所进行的操作
使用已注册公钥的用户所进行的操作
/*
==================== 小知识点 ====================
浏览器如何验证SSL证书
1. 在IE浏览器的菜单中点击“工具 /Internet选项”,选择“内容”标签,点击“证书”按钮,然后就可以看到IE
浏览器已经信任了许多“中级证书颁发机构”和“受信任的根证书颁发机 构。当我们在访问该网站时,浏览器
就会自动下载该网站的SSL证书,并对证书的安全性进行检查。
2. 由于证书是分等级的,网站拥有者可能从根证书颁发机构领到证书,也可能从根证书的下一级(如某个国家
的认证中心,或者是某个省发出的证书)领到证书。假设我们正在访问某个使用 了 SSL技术的网站,IE浏
览器就会收到了一个SSL证书,如果这个证书是由根证书颁发机构签发的,IE浏览器就会按照下面的步骤来
检查:浏览器使用内 置的根证书中的公钥来对收到的证书进行认证,如果一致,就表示该安全证书是由可信
任的颁证机构签发的,这个网站就是安全可靠的;如果该SSL证书不是根服 务器签发的,浏览器就会自动检
查上一级的发证机构,直到找到相应的根证书颁发机构,如果该根证书颁发机构是可信的,这个网站的SSL证
书也是可信的。
*/
认证机构(Certification Authority,CA)是对证书进行管理的人。上面的图中我们给它起了一个名字叫作Trent。认证机构具体所进行的操作如下:
认证机构的工作中,公钥注册和本人身份认证这一部分可以由注册机构(Registration Authority,RA) 来分担。这样一来,认证机构就可以将精力集中到颁发证书上,从而减轻了认证机构的负担。不过,引入注册机构也有弊端,比如说认证机构需要对注册机构本身进行认证,而且随着组成要素的增加,沟通过程也会变得复杂,容易遭受攻击的点也会增。
仓库(repository)是一个保存证书的数据库,PKI用户在需要的时候可以从中获取证书.它的作用有点像打电话时用的电话本。在本章开头的例子中,尽管没特别提到,但Alice获取Bob的证书时,就可以使用仓库。仓库也叫作证书目录。
公钥基础设施(PKI)这个名字总会引起一些误解,比如说“面向公众的权威认证机构只有一个”,或者“全世界的公钥最终都是由一个根CA来认证的”,其实这些都是不正确的。认证机构只要对公钥进行数字签名就可以了,因此任何人都可以成为认证机构,实际上世界上已经有无数个认证机构了。 国家、地方政府、医院、图书馆等公共组织和团体可以成立认证机构来实现PKI,公司也可以出于业务需要在内部实现PKI,甚至你和你的朋友也可以以实验为目的来构建PKI。 在公司内部使用的情况下,认证机构的层级可以像上一节中一样和公司的组织层级一一对应,也可以不一一对应。例如,如果公司在东京、大阪、北海道和九州都成立了分公司,也可以采取各个分公司之间相互认证的结构。在认证机构的运营方面,可以购买用于构建PKI的软件产品由自己公司运营,也可以使用VeriSign等外部认证服务。具体要采取怎样的方式,取决于目的和规模,并没有一定之规。
Fabric CA项目是超级账本Fabric内的MemberService组件, 对网络内各个实体的身份证书的管理, 主要实现:
在fabric-ca中的三种证书类型
1.登记证书(ECert):对实体身份进行检验
2.通信证书(TLSCert):保证通信链路安全,对远端身份校验
3.交易证书(TCert):颁发给用户,控制每个交易的权限
下图描述了CA 服务器在Fabric 框架体系架构中的工作方式:
CA 服务器结构为树形结构,整个树形结构的根节点为根CA(Root Server),存在多个中间CA(Intermediate CA),图中每个中间CA服务器上可以配置一个CA服务集群,CA服务集群通过前置的HA实现负载均衡。
Fabric CA提供了两种访问方式调用Server服务,一种是通过Client调用,另一种是通过SDK调用。两种调用都是REST风格的。本文使用的是通过Client调用。
Fabric CA采用了典型的C/S架构, 目前包含两个基本组件, 分别实现服务端功能和客户端功能
安装服务端与客户端二进制命令到$GOPATH/bin目录下
$ go get -u github.com/hyperledger/fabric-ca/cmd/...
切换至源码目录下:
$ cd $GOPATH/src/github.com/hyperledger/fabric-ca/1
使用make命令编译:
$ make fabric-ca-server
$ make fabric-ca-client
生成 bin
目录, 目录中包含 fabric-ca-client
与 fabric-ca-server
两个可执行文件
返回至用户目录
1.$ cd ~
2.$ mkdir fabric-ca
3.$ cd fabric-ca
fabric-ca启动:
1. 使用init进行初始化
2. 使用start启动
初始化
$ fabric-ca-server init -b admin:pass
生成配置文件到至当前目录
快速启动并初始化一个fabric-ca-server服务
$ fabric-ca-server start -b admin:pass
-b : 提供注册用户的名称与密码, 如果没有使用LDAP, 这个选项为必需. 默认的配置文件的名称为fabric-ca-server-config.yaml
如果之前没有执行初始化命令, 则启动过程中会自动先进行初始化操作. 即从主配置目录搜索相关证书和配置文件, 如果不存在则会自动生成
fabric-ca-server-config.yaml配置文件包括通用配置, TLS配置, CA配置, 注册管理配置, 数据库配置, LDAP配置, 组织结构配置, 签名, 证书申请等几部分
version: 1.1.1-snapshot-e656889
port: 7054 # 指定服务的监听端口
debug: false # 是否启用DEBUG模式, 输出更多的调试信息上
crlsizelimit: 512000
# 是否在服务端启用TLS,如果启用TLS后进行身份验证的证书和签名的私钥
tls:
enabled: false # 是否启用TLS, 默认不启用
certfile: # TLS证书文件
keyfile: # TLS密钥文件
clientauth: # 客户端验证配置
type: noclientcert # 默认不进行身份验证
certfiles: # 进行客户端身份验证时, 信任的证书文件列表
# 包括实例的名称、签名私钥文件、身份验证证书和证书链文件;这些私钥和证书文件会用来作为生成ECert、TCert的根证书
ca:
name: # CA服务名称. 可以支持多个服务
keyfile: # 密钥文件(默认: ca-key.pem)
certfile: # 证书文件(默认: ca-cert.pem)
chainfile: # 证书链文件(默认: chain-cert.pem)
crl:
expiry: 24h
# 当fabric-ca-server自身提供用户的注册管理时使用, 此情况下需要禁用LDAP功能, 否则fabric-ca-server将会把注册管理数据转发到LDAP进行查询
registry:
# 允许同一个用户名和密码进行enrollment的最大次数, -1为无限制, 0为不支持登记
maxenrollments: -1
identities: # 注册的实体信息, 可以进行enroll. 只有当LDAP未启用时起作用
- name: admin
pass: adminpw
type: client
affiliation: ""
attrs:
hf.Registrar.Roles: "peer,orderer,client,user"
hf.Registrar.DelegateRoles: "peer,orderer,client,user"
hf.Revoker: true
hf.IntermediateCA: true # 该id是否是一个中间层的CA
hf.GenCRL: true
hf.Registrar.Attributes: "*"
hf.AffiliationMgr: true
# 数据库支持SQLite3、MySQL、Postgres. 默认为SQLite3类型的本地数据库. 如果要配置集群, 则需要选用MySQL或Postgres后端数据库, 并在前端部署负载均衡器(如Nginx或HAProxy)
db:
type: sqlite3
datasource: fabric-ca-server.db # SQLite3文件路径
tls:
enabled: false # 是否启用TLS来连接到数据库
certfiles: # PEM格式的数据库服务器的TLS根证书, 可以指定多个, 用逗号隔开
client:
certfile: # PEM格式的客户端证书文件
keyfile: # PEM格式的客户端证书私钥文件
# 配置使用远端的LDAP来进行注册管理, 认证enrollment的用户和密码, 并获取用户属性信息. 此时, 服务端将按照指定的usrfilter从LDAP获取对应的用户, 利用其唯一识别名(distinguidhed name)和给定的密码进行验证.
# 当LDAP功能启用时, registry中的配置将被忽略
ldap:
enabled: false # 是否启用LDAP, 默认不启用
url: ldap://<adminDN>:<adminPassword>@<host>:<port>/<base> # LDAP的服务地址
tls:
certfiles: # PEM格式的LDAP服务器的TLS根证书, 可以为多个, 用逗号隔开
client:
certfile: # PEM格式的客户端证书文件
keyfile: # PEM格式的客户端证书私钥文件
attribute:
names: ['uid','member']
converters:
- name:
value:
maps:
groups:
- name:
value:
# 组织结构配置
affiliations:
org1:
- department1
- department2
org2:
- department1
# 签发证书相关的配置包括签名方法、证书超时时间等. fabric-ca-server可以作为用户证书的签发CA(默认情况下), 也可以作为根CA来进一步支持其它中间CA
signing:
default: # 默认情况下,用于签署Ecert
usage: # 所签发证书的KeyUsage extension域
- digital signature
expiry: 8760h
profiles: # 不同的签发配置
ca: # 签署中间层CA证书时的配置模板
usage:
- cert sign # 所签发证书的KeyUsage extension域
- crl sign
expiry: 43800h
caconstraint:
isca: true
maxpathlen: 0 # 限制该中间层CA无法进一步签署中间层CA
tls:
usage:
- signing
- key encipherment
- server auth
- client auth
- key agreement
expiry: 8760h
# CA自身证书的申请请求配置. 当CA作为根证书服务时, 将基于请求生成一个自签名的证书; 当CA作为中间证书服务时, 将请求发送给上层的根证书进行签署
csr:
cn: fabric-ca-server # 建议与服务器名一致
names:
- C: US
ST: "North Carolina"
L:
O: Hyperledger
OU: Fabric
hosts:
- kevin-hf
- localhost
ca: # 配置后会加入到证书的扩展字段
expiry: 131400h # 超时时间
pathlength: 1 # 允许产生的中间证书的深度
# 配置所选择的加密库
bccsp:
default: SW
sw:
hash: SHA2
security: 256
filekeystore:
keystore: msp/keystore # 存放密钥文件的路径
# 自动创建除了默认CA外的多个CA实例, 如ca1、ca2等
cacount:
# 可以指定多个CA配置文件路径, 每个配置文件会启动一个CA服务,注意不同配置文件之间需要避免出现冲突(如服务端口、TLS证书等)
cafiles:
# 当CA作为中间层CA服务时的相关配置. 包括父CA的地址和名称、登记信息、TLS配置等.
# 注意: 当intermediate.parentserver.url非空时, 意味着本CA是中间层CA服务,否则为根CA服务
intermediate:
parentserver: # 父CA相关信息
url:
caname:
enrollment: # 在父CA侧的登记信息
hosts: # 证书主机名列表
profile: # 签发所用的profile
label: # HSM操作中的标签信息
tls: # TLS相关配置
certfiles: # 信任的根CA证书
client: # 客户端验证启用时的相关文件
certfile:
keyfile:
fabric-ca-client命令可以与服务端进行交互, 包括五个子命令:
CRL 验证
CRL 一般用于数字证书有效性的验证,当执行revoke 操作后会生成CRL证书作废列表
CRL 是经过CA签名的证书作废列表,用于证书冻结和撤销
一般证书会有CRL地址,供HTTP或者LDAP方式访问,通过解析可得到CRL地址,然后下载CRL 进行验证
CRL 会自动更新,并不是生成后不改变的
AKI: 公钥标识号, 代表了对该证书进行签发机构的身份
查看根证书的AKI与序列号信息:
$ openssl x509 -in .fabric-ca-client/msp/signcerts/cert.pem -text -noout
输出内容如下:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: # 序列号
74:48:88:33:70:1a:01:a0:ad:32:29:6e:c5:ab:5a:fa:3b:91:25:a4
......
X509v3 extensions:
......
X509v3 Authority Key Identifier: # keyid后面的内容就是 AKI
keyid:45:B1:50:B6:CD:8A:8D:C5:9B:9E:5F:75:15:47:D6:C0:AD:75:FE:71
......
单独获取AKI
$ openssl x509 -in .fabric-ca-client/msp/signcerts/cert.pem -text -noout | awk '/keyid/ {gsub (/ *keyid:|:/,"",$1);print tolower($0)}'
输出内容如下:
45b150b6cd8a8dc59b9e5f751547d6c0ad75fe71
单独获取序列号
$ openssl x509 -in .fabric-ca-client/msp/signcerts/cert.pem -serial -noout | cut -d "=" -f 2
输出内容如下:
74488833701A01A0AD32296EC5AB5AFA3B9125A4
er: # 序列号 74:48:88:33:70:1a:01:a0:ad:32:29:6e:c5🆎5a:fa:3b:91:25:a4 … X509v3 extensions: … X509v3 Authority Key Identifier: # keyid后面的内容就是 AKI keyid:45:B1:50:B6:CD:8A:8D:C5:9B:9E:5F:75:15:47:D6:C0:AD:75:FE:71
......
单独获取AKI
````shell
$ openssl x509 -in .fabric-ca-client/msp/signcerts/cert.pem -text -noout | awk '/keyid/ {gsub (/ *keyid:|:/,"",$1);print tolower($0)}'
输出内容如下:
45b150b6cd8a8dc59b9e5f751547d6c0ad75fe71
单独获取序列号
$ openssl x509 -in .fabric-ca-client/msp/signcerts/cert.pem -serial -noout | cut -d "=" -f 2
输出内容如下:
74488833701A01A0AD32296EC5AB5AFA3B9125A4
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
发布者:全栈程序员栈长,转载请注明出处:https://javaforall.cn/181355.html原文链接:https://javaforall.cn