数字证书的原理是什么？

媒介

前一篇文章介绍的 GPG Key 所构建小我的公钥加密系统是基于点对点的散布式信赖，也叫 Web of Trust (WoT)，因为签名膨胀 (signature bloat/spamming) 问题招致 WoT 现实上已经失效，从 gpg 2.2.17 版本起头，key server 已经忽略除自签名以外的签名了。那篇文章所介绍的 X.509 证书是基于权势巨子机构 (Certification Authority) 的信赖，属于中心化的信赖，与 GPG Key 的信赖体例相反。

下面是一个比照：

GPG Key

能够看到，在 GPG Key 系统中，信赖是由用户本身倡议的，一小我搜集到的签名越多，那么他/她的公钥也就越可信。

X.509

在 X.509 证书系统中，信赖是由权势巨子机构（CA）倡议的，一小我的公钥要变得可信，只需要某 CA 的签名即可。

PKI 系统包罗了多种差别的标准和实现，SSH Key, GPG Key，以及 X.509 都是 PKI 中的一员，归根结底，它们都需要处理公钥的可信赖问题。换句话说，当你从差别的路子拿到某个机构，组织或者小我的公钥，若何确认那个公钥就是那个实体的，而不是他人仿冒的。一个必需的步调就是它们都需要把公钥与能标识实体的独一名称停止绑定，通过签名的数量（GPG Key）或者权势巨子性 (X.509 Certificate）来确定公钥能否可信。

什么是 X.509？

有一个国际尺度化组织 ISO，它对各个范畴做出一些尺度标准，以便全球通用，常见的好比 ISO 9000 系列的量量系统。类似的尺度化组织还有良多，ITU（国际电信联盟）就是此中一个，在尺度化的系统里，都是以树状目次构造来组织各个部门的。X.509 就是此中一个目次，它规定了数字证书的尺度，类似的目次还有 X.208 and X.680 等。ITU 最早在 1993 年就指定了 X.509 数字证书尺度，它其实是做为 X.500 项目标一部门，X.500 项目标感化是定义了独一标识一个实体的办法，该实体能够是机构、组织、小我或一台办事器。而 X.509 则把该实体与公钥所绑定联系关系起来，从而供给了通信实体的辨别机造，也就是目前更流行的 X.509 数字证书。

X.509 的最后版本公布于 1988 年。X.509 证书次要由用户公共密钥和用户标识符构成。此外还包罗版本号、证书序列号、CA标识符、签名算法标识、签发者名称、证书有效期等辅助信息。那一尺度的最新版本是X.509 v3，它定义了包罗扩展信息 (extensions)的数字证书。该版数字证书供给了一个扩展信息字段，用来供给更多的灵敏性及特殊应用情况下所需的信息传送。

我们凡是说的证书都是指 X.509 数字证书，若是不加出格申明，都是指 X.509 v3 版本的。简单来说，v3 版本就是添加了扩展字段的证书。

一张典型的 X.509 v3 证书包罗如下内容：

翻开阅读器，能够看到某网站的数字证手札息如下：

权势巨子机构（Certificate Authority）

上面介绍到，X.509 系统中，权势巨子机构 (CA) 是最重要的一环，只要颠末它签名的公钥（包罗在所签发的数字证书中）才是可信的。当我们翻开一个 HTTPS 链接的网页时，阅读器会主动从系统内置的 CA 证书列表中找到对应的 CA 根证书来帮我们帮我们校验网站的数字证书能否合法。而那些 CA 证书凡是在我们安拆操做系统的时候就已经预置在我们的操做系统中（或者我们也能够手动安拆），好比在 Ubuntu 中，预置的 CA 证书所在的目次凡是是 /usr/share/ca-certificates/mozilla/。

权势巨子机构的分级

为了愈加有组织的办理证书系统，CA 也是分级的，按照功用次要分为三个层级：Root CA, Intermediate CA 和 End User，它们会构成一个证书链来确保此中的每个证书都是可信的，我们后续创建 X.509 证书系统的时候就是根据那个层级停止创建。

当我们向某 CA 申请一个数字证书的时候，按照我们供给信息的详细水平以及 CA 对我们停止校验的手段，颁布的数字证书有差别的信赖级别，次要有三品种型的数字证书：

DV, Domain ValidatedOV, Organization ValidatedEV, Extended Validated

那三者的验证级别以及可信水平是逐渐进步的，我们通俗用户想要为本身购置的一个域名（domain）申请数字证书时，凡是其实不需要供给详细小我信息（Country, State, Organization, Email 等等），只需要证明我们是域名的拥有者即可，那时候我们凡是只需要申请 DV 证书；而关于一些大银行、政府机构，他们则会申请 OV 或者 EV 证书来证明本身的可靠性。

若何分辨网站的证书是 DV，OV 仍是 EV 类型？

关于 DV 证书来说，凡是其 Subject 信息中只需要包罗 Common Name 即可，因为它不需要验证明体，只需要验证域名所有权。其它信息好比 Country, Organization 等均可忽略。好比下面是几个例子：

而关于 OV, 或 EV 类型的证书来说，它们都需要验证明体，所以会有 Country, State, Organization 等更详细信息，好比：

其实要判断 DV, OV 仍是 EV，一个更准确的体例是通过 OID 来判断，OID (Object ID）是 ISO 中的条目标独一编号，证书中的固定属性凡是已经注册了独一标识符 OID，证书类型的 OID 如下：

Type Policy Identifier

Domain Validated 2.23.140.1.2.1

Organization Validated 2.23.140.1.2.2

Extended Validated 2.23.140.1.1

因而，我们查看 v3 Extension 中的 Policy ID 字段即可得知证书实在类型：

好比：

bankofamerica.com (EV 证书)

stackoverflow.com

(DV 证书)

权势巨子机构都有哪些？

常见的权势巨子机构有 Sectigo, SSL.com, DigiCert, GlobalSign, Entrust (GTS) Google Trust Services, ISRG (Internet Security Research Group) 等等，那些 CA 普遍遭到信赖，它们的根证书几乎预置在所有设备中，因而由它们所签发的证书都遍及遭到信赖。好比，国内的京东和淘宝都是用 GlobalSign 签发的证书，而常见的社交媒体 Twitter, Facebook, Instagram 等网站则都是用 DigiCert 签发的证书，Google 的办事大大都用 GTS 签发，而一些开发类的网站或者博客站点（好比 http://stackoverflow.com 等）凡是会选择利用 ISRG（也就是 Lets Encrypt ）所签发的证书，因为申请 Lets Encrypt 证书是免费的，而申请其它 CA 的证书都需要一笔费用。

X.509 v3 Extensions

若是不加任何限制，我们所说的证书都是 X.509 v3 版本的证书，它是在 RFC 5280 中描述、 CA/Browser Forum Baseline Requirements 中进一步完美的 PKIX 变种。X.509 v3 正式是目前最通用的证书格局，比拟之前的版本，v3 版本次要多了扩展字段，在我们正式脱手创建证书系统之前，有需要对那些扩展字段有必然的领会。

下图展现了 v1, v2, v3 版本的区别：

OpenSSL

在正式创建证书之前，我们对 OpenSSL 东西有一个简单的领会，openssl 是 Linux 下最常见的一个 PKI 东西，用来创建密钥和数字证书十分便利。原来我是写若何用 vault + cert-manager 来办理 k8s 集群证书的，而 cert-manager 能够主动引入 vault 中的 PKI 证书系统，所以用起来会愈加便利。但是究竟结果 OpenSSL 东西愈加通用和普遍一些，固然略微难用，那也是因为 PKI 自己就比力复杂，概念繁多所形成的。掌握并理解 OpenSSL 之后，换成其它 KMS 也会相对简单良多。

安拆 OpenSSL

建议安拆最新版本的 OpenSSL (纷歧定最新，但建议版本在 openssl 1.1.1+，老的版本会有 CVE 高危破绽)

$ wget https://www.openssl.org/source/openssl-1.1.1n.tar.gz $ tar xf openssl-1.1.1n.tar.gz $ cd openssl-1.1.1n $ ./config --prefix=/usr/local/openssl $ make & make install

OpenSSL 常见号令

genrsacareqx509crlececparamencans1parse...

OpenSSL 的设置装备摆设文件

默认的设置装备摆设文件位于 /etc/ssl/openssl.cnf

openssl.conf 中的设置装备摆设包罗多个段落 (sections)，能够互相引用，openssl 的 ca 和 req 两个号令会引用对应名称的段落，好比 ca 号令会引用 [ ca ] 段落，而 req 号令会引用 [ req ] 段落。

在创建证书前，我们能够为我们的证书系统创建一个根目次，所有的证墨客成都在那个目次下，从上图中能够看到，我们在操做之前应该按照本身的需求创建响应的目次及文件。

创建三级证书系统

我们创建三级证书系统的目标是为了便利我们在私网（好比 Home Lab）办理集群以及摆设浩瀚的 web 应用，微办事，存储及平安战略。因而，证书系统与公网情况下的并没有太大区别，需要有 Root CA，Intermediate CA 以及差别应用所需的 User Certificate。之所以良多人还停留在手工造做临时性的自签名证书阶段，是因为 PKI 系统确实比力复杂繁琐。但是，不竭地把自签名导入阅读器或者系统的 Key Store 中不只会招致 Key Store 的紊乱和难以办理，并且也会增加没必要要的风险。当我们有了本身的 Root CA，而且所有的用户端证书都由响应的 Intermediate CA 来签发时，我们只需要把 Root CA 导入系统的 Key Store 即可，不只一劳永逸的处理浩瀚自签名证书的懊恼，并且证书的办理也变得愈加合理。

按照规划，我们想要的证书系统次要包罗三个构成部门：Root CA Certificate, Intermediate CA Certificate, 以及 User Certificates，完好证书链如下：

创建 Root CA 证书

起首，应该创建响应的目次及文件，接下来所有操做都在该目次中停止

$ mkdir facttrust $ cd facttrust $ mkdir -p CA/private newcerts $ touch index.txt $ echo -ne "00" > serial $ echo -ne 00 > crlnumber

按照 /etc/ssl/openssl.cnf 中 [ CA_default ] 段落的设置装备摆设信息修改成与我们上述步调所创建的目次和文件对应的值，建议零丁放在一个文件中（好比 ca.cnf），能够制止对全局的设置装备摆设文件停止修改。

如许设置装备摆设之后，后续利用 openssl ca 号令签发或撤销下级证书的时候会主动读取 [ ca ] 段落的设置装备摆设信息。

Root CA 证书格局

想要创建一个与公网情况下不异功用的 Root CA 证书，先考察一下目前流行的权势巨子 CA 证书的构造，能够施行如下号令：

$ openssl x509 -noout -text -in /usr/share/ca-certificates/DigiCert_Global_Root_CA.crt$ tar xf openssl-1.1.1n.tar.gz $ openssl x509 -noout -text -in /usr/share/ca-certificates/Buypass_Class_3_Root_CA.crt$ ./config --prefix=/usr/local/openssl $ openssl x509 -noout -text -in /usr/share/ca-certificates/SSL.com_Root_Certification_Authority_RSA.crt

上述号令查看了支流的几个权势巨子机构的根证书的组织构造，总结有如下特点：

Self-signed (DV, OV, EV) 根证书都是自签名的Validity: 20 ~ 30 years 有效期都在 20 ~ 30 年摆布x509 v3 extensions 包罗的 v3 扩展字段有如下几个：

[v3_ca]subjectKeyIdentifier = hashauthorityKeyIdentifier = keyid:always,issuer:alwaysbasicConstraints = critical,CA:true,pathlen:3 # 大都没有 pathlen 限造keyUsage = critical, cRLSign,keyCertSign,digitalSignature # 大都没有 digitalSignatureextendedKeyUsagesubjectAltName

总结：

(1) Root CA 的扩展字段均没有 extendedKeyUsage, subjectAltName, Certificate Authority Information Access, CRL Distribution Points, Certificate Policies 等字段，而那些字段次要呈现在 Intermediate CA 和 User Certificate 中。

(2) 有的 Root CA 设置了pathlen（好比 /usr/share/ca-certificates/mozilla/Baltimore_CyberTrust_Root.crt），pathlen 次要是限造 Root CA 部属的 Intermediate CA 的层级数量。若是没有设置 pathlen，则无限造。若是 pathlen = 0，申明不克不及有 Intermediate CA，只能用于签发用户证书。一般来说，Root CA 的 pathlen 无限造（在 vault 中默认 -1），而 Intermediate 证书的 pathlen 一般设置为 0 或 1，证书链不宜太长。

(3) Root CA 的 Key Usage 凡是只要 CRL Sign 和 Certificate Sign，也就是只用来签发和撤消证书（更切当的说是只用来签发和撤消 Intermediate CA Certificates），不外也有放宽到 digitalSignature 的，好比 /usr/share/ca-certificates/mozilla/DigiCert_Global_Root_CA.crt。

利用 openssl 号令来创建 Root CA 证书：

证书名字模拟支流权势巨子机构起名 (Common Name) 为 FactTrust Root CA有效期 20 年私钥算法和长度：RSA:4096 （默认 2048)摘要签名算法：SHA256 (默认 SHA256)密钥能否加密：不加密

$ openssl req -x509 -newkey rsa:4096 -sha256 -days 7300 -nodes \ -keyout FactTrust_Root_CA.key -out FactTrust_Root_CA.crt \ -subj "/C=US/ST=TX/L=DAL/O=Security/OU=IT Department/CN=FactTrust Root CA" \ -addext keyUsage=critical,cRLSign,keyCertSign,digitalSignature \ -addext basicConstraints=critical,CA:true,pathlen:3

注解：

(1) 整个号令会同时生成密钥 .key 和证书 .crt，默认是 PEM 格局。

(2) openssl 默认会接纳交互式的体例要求你填写 Subject 信息（Country Name, State, Locality, Organization, Common Name 以及 Email 等信息），利用 -subj 选项能够一次性填入，无需交互。别的，若是你仅想利用默认值，而且制止交互，那么能够用 -batch 选项。

(3) 利用 -addext 选项添加 customized X509 v3 extenstions。

(4) -nodes 表白不合错误 private key 停止加密，若是没有那个选项，那么会提醒你输入一个密码来庇护 private key。

加密 Private Key

因为 Private key 的重要性，应该接纳愈加平安的体例来庇护它，也就是把它停止加密。openssl 默认利用的是 DES3 的对称加密体例，但是它 block size 只要 56 位，被认为不是足够平安，保举利用 AES 的加密体例。

接下来我们生成一个密码文件，并把密码文件加盐加密，然后用那个密码文件对密钥停止加密，利用 AES256。

1) 生成密码文件

