OpenSSL 密码库实现证书签发流程详解

0. 基础理论

参考：openssl证书签发流程详解

openssl简介

openssl 是目前最流行的 SSL 密码库工具，其提供了一个通用、健壮、功能完备的工具套件，用以支持 SSL/TLS 协议的实现。

构成部分

• 密码算法库
• 密钥和证书封装管理功能
• SSL通信API接口

用途

• 建立 RSA、DH、DSA key 参数
• 建立 X.509 证书、证书签名请求(CSR)和CRLs(证书回收列表)
• 计算消息摘要
• 使用各种 Cipher加密/解密
• SSL/TLS 客户端以及服务器的测试
• 处理S/MIME 或者加密邮件

数字证书标准

• X.509版本号：指出该证书使用了哪种版本的X.509标准，版本号会影响证书中的一些特定信息
• 序列号：由CA给予每一个证书分配的唯一的数字型编号，当证书被取消时，实际上是将此证书序列号放入由CA签发的CRL（Certificate Revocation List证书作废表，或证书黑名单表）中。这也是序列号唯一的原因
• 签名算法标识符 ：用来指定CA签署证书时所使用的签名算法，常见算法如RSA
• 签发者信息：颁发证书的实体的 X.500 名称信息。它通常为一个 CA
• 证书的有效期：证书起始日期和时间以及终止日期和时间；指明证书在这两个时间内有效。
• 主题信息：证书持有人唯一的标识，在 Internet上应该是唯一的
• 发布者的数字签名：这是使用发布者私钥生成的签名，以确保这个证书在发放之后没有被撰改过
• 证书的公钥：包括证书的公钥、算法(指明密钥属于哪种密码系统)的标识符和其他相关的密钥参数

数字证书格式

• CSR：证书请求文件，这个并不是证书，而是向证书颁发机构获得签名证书的申请文件
• CER：存放证书文件可以是二进制编码或者 Base64 编码
• CRT：证书可以是DER编码，也可以是PEM编码，在linux系统中比较常见
• pem：该编码格式在RFC1421中定义，但他也同样广泛运用于密钥管理，实质上是 Base64 编码的二进制内容
• DER：用于二进制DER编码的证书。这些证书也可以用CER或者CRT作为扩展名
• JKS：java的密钥存储文件,二进制格式,是一种 Java 特定的密钥文件格式， JKS的密钥库和私钥可以用不同的密码进行保护
• p12/PFX：包含所有私钥、公钥和证书。其以二进制格式存储，也称为 PFX 文件，在windows中可以直接导入到密钥区，密钥库和私钥用相同密码进行保护

数字证书和公钥的关系

数字证书是经过权威机构（CA）认证的公钥，通过查看数字证书，可以知道该证书是由哪家权威机构签发的，证书使用人的信息，使用人的公钥。它有以下特点：

• 由专门的机构签发的数字证书才安全有效。
• 签发数字证书是收费的。
• 不会被冒充，安全可信。
• 数字证书有使用期限，过了使用期限，证书变为不可用。CA也可以在试用期内，对证书进行作废操作。

什么是x.509

X.509 就是其中一个目录，它规定了数字证书的标准。ITU 最早在 1993 年就指定了 X.509 数字证书标准，它其实是作为 X.500 项目的一部分，X.500 项目的作用是定义了唯一标识一个实体的方法，该实体可以是机构、组织、个人或一台服务器。而 X.509 则把该实体与公钥所绑定关联起来，从而提供了通信实体的鉴别机制，也就是目前最流行的 X.509 数字证书。我们通常说的证书都是指 X.509 数字证书，如果不加特别说明，都是指 X.509 v3 版本的。简单来说，v3 版本就是添加了扩展字段的证书。

对称加密和非对称加密

对称加密，就是加密和解密用同一份密钥，而非对称加密，就是加密和解密用不同的密钥。

对称加密的问题在于，需要双方都知道密钥，而密钥一旦需要在通信中传递就有被窃取的可能，这样加密的内容也会被窃取。

