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生成）
非对称加密虽然解决了对称加密的问题，但仍然存在着安全隐患。假如此时有一个中间人，他也生成了自己的公钥和私钥，并且先一步与A和B分别建立了联系，获取了B的公钥，又把自己的公钥给了A，而A以为这个公钥是B的，那么
明文 --（A）中间人的公钥加密 --> 密文 --（中间人）中间人的私钥解密--> 明文
明文 --（中间人）B的公钥加密 --> 密文 --（B）B的私钥解密--> 明文
此时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通信了
参考链接：https://zhuanlan.zhihu.com/p/456089100
三、生成证书流程原理
1: 生成自己的私钥文件(.key)
2: 基于私钥生成证书请求文件(.csr)
3: 将证书请求文件(.csr)提交给证书颁发机构（CA），CA会对提交的证书请求中的所有信息生成一个摘要，然后使用CA根证书对应的私钥进行加密，这就是所谓的“签名”操作，完成签名后就会得到真正的签发证书(.cer或.crt)
4: 用户拿到签发后的证书，可能需要导入到自己的密钥库中，或根据需要再进行各种格式转换(.pem .p12 .jks等等)
权威机构 (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: 首先创建私钥
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证书的流程，用的就是自己的私钥。
- 生成私有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]#
参考链接：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 表示私钥不加密，若不带参数将提示输入密码；