$ echo !mrgWnh*2dEgpdE4X= > capass $ openssl enc -aes256 -pbkdf2 -salt -in capass -out capass.enc

解密密码文件能够用如下号令：

$ openssl enc -aes256 -pbkdf2 -salt -d -in capass.enc

2) 生成 Root CA 的 Private key 和 Certificiate

$ openssl req -x509 -newkey rsa:4096 -sha256 -days 7300 -passout file:capass.enc \ -keyout FactTrust_Root_CA.key -out FactTrust_Root_CA.crt \ -subj "/C=US/ST=TX/L=DAL/O=Security/OU=IT Department/CN=FactTrust Root CA" \ -addext keyUsage=critical,cRLSign,keyCertSign,digitalSignature \ -addext basicConstraints=critical,CA:true,pathlen:3

上述号令把之前的 -nodes 替代成了 -passout file:capass.enc 之后，生成的 FactTrust_Root_CA.key 会是加密后的格局，如下：

我们用 openssl asn1parse 号令解析该私钥会发现，它默认利用的是 DES3 体例加密，如下：

接下来，我们把它转换成 AES256 体例加密。

在操做前，同样，先筹办一个密码文件，之前利用的是默认 DES3 加密，而此次利用 AES256 加密，所以需要再筹办另一个密码文件，不外你也能够用之前的，只不外你需要再拷贝一份，因为 openssl 不撑持 -passin 和 -passout 利用统一个密码文件。