非对称加密，主体需要准备一对密钥，一个叫做私钥，自己留着，一个叫做公钥，发送给要通信的对象。私钥加密的数据，用公钥可以解开，公钥加密的数据，用私钥可以解开。并且即使公钥被其他人知道，远端通信的对象发送来的数据也是安全的，因为公钥加密的数据公钥解不开，但是此时私钥加密的数据就会被知道了。所以一般情况下，私钥加密数据被用作身份验证，叫做签名。

对称加密：  明文 --（A）密钥加密--> 密文 --（B）同一份密钥解密--> 明文
非对称加密：明文 --（A）公钥加密--> 密文 --（B）私钥解密--> 明文
            明文 --（B）私钥签名--> 密文 --（A）公钥验签--> 明文
          （此处公私钥由B生成）
1
2
3
4

非对称加密虽然解决了对称加密的问题，但仍然存在着安全隐患。假如此时有一个中间人，他也生成了自己的公钥和私钥，并且先一步与A和B分别建立了联系，获取了B的公钥，又把自己的公钥给了A，而A以为这个公钥是B的，那么：

明文 --（A）中间人的公钥加密 --> 密文 --（中间人）中间人的私钥解密--> 明文
明文 --（中间人）B的公钥加密 --> 密文 --（B）B的私钥解密--> 明文
1
2

此时A和B都以为自己在和对方通信，但是中间人已经获取了加密的内容，甚至可以进行篡改。所以我们还要保证公钥在分发的过程中不能出现差错。

为了解决这个问题，出现了另一个办法，这个办法涉及到了第三方，叫做证书授权机构（Certificate Authority简称CA），并且，这个方法工作的前提是，A已经正确的拥有了CA的公钥。

工作的流程是这样的：

1: CA用自己的私钥生成一个自签名的证书
2: B向CA发起请求，CA用自己的私钥和证书，使用B的私钥为其签发证书，证书中包含B的公钥信息
3: B把自己的证书发送给A，同时用自己的私钥签名了一些东西也发了过去，A拿着CA的证书验证B证书，如果验证没有问题，就从证书中拿到B的公钥，然后拿这个公钥对收到的数据验证签名确定身份
4: 最后A就可以用这个公钥和B通信了 	
1
2
3
4

参考链接：https://zhuanlan.zhihu.com/p/456089100

生成证书流程原理

1: 用户生成自己的私钥文件(.key)
2: 用户基于私钥生成证书请求文件(.csr)
3: 用户将证书请求文件(.csr)提交给证书颁发机构（CA），CA会对提交的证书请求中的所有信息生成一个摘要，然后使用CA根证书对应的私钥进行加密，这就是所谓的“签名”操作，完成签名后就会得到真正的签发证书(.cer或.crt)
4: 用户拿到签发后的证书，可能需要导入到自己的密钥库中，或根据需要再进行各种格式转换(.pem .p12 .jks等等)
1
2
3
4

权威机构 (CA，Certificate Authority) 是最重要的一环，只有经过它签名的公钥（包含在所签发的数字证书中）才是可信的。

生成证书的方式有以下三种：

• 标准CA签发流程
• 生成自签名证书
• 生成私有CA签发的证书

CA签发流程

标准签发流程

1: 首先创建私钥
openssl genrsa -out server.key 2048

2：基于私钥创建证书签名请求
openssl req -new -key server.key -out server.csr -subj "/C=CN/ST=beijing/L=beijing/O=ceshi/OU=devops/CN=test.com"

# csr这一步可以使用交互式输入
# -subj格式：国家/省/城市/组织/部门/名称/其他可选值
# 在请求中提交了申请人的一些组织信息之外，最重要的就是把上一步中生成的私钥作为参数传给命令行，这是因为命令行工具能根据私钥算出对应的公钥，公钥是未来证书的核心组成部分。

3：将证书申请请求（.csr）提交给CA认证机构申请证书。这个过程在CA机构那里完成，无法在本地使用命令完成。走标准CA签发流程，是CA机构来操作，用的是CA机构的根证书对应的私钥来签名
1
2
3
4
5
6
7
8
9
10
11