$ echo 6Cz4P$9bW8ZB55^j=v > aespass $ openssl enc -aes256 -pbkdf2 -salt -in aespass -out aespass.enc

利用 openssl pkcs8 号令转换成 AES256 加密：

$ openssl pkcs8 -topk8 -v2 aes256 -in FactTrust_Root_CA.key -out FactTrust_Root_CA-PKCS8-AES256.key -passin file:capass.enc -passout file:aespass.enc

解释：

-topk8 选项就是转换成 pkcs#8 格局，它比 pkcs#1 格局多 20 字节，次要用于描述算法类型等 metadata 信息。pkcs#1 只撑持 RSA 密钥算法，而 pkcs#8 愈加通用，撑持多种密钥算法。对称加密算法是在 pkcs#5 中定义的，pkcs#5 v1.5 只撑持 DES 算法，而 v2 则撑持 AES 等算法。

-v2 aes256 引用的是 pkcs#5 的 v2 版本，我们能够省略该选项，因为 pkcs8 号令默认就是利用 pkcs#5 的 v2 中的 aes256 算法。

别的，也能够用 openssl rsa 号令来转换，不外它会生成传统的 pkcs#1 格局的密钥。

$ openssl rsa -aes256 -in FactTrust_Root_CA.key -out FactTrust_Root_CA-PKCS1-AES256.key -passin file:capass.enc -passout file:aespass.enc