自签名签发流程

1: 首先创建私钥
openssl genrsa -out server.key 2048

2：基于私钥创建证书签名请求
openssl req -new -key server.key -out server.csr -subj "/C=CN/ST=beijing/L=beijing/O=ceshi/OU=devops/CN=test.com"

3：使用自己的私钥（.key）签署自己的证书签名请求（.csr），生成自签名证书（.crt）
openssl x509 -req -in server.csr -out server.crt -signkey server.key -days 3650
##走自签名证书或私有CA证书的流程，用的就是自己的私钥。
1
2
3
4
5
6
7
8
9

生成私有CA签发的证书

首先步骤还是和自签证书一样，先生成一个server.crt证书和server.key文件
1:先生成server.crt证书

openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr -subj "/C=CN/ST=beijing/L=beijing/O=ceshi/OU=devops/CN=test.com"
openssl x509 -req -in server.csr -out server.crt -signkey server.key -days 3650

[root@node1 test]# ll
total 28
-rw-r--r-- 1 root root 1212 Jun 13 21:59 server.crt
-rw-r--r-- 1 root root 1001 Jun 13 21:58 server.csr
-rw------- 1 root root 1679 Jun 13 21:58 server.key

2：生成client端证书
openssl genrsa -out client.key 2048
openssl req -new -key client.key -out client.csr -subj "/C=CN/ST=beijing/L=beijing/O=ceshi/OU=devops/CN=test2.com"
接下来是重要的一步，使用
openssl x509 -req -in client.csr -CA server.crt -CAkey server.key -CAcreateserial -out client.crt -days 3650

[root@node1 test]# ll
total 28
-rw-r--r-- 1 root root 1212 Jun 13 22:06 client.crt
-rw-r--r-- 1 root root 1001 Jun 13 22:06 client.csr
-rw------- 1 root root 1675 Jun 13 22:06 client.key
-rw-r--r-- 1 root root 1212 Jun 13 21:59 server.crt
-rw-r--r-- 1 root root 1001 Jun 13 21:58 server.csr
-rw------- 1 root root 1679 Jun 13 21:58 server.key
-rw-r--r-- 1 root root   41 Jun 13 22:06 server.srl

####################
我们可以看到,此处没有了-signkey server.key参数，而是改为了-CA server.crt -CAkey server.key.
关于-CAcreateserial解释如下：
   当签署证书时，CA 需要为每个证书生成一个唯一的序列号，由于每个证书的序列号对于每个颁发者都必须是唯一的，因此颁发者需要跟踪它以前使用过哪些序列号，以确保它不会重复使用任何序列号。OpenSSL 提供了一种使用序列号文件进行跟踪的简单方法。当你指定 -CAcreateserial 时，它会将序列号 01 或一个随机数分配给签名证书，然后创建此序列号文件。在未来的签名操作中，应该使用 -CAserial 和该文件的名称，而不是-CAcreateserial，并且 OpenSSL 将为每个签名的证书增加该文件中的值。这样，你可以用一个颁发者证书签署一堆证书，并且它们的所有序列号都是唯一的。
   
####验证client.crt是否真得是由server签发的

[root@node1 test]# openssl verify -CAfile server.crt client.crt
client.crt: OK
[root@node1 test]# 
[root@node1 test]#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

参考链接：https://blog.csdn.net/bluishglc/article/details/123617558

openssl基础操作

1:查看证书内容
openssl x509 -in server.crt -noout -text

2：查看私钥key内容
openssl x509 -in server.crt -noout -text

3：获取公钥
openssl x509 -pubkey -noout -in server.crt

4:证书格式转换
openssl x509 -in server.crt -outform der -out server.cer
openssl x509 -in server.cer -outform pem -out server.crt
# 如果后缀名不标准的话还需要指定-inform der/pem

5:一条命令生成自签证书
openssl req -newkey rsa:2048 -nodes -keyout rsa_private.key -x509 -days 365 -out cert.crt -subj "/C=CN/ST=beijing/L=beijing/O=ceshi/OU=devops/CN=test.com"
###-nodes 表示私钥不加密，若不带参数将提示输入密码；
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