再次通过 openssl asn1parse 号令查抄 key 格局，就已经是 aes256 加密的了，如下：

若是在某些主动化场景或者云情况中（无法拜候我们的密码文件），那么我们可能需要用到非加密的 Private Key，下面的号令能够把 Encrypted Private Key 转换成 Unencrypted Private Key：

$ openssl pkcs8 -topk8 -nocrypt -passin file:aespass.enc -in FactTrust_Root_CA-PKCS8-AES256.key -out pkcs8-unencrypted-FactTrust_Root_CA.key $ openssl rsa -in FactTrust_Root_CA-PKCS8-AES256.key -out unencrypted-FactTrust_Root_CA.key -passin file:aespass.enc

加密后的私钥遭到密码的庇护，因而，只要需要拜候到 Private Key 的场景，都需要用到密码文件，利用 -passin 选项传入密码文件，好比下面的号令用于提取公钥：

$ openssl rsa -in FactTrust_Root_CA-PKCS8-AES256.key -pubout -out pub-FactTrust_Root_CA.key -passin file:aespass.enc

重生成的 Root CA 证书能够利用 openssl x509 号令查看：

$ openssl x509 -noout -text -in FactTrust_Root_CA.crt

最初，别忘了把创建好的 Key 和 CRT 放入 [ CA_default ] 中指定的目的目次

$ mv FactTrust_Root_CA-PKCS8-AES256.key CA/private/

接下来，创建一个撤销列表 CRL，因为目前并没有签发和撤销过下级证书，所以 CRL 必定是空的：

$ openssl ca -gencrl -config ca.cnf -out crl.pem -passin file:aespass.enc

步调总结：

1. 先一键式创建 Root CA 的 Key 和 CRT（并为 Key 添加密码庇护）

2. 把对 Key 的加密庇护体例转换成 AES256 加密（因为 openssl req 号令默认只能对 Key 停止 DES3 加密）

上面介绍的是 One-liner 一键式的创建 Root CA，一个更常见的流程是先创建 Key，然后创建 CSR，然后用 Key 对 CSR 签名从而得到 CRT。

那里就不外多介绍，因为下面我们创建 Intermediate CA 证书以及 User 证书时会用那个流程来创建。

创建 Intermediate CA 证书

创建目次

同 Root CA，我们为 Intermediate CA 创建零丁的目次及需要文件

$ mkdir facttrust-rsa-ica1 $ cd facttrust-rsa-ica1 $ mkdir -pv CA/private newcerts $ touch index.txt $ echo -ne "00" > serial $ echo -ne 00 > crlnumber

目次构造同样在根据 [ CA_default ] 段落的设置装备摆设信息修改，那里为制止对全局的设置装备摆设文件停止修改，也零丁创建一个设置装备摆设文件来存放设置装备摆设信息 ica.cnf，

创建 Intermediata CA 证书的简要步调：

1. 先创建 Key Pairs

2. 设置装备摆设需要的 v3 extensions 信息，并据此创建 CSR

3. 对 CSR 签名从而得到 CRT

创建 Intermediate CA 证书和 末端 User 证书的步调比力类似，因为它们都能够被撤消，所以我们需要为它们创建编号 (Serial Number) 以即可以记录它们的创建序列，Serial Number 必需是独一的，撤销时会根据 Serial Number 来停止撤销。Root CA 凡是不主动撤消，所以在被创建时，它的 Serial Number 会是一个独立的随机值，它不在那个我们接下来要利用的 Serial Nubmer List 中。

Intermediate CA 证书的格局（组织构造）

在创建之前，我们先扒拉下来一些支流权势巨子机构的中间证书，通过参考它们的组织构造来构造我们的中间证书。

我们能够间接翻开某 HTTPS 网站来查看此中间证书，

能够看到，v3 extensionts 部门比 Root CA 多了很多内容，好比 Extended Key Usage, Certificates Policies, CRL Distribution Points 等。

别的，Intermediate CA 证书的有效期也要更短，凡是是 3 ~ 10 年。其它部门与 Root CA 没有太大区别。

若是需要下载 PEM 格局的 Intermediate CA 证书和 User 证书，能够利用如下号令：

$ openssl s_client -connect github.com:443 -showcerts </dev/null $ openssl s_client -connect github.com:443 -showcerts </dev/null | openssl x509 -outform PEM > github.pem

Intermediate CA 证书格局：

在查看了几个支流的权势巨子机构的中间证书的组织构造后，能够总结如下：

Issued by Root CA Intermediate CA 证书由 Root CA 签名Validity: 3 ~ 10 years 有效期在 3 ~ 10 年摆布x509 v3 extensions 包罗的 v3 扩展字段有如下几个：