1. 生成证书的步骤与原理

后面这部分参考：使用OpenSSL生成/签发证书的原理、流程与示例

要理解创建证书的每一步操作必须要先理解创建证书的流程和每一步的含义。生成证书的标准流程是这样的：

• 1、用户生成自己的私钥文件(.key)
• 2、用户基于私钥生成证书请求文件(.csr)
• 3、用户将证书请求文件(.csr)提交给证书颁发机构（CA），CA会对提交的证书请求中的所有信息生成一个摘要，然后使用CA根证书对应的私钥进行加密，这就是所谓的“签名”操作，完成签名后就会得到真正的签发证书(.cer或.crt)
• 4、用户拿到签发后的证书，可能需要导入到自己的密钥库中，如Java的keystore，或根据需要再进行各种格式转换(.pem .p12 .jks等等)

注意：

• 1、第1/2两步可以通过一个命令合并完成。
• 2、第3步向公认可信的CA机构申请证书是线上线下都要进行操作的一系列流程，申请的公司或组织还要提交各种资质和证明，与企业申请某种执照或办理某种手续性质类似，但企业最终拿到的就是一个CA签名的证书文件。所以，对于企业内部应用来说，完全可以自己创建自己的根证书，自己给自己签发证书，然后通过域控手段强制用户浏览器接受来自相应CA签发的证书。
• 3、再次解释一下“签名”的含义，这个概念很关键。在CA签发的证书中，包含申请者的公钥在内，几乎所有的数据都是明文的，也都是申请者自己提供的（当然CA需要审核），签发的证书唯一多出来的信息就是基于申请者提供的所有信息生成了一份摘要，然后用CA自己的私钥对摘要进行了加密，这段加密后的密文被称之为“签名”，这部分数据是返还的签发证书(.cer或.crt)中多出来的关键数据。下图是CA签发证书的原理：

汇总所有的情况来看，生成证书不外乎三种情形：

• 标准CA签发流程
• 生成自签名证书
• 生成私有CA签发的证书

对于绝大多数的开发者而言，需要使用的其实是后两种：自签名证书和私有CA签发的证书。对这两种证书的差异，笔者现在理解的还不够透彻，需要进一步研究。网上的说法是：自签名证书无法被吊销，私有CA签发的证书可以被吊销。从它们各自的命令行工具上看，后者确实有一个撤销操作openssl ca -revoke。此外，生成这两种证书的命令也是不一样的。

针对私有CA签发的证书，网上有如下的建议：

如果你的规划需要创建多个证书，那么使用私有CA的方法比较合适，因为只要给所有的客户端都安装了CA的证书，那么以该证书签名过的证书，客户端都是信任的，也就是安装一次就够了。

如果你直接用自签名证书，你需要给所有的客户端安装该证书才会被信任，如果你需要第二个证书，则还的挨个给所有的客户端安装证书2才会被信任。

2. 标准的CA签发流程

对应文章开头提及的证书生成流程，标准CA签发流程中的第三步是需要CA机构操作的，我们会解释CA机构要做的工作。

2.1 创建私钥（.key)

openssl genrsa -out my.key 2048
1

2.2 基于私钥创建证书签名请求（.csr）

openssl req -new -key my.key -out my.csr -subj "/C=CN/ST=shanghai/L=shanghai/O=example/OU=it/CN=domain1/CN=domain2"
1

这一操作有一个关键点：除了在请求中提交了申请人的一些组织信息之外，最重要的就是把上次生成的私钥作为参数传给命令行，这是因为命令行工具能根据私钥算出对应的公钥，公钥是未来证书的核心组成部分。

2.3 （可选）直接同时生成私钥和证书签名请求

上述两个操作是可以通过一条命令完成的，即同时生成my.key和my.csr两个文件：

openssl req -new -newkey rsa:2048 -nodes -keyout my.key -out my.csr -subj "/C=CN/ST=shanghai/L=shanghai/O=example/OU=it/CN=domain1/CN=domain2"
1