[v3_ca]subjectKeyIdentifier = hashauthorityKeyIdentifier = keyid:always,issuer:alwaysbasicConstraints = critical,CA:true,pathlen:0 # pathlen:0 暗示只能签发端证书，不克不及再有 intermediate CA

keyUsage = critical, cRLSign,keyCertSign,digitalSignature extendedKeyUsage=clientAuth,serverAuthauthorityInfoAccessOCSPCA IssuerscrlDistributionPoints = URI:http://crl.pki.goog/gtsr1/gtsr1.crl

certificatePoliciesPolicy ID #1Qualifier ID #1CPS: URIUserNotice

subjectAltName

总结：

(1) 比拟 Root CA，Intermediate CA 的扩展字段增加了 extendedKeyUsage, Certificate Authority Information Access, CRL Distribution Points, Certificate Policies 等字段，不外仍然没有 subjectAltName。subjectAltName 凡是只呈现在 User 证书上。除此之外，Intermediate CA 和 User Certificate 的扩展字段根本不异。

(2) Intermediate CA 证书的pathlen 一般设置为 0 或 1，也就是不再下辖下级中间证书或者最多鄙人辖一个中间证书。

利用 openssl 号令来创建 Intermediata CA 证书：

Intermediata CA 证书起名 (Common Name) 为 FactTrust Secure RSA ICA1有效期 5 年Country Name 和 Organization 与 Root CA 对应的值不异私钥算法和长度：RSA:4096 （默认 2048)摘要签名算法：SHA256 (默认 SHA256)密钥能否加密：加密

1. 创建 Key pairs (密码庇护)

$ cd facttrust-rsa-ica1 $ echo Uw3b4r#6Nn6$gMJi^7 > icapass $ openssl enc -aes256 -pbkdf2 -salt -in icapass -out icapass.enc $ openssl genrsa -aes256 -passout file:icapass.enc -out FactTrust_RSA_ICA1.key 4096

上述号令生成的是 pkcs#1 格局的 Key，如下：

pkcs#1 格局的 Key 无法用 openssl asn1parse 号令读取，我们应该把它转换成更通用的 pkcs#8 格局的 Key

$ cp icapass.enc icapass-pkcs8.enc $ openssl pkcs8 -topk8 -in FactTrust_RSA_ICA1.key -out FactTrust_RSA_ICA1-PKCS8.key -passin file:icapass.enc -passout file:icapass-pkcs8.enc

转换胜利后：

2. 创建 CSR $ openssl req -new -sha256 -passin file:icapass-pkcs8.enc \ -key FactTrust_RSA_ICA1-PKCS8.key -out FactTrust_RSA_ICA1-PKCS8.csr \ -subj="/C=US/O=Security/CN=FactTrust Secure RSA ICA1" \ -reqexts req_ext -config <(cat /etc/ssl/openssl.cnf -<<END [req_ext] basicConstraints = critical,CA:true,pathlen:0 subjectKeyIdentifier = hash keyUsage = critical,digitalSignature,keyCertSign,cRLSign extendedKeyUsage = clientAuth,serverAuth subjectAltName = DNS.1:localhost,DNS.2:winkee.lab,DNS.3:*.winkee.lab,IP.1:127.0.0.1,IP.2:192.168.1.3 authorityInfoAccess = OCSP;URI:http://ocsp.facttrust.com/,caIssuers;URI:http://facttrust.com/certs/FactTrustRootCA.der crlDistributionPoints = URI:http://crl.facttrust.com/FactTrustRootCA.crl certificatePolicies = @pol [pol] policyIdentifier = 2.5.29.32.0 CPS.1 = "https://www.facttrust.com/CPS" userNotice.1 = @notice [notice] explicitText = "UTF8:Notice An use of this Certificate constitutes acceptance of the Relying Party Agreement located at https://www.facttrust.com/rpa-ua" END )

解释：

req 号令会利用设置装备摆设文件中 [ req ] 段落中的内容，若是是利用 req 号令创建 CSR，那么 CSR 中的扩展字段由 req_extension 决定，若是是利用 req -x509 号令，那么 crt 中的扩展字段由 x509_extensions 决定，如下：

-reqext 选项用来指定一个笼盖 req_extensions 值的段落，我们看到，它默认的值是来自 v3_req 段落。那里我们利用了一个自定义的段落 req_ext 来笼盖其默认值。

上述号令为了便利，所以用的是 One-liner，我们完全能够把其内容填写到一个零丁文件中，然后同样引用该文件中的 req_ext 段落即可，

reqexts.cnf

$ cat reqexts.cnf [req_ext] basicConstraints = critical,CA:true,pathlen:0 subjectKeyIdentifier = hash keyUsage = critical,digitalSignature,keyCertSign,cRLSign extendedKeyUsage = clientAuth,serverAuth authorityInfoAccess = OCSP;URI:http://ocsp.facttrust.com/,caIssuers;URI:http://facttrust.com/certs/FactTrustRootCA.der crlDistributionPoints = URI:http://crl.facttrust.com/FactTrustRootCA.crl certificatePolicies = @pol [pol] policyIdentifier = 2.5.29.32.0 CPS.1 = "https://www.facttrust.com/CPS" userNotice.1 = @notice [notice] explicitText = "UTF8:Notice An use of this Certificate constitutes acceptance of the Relying Party Agreement located at https://www.facttrust.com/rpa-ua"

generate CSR

$ openssl req -new -sha256 -passin file:icapass-pkcs8.enc \ -key FactTrust_RSA_ICA1-PKCS8.key -out FactTrust_RSA_ICA1-PKCS8.csr \ -subj="/C=US/O=Security/CN=FactTrust Secure RSA ICA1" \ -reqexts req_ext -config <(cat ica.cnf reqexts.cnf)

查看 CSR 以确定格局准确

$ openssl req -text -noout -in FactTrust_RSA_ICA1-PKCS8.csr

若是格局不准确，我们能够调整参数，继续从头生成。

3. 利用 Root CA 证书对 Intermediate CSR 签名

CSR 创建好了之后，利用 Root CA 对其签名就能够得到 Intermediate CA 证书了

签名时需要留意几点：

1）openssl ca 号令会有 policy matching 要求，一般来说，Country Name 和 Organization 必需婚配，Common Name 必需供给。

2）能够间接利用 [ CA_default ] 中的 copy_extensions 字段来把 CSR 中的 extension 都拷贝到最末的 .crt 中，但是一般其实不建议那么做，而是由 CA 签发是本身决定最末的 extensions 有哪些（保留 CA 的自主决定权）。

openssl ca 号令利用 -extensions 选项来笼盖默认的 x509_extensions 字段。

因为是利用 Root CA 停止签发，所以我们需要回到 Root CA 目次，

$ cd ../facttrust/

然后施行如下的签发号令：

$ openssl ca -days 1825 -passin file:../facttrust/CA/private/aespass.enc \ -in FactTrust_RSA_ICA1-PKCS8.csr -out FactTrust_RSA_ICA1-PKCS8.crt \ -cert ../facttrust/FactTrust_Root_CA.crt \ -keyfile ../facttrust/CA/private/FactTrust_Root_CA-PKCS8-AES256.key \ -create_serial \ -extensions req_ext \ -config <(cat ica.cnf reqexts.cnf) \ -policy policy_match

最末签发的证书还会拷贝一份在 newcerts/ 中，定名体例是 <serial-number>.pem，我们来查看最末的证书：

$ openssl x509 -text -noout -in FactTrust_RSA_ICA1-PKCS8.crt

签发之后, index.txt 中会有一笔记录

创建 User/Leaf 证书

User 证书处于证书链的最下流，因而也叫 Leaf 证书。我们日常平凡接触最多的就是 User 证书，因为所有的 HTTPS 应用都需要一个合法的 User 证书才气一般工做。

创建 User 证书的步调与创建 Intermediate CA 证书并没有区别，流程都是：

1. 先创建 Key Pairs

2. 设置装备摆设需要的 v3 extensions 信息，并据此创建 CSR

3. 对 CSR 签名从而得到 CRT

User 证书的格局

前面介绍过，User 证书中的 extensions 字段与 Intermediate CA 证书根本不异，独一一个区别是 User 证书中有 subjectAltName 字段，那也是重要的一个字段，若是你签发的 User 证书没有那个字段，那么会被认为不是一个合规的证书，阅读器会回绝。

利用 openssl 号令来创建 User 证书：

User 证书的名字 (Common Name) 凡是为域名或泛域名。有效期 1 年（短的有 1 到 3 个月，长的则 1 年摆布）证书类型：DVPolicy ID 为 2.23.140.1.2.1DV 类型的证书 Subject 中只需要填写 Common Name。Key Usage: Digital Signature, Key EnciphermentExtended Key Usage: Client Auth, Server Auth

私钥算法和长度：RSA:4096 （默认 2048)摘要签名算法：SHA256 (默认 SHA256)密钥能否加密：否

1. 创建 Key + CSR