两个关键参数：

• -newkey rsa:2048 -> 生成一个新的证书签名请求，同时生成一个2048位的RSA私钥
• -nodes -> 不对新私钥加密

2.4 将证书申请请求（.csr）提交给CA认证机构申请证书（.crt）

如上所述，此为事务性的审批操作，无本地命令行操作。但是在CA机构那里，执行人员一定会使用CA自己的密钥对CSR进行签名操作，这一步操作与我们将在第4节介绍的使用私有CA证书对应的私钥进行签名性质上是一样的。

简单将：从CSR到CRT，就是一个签名过程，这个过程需要用签发方的私钥。走标准CA签发流程，是CA机构来操作，用的是他的根证书对应的私钥来签名；走自签名证书或私有CA证书的流程，用的就是自己的私钥。

2.5 CA机构生成CA证书链

绝大多书情况下，CA机构返还不是一个单一的证书，而一个证书链。关于证书链，我们会单独起一篇文章进行解释。这里先简单介绍一下：通常机构颁发的证书中会包含完整的证书链，可以直接使用。如果没有包含完整的证书链，浏览器通常会自动下载并补全上级证书，安装完成后不再显示安全警告。在颁发的证书中都会有它的上级和下级证书的相关信息，也包括下载地址，所以浏览器是可以自动下载补全的。但很多企业内网往往不允许连接到互联网，无法补全证书链。所以最好的办法是先补全证书链，再部署到网站上。

一张标准的证书，都会包含自己的颁发者名称，以及颁发者机构访问信息： Authority Info Access，其中就会有颁发者CA证书的下载地址。

通过这个URL，我们可以获得这个证书的颁发者证书，即中间证书。Windows、IOS、MAC都支持这种证书获取方式。

3. 生成自签名证书

3.1 创建私钥（.key）

openssl genrsa -out my.key 2048
1

3.2 基于私钥（.key）创建证书签名请求（.csr）

openssl req -new -key my.key -out my.csr -subj "/C=CN/ST=shanghai/L=shanghai/O=example/OU=it/CN=domain1/CN=domain2"
1

3.3 （可选）直接同时生成私钥（.key）和证书签名请求（.csr）

openssl req -new -newkey rsa:2048 -nodes -keyout my.key -out my.csr -subj "/C=CN/ST=shanghai/L=shanghai/O=example/OU=it/CN=domain1/CN=domain2"
1

3.4 使用自己的私钥（.key）签署自己的证书签名请求（.csr），生成自签名证书（.crt）

openssl x509 -req -in my.csr -out my.crt -signkey my.key -days 3650
1

对于这条命令，要注意以下几点：

• 这个命令是openssl x509，-req是参数，和前面生成证书签名请求的openssl req命令不同。
• -signkey my.key配置清晰地表明使用自己的私钥进行签名。

3.5 （可选）直接同时生成私钥（.key）和自签名证书（.crt）

上述三步操作也可以通过一个命令一次完成：

openssl req -x509 -newkey rsa:2048 -nodes -keyout my.key -out my.crt -days 3650  -subj "/C=CN/ST=shanghai/L=shanghai/O=example/OU=it/CN=domain1/CN=domain2"
1

这个命令要和3.3仔细区分开，3.3的命令是openssl req -new -newkey …，这里的openssl req -x509 -newkey …，关键的区别就是把-new改成了-x509，-x509参数指明要输出的是一个证书，所以我们out文件是.crt后缀，而如果没有-x509，生成是证书签名请求，out文件就得是.csr后缀

4. 生成私有CA签发的证书

上面讲的生成自签名证书场景下只有一个参与方，请求证书和签发证书都是自己，而生成私有CA证书的场景里开始涉及两个角色了:

• 签发证书的一方：CA（主要牵涉的是CA私钥和根证书）
• 请求签发证书的一方：如服务器

为了变于区别，我们把它相关的文件分别用ca和server加以区别