那里我们能够间接同时创建 Key 和 CSR

$ openssl req -new -sha256 -nodes \ -keyout winkee.key -out winkee.csr \ -subj "/CN=*.winkee.lab" \ -reqexts user_ext -config <(cat /etc/ssl/openssl.cnf -<<END [user_ext] basicConstraints = CA:FALSE subjectKeyIdentifier = hash keyUsage = digitalSignature, keyEncipherment extendedKeyUsage = clientAuth,serverAuth authorityInfoAccess = OCSP;URI:http://ocsp.facttrust.com/,caIssuers;URI:http://facttrust.com/certs/FactTrustRSAICA1.der crlDistributionPoints = URI:http://crl.facttrust.com/FactTrustRSAICA1.crl certificatePolicies = @pol [pol] policyIdentifier = 2.23.140.1.2.1 # DV certificate CPS.1 = "https://www.facttrust.com/CPS" END )

生成的 key 已经是 pkcs#8 格局的，所以无需转换。

查看 CSR 以确定格局准确

$ openssl req -text -noout -in winkee.csr

若是格局不准确，我们能够调整参数，继续从头生成。

2. 利用 Intermediate CA 证书对用户证书签名

因为是利用 Intermediate CA 停止签发，所以接下来的签发操做请确保在 Intermediate CA 目次中停止。

$ openssl ca -days 365 \ -in winkee.csr -out winkee.crt \ -cert ./FactTrust_RSA_ICA1-PKCS8.crt \ -keyfile ./CA/private/FactTrust_RSA_ICA1-PKCS8.key \ -create_serial \ -extensions user_ext \ -config <(cat ica.cnf user.cnf) \ -policy policy_anything

同样，最末签发的证书会拷贝一份在 newcerts/ 目次中，定名体例是 <serial-number>.pem，我们来查看最末的证书：

$ openssl x509 -text -noout -in winkee.crt

签发之后, index.txt 中会有一笔记录

至此，我们就创建了一个完好的证书系统啦。若是需要签发更多的证书，我们只需要根据上面的步调依葫芦画瓢就能够完成。

当然，还留下了一些其它细节有待进一步切磋，好比 User 证书的分发，CRL 列表更新，OCSP 办事器的成立等等，留待后续文章继续介绍。

引用链接

[1] rfc5280 https://datatracker.ietf.org/doc/html/rfc5280

[2] AES vs. DES Encryption: Why AES has replaced DES, 3DES and TDEA https://www.precisely.com/blog/data-security/aes-vs-des-encryption-standard-3des-tdea#:~:text=In%20terms%20of%20structure%2C%20DES,to%20create%20the%20encrypted%20block.

[3] Converting a Traditional PEM-Encoded Encrypted Private Key to PKCS#8 Format https://help.globalscape.com/help/archive/secureserver3/Converting_an_incompatible_traditional_PEM_encoded_encrypted_private_key.htm

[4] x509v3_confighttps://www.openssl.org/docs/man1.0.2/man5/x509v3_config.html

[5] OpenSSL Certificate Authority https://wechris.github.io/tips-tutorials/openssl/ssl/tls/security/certificate/2018/06/16/OpenSSL-Certificate-Authority-Part1/

[6] PGP - The Web of Trust is Dead https://inversegravity.net/2019/web-of-trust-dead/

[7] PGP Web of Trust: Delegated Trust and Keyservers https://www.linux.com/news/pgp-web-trust-delegated-trust-and-keyservers/

[8] OpenSSL create self signed certificate Linux with example https://www.golinuxcloud.com/generate-self-signed-certificate-openssl/

[9] The Most Popular SSL Certificate Authorities Reviewed https://wpmudev.com/blog/ssl-certificate-authorities-reviewed/

[10] Openssl: Setup an intermediate CA https://michlstechblog.info/blog/openssl-setup-an-intermediate-ca/

[11] Error getting keypair for CA issuerhttps://github.com/cert-manager/cert-manager/issues/279

[12] Intermediate CA configuration file https://jamielinux.com/docs/openssl-certificate-authority/appendix/intermediate-configuration-file.htm

[13] How to setup your own CA with OpenSSL https://gist.github.com/jalogisch/d5daa6781ee0c1452e8929814d9bba53

[14] Everything you should know about certificates and PKI but are too afraid to ask: https://smallstep.com/blog/everything-pki/

若是你觉得我的文章对你有帮忙，欢送留言或者存眷我的专栏。

微信公家号：“知辉”

搜刮“deliverit”或

扫描二维码