4.1 生成CA私钥（ca.key）和CA自签名证书（ca.crt）

为了简化操作，我们会仿照3.5的操作，一步生成CA私钥和CA自签名证书。

openssl req -x509 -newkey rsa:2048 -nodes -keyout ca.key -out ca.crt -days 3650  -subj "/C=CN/ST=shanghai/L=shanghai/O=example/OU=it/CN=domain1/CN=domain2"
1

可以看到私有CA证书其实就是一个普通的自签名证书，至此环节时，还没有任何特殊之处。

4.2 生成Server端私钥（server.key）和证书签名请求（server.csr）

也是为了简化操作，我们仿照3.3节，一步生成成Server端私钥（server.key）和证书签名请求（server.csr）

openssl req -new -newkey rsa:2048 -nodes -keyout server.key -out server.csr -subj "/C=CN/ST=shanghai/L=shanghai/O=example/OU=it/CN=domain1/CN=domain2"
1

4.3 使用CA证书（ca.crt）与密钥（ca.key）签署服务器的证书签名请求（server.csr），生成私有CA签名的服务器证书（server.crt）

接下来是关键的一步了！

openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 3650
1

对比3.4节生成自签名证书的命令行，我们可以看到，这里没有了-signkey my.key参数，而是改为了 -CA ca.crt -CAkey ca.key，目前让我困惑的是为什么还需要使用ca.crt文件呢？是要生成证书链吗？需验证

• 关于-CAcreateserial
  当签署证书时，CA 需要为每个证书生成一个唯一的序列号，由于每个证书的序列号对于每个颁发者都必须是唯一的，因此颁发者需要跟踪它以前使用过哪些序列号，以确保它不会重复使用任何序列号。OpenSSL 提供了一种使用序列号文件进行跟踪的简单方法。当你指定 -CAcreateserial 时，它会将序列号 01 或一个随机数分配给签名证书，然后创建此序列号文件。在未来的签名操作中，应该使用 -CAserial 和该文件的名称，而不是-CAcreateserial，并且 OpenSSL 将为每个签名的证书增加该文件中的值。这样，你可以用一个颁发者证书签署一堆证书，并且它们的所有序列号都是唯一的。

最后，我们还可以使用如下命令来验证server.crt是否真得是由CA签发的：

openssl verify -CAfile ca.crt server.crt
1

如果显示OK，就是验证成功了。

5. 附录一：openssl req命令参数说明

由于创建证书的关键命令是openssl req命令，此处特别罗列一个这个命令的关键参数。

-days <n>
指定证书有效期，默认是30天，与 -x509 选项一起使用

-newkey rsa:2048
生成一个新的证书申请，同时生成一个 2048 位的 RSA 私钥

-keyout <keyfile>
新私钥要写入的文件

-nodes
不对新私钥加密

-key <keyfile>
读取指定的私钥文件.

-text
同时打印纯文本版本和编码版本信息

-noout
不打印编码后版本 (BASE64编码)

-new
生成一个新的证书申请，会提示用户输入相关字段的值，如果没有 -key 选项，会使用指定配置文件中的信息生成一个新的 RSA 私钥.

-x509
输出自签名的证书，而不是请求一个证书. 通常用于生成测试证书或自签名的根证书.

-subj <arg>
申请人信息，格式是 /C=CN/O=Corp/.../CN=www.ez.com，可以使用 \ 转义，不会跳过空格.

-[digets] 指定签署请求时使用的信息摘要算法，如 -md5，-sha1，-sha256
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

6. 附录二：openssl req的-subj参数说明

/C= Country 国家
/ST= State or Province 省
/L= Location or City 城市
/O= Organization 组织或企业
/OU= Organization Unit 部门
/CN= Common Name 域名或IP
1
2
3
4
5
6

相关实操博文案例

B站视频教程

使用OpenSSL生成/签发证书步骤

openssl以及证书详解

opensll证书解析验证（1

opensll证书及CRL生成
【网络】HTTPS讲解（侧重于加密、秘钥、证书的讲解）-- 此博主所有网络博文值得一看