目录

网络传输 CIAA 安全模型

网络传输 CIAA 安全模型，是构建安全的网络通信的基本模型。包括：

1. 机密性（Confidentiality）：指在数据传输过程中，只有授权的用户可以查看数据，而未经授权的用户无法查看数据。机密性通常通过使用加密技术来实现。
2. 完整性（Integrity）：指在数据传输过程中，数据没有被篡改。完整性通常使用 HASH 技术进行验证，发送方在传输数据时会生成一个 HASH Value 并将其附加到 Header 校验字段上，接收方在接收数据时会对数据进行完整性校验，以确保数据未被篡改。
3. 认证性（Authentication）：指确认对方身份的过程，确保数据传输的安全性。常用的认证方式包括用户名和密码、数字证书等。
4. 可用性（Availability）：指系统或服务应始终处于可用状态，并能够满足用户的需求。为确保可用性，通常使用负载均衡、冗余备份等技术来实现。

其中，Authentication 和 Availability 用于保障互联网资源的访问安全，Confidentiality 和 Integrity 用于保障业务数据传输的安全。

机密性（Confidentiality）

机密性（Confidentiality）通常使用加密技术来实现。在 SSL/TLS 网络传输层中使用到的加密技术主要有对称加密、非对称加密和混合加密这 3 大类型。

对称加密

加密的过程就是把 “明文” 变成 “密文” 的过程。反之，解密的过程，就是把 “密文” 变为“明文”。在这两个过程中，都需要一个关键的 “密钥” 来参与数学运算。

对称加密，就是通信双方使用相同的 “密钥“ 进行加解密，该密钥被称为 “对称密钥”，常见的对称加密算法有 AES、DES 算法等。对称加密的特点是速度快，但缺点是对称密钥泄漏的风险大。一旦对称密钥泄漏，那么加密过程就会被破解。

例如：使用 7zip 创建一个带密码的加密压缩包。当别人要解压时，就需要输入相同的密码。在这个例子中，密码就是一个对称密钥，它是容易泄露的。

非对称加密

基于对称密钥容易泄漏的特性，非常不适用于需要进行频繁交互的公共网络环境，被中间人窃取的机会将大大的增加。为了解决这一问题，就提出了非对称加密技术，常见的非对称加密算法有 RSA 算法。

所谓 “非对称密钥“ 指的是通信双方使用不同的密钥进行加密和解密，分别称为 Private Key（私钥）和 Public Key（公钥）。在 C/S 场景中，Private 和 Public Key 都是由 Server 创建的，并且：

• Private Key：只存在于 Server 中。
• Public Key：会发送给需要建立安全通性的 Client。

由于 Private Key 和 Public Key 之间能够进行互补运算，所以通过 PublicKey 加密的数据，只能由对应的 Private Key 进行解密，反之亦然。并且由于只有 Public Key 会在公网中传递，这样即便中间人窃取到了 Public Key 也没用，因为只有对应的 Private Key 能够进行解密。通过这样的方式就解决了对称密钥泄漏风险的问题。

混合加密

对称加密性能好（每个操作纳秒级），但有安全漏洞。非对称加密提升了安全性，但却降低了性能（每个操作需要微秒到毫秒级）。为了将两者的优势结合就提出了混合加密方案。

值得注意的是。混合加密是一种方案，而不是一种具体的技术，实际上它结合使用了 2 种加密技术。在一个混合加密的安全会话中：

• 首先，应用非对称加密技术解决了对称密钥（也称为会话密钥）的安全交换问题。
• 然后，应用对称加密技术和会话密钥来对实际的交互数据进行加解密。

目前。混合加密方案已经被广泛到网络系统中，例如：SSL/TLS、IPSec、Signal、WireGuard 等传输协议。

完整性（Integrity）

IP Internet 环境是一个 “尽力而为” 的网络，除了需要应用上述提到的加密算法来保障数据机密性之外，还需要在报文传输层面保障数据的完整性（Integrity）。

L2 数据链路层的 CRC 强校验

数据在物理介质中进行传输是非常容易出错的，因为数字信号会受到各种环境干扰。所以在 Ethernet 中，封装 L2 Frame 时会附加上一个 FCS 尾部（4Bytes）。Receiver 接收到 Frame 之后，通过 CRC32 强校验算法对 Frame 的 Header 和 Data 部分都进行完整性校验，一旦发现数据不完整就触发错误。但 Frame CRC 强校验的作用域仅仅在同一个 Ethernet LAN 中，对于跨网络报文传输还需要依靠其他手段。

L3 网络层的 Checksum 弱校验

在 Receiver 将 L2 Frame 提交到 L3 sub-system 的过程中，由于存在数据复制操作，也可能会引入错误，所以 L3 会对 IP Header 进行 Checksum 弱校验。区别在于 IP Checksum 只会对 IP Header 进行校验，以此确保 IP Header 的完整性，所以称为弱校验。之所以有这样的设计，主要是兼顾了安全和性能这两方面的考量。强校验算法和数据量也意味着网络性能的降低。

L4 传输层的 Checksum 弱校验

L4 Checksum 弱校验是一个可选项目，根据传输场景和协议类型的不同，可能会忽略掉该字段。

安全层的 Checksum 强校验

上述可见，仅依靠 L2-4 的数据校验手段，并不能全面确保数据的完整性。所以，从网络分层理念出发，在传输层之上还增加了可以根据用户需求而 “插入" 的安全传输层。它以 “安全第一" 为原则，其次才是性能考量。

以 SSL/TLS 为例，为了支持多种不同的强校验算法，它的 Checksum 字段长度可以是 16Bytes（MD5）、20Bytes（SHA1），甚至是 64Bytes（SHA512）。关于 SSL/TLS 协议细节我们在后面再展开。

认证性（Authentication）

上面我们讨论了报文传输层面的数据完整性，以及通过非对称密钥进行数据加密，此外还需要继续讨论非对称密钥本身的安全性，最常见的就是 “中间人公钥劫持" 问题。

如下图所示。在 C/S 场景中，假设 Server 和 Client 希望建立非对称加密安全通道。但一开始 Server 传递给 Client 的 Public Key 就已经被中间人劫持了，并伪造了一对非法的非对称密钥，且将非法的 Public Kay 发送给 Client。那么 Client 实际上是和中间人建立起了 “安全” 通道，而不是 Server。

后续，当 Server 向 Client 发送数据时，中间人故技重施的将数据劫持，用一开始劫持的 Public Key 进行解密后，对数据进行篡改，然后再使用非法的 Private Key 对数据进行加密发送给 Client，而 Client 也会使用非法的 Public Key 进行解密。反过来亦是如此。对 Client 和 Server 而言，中间人都是透明的，信息泄露了却不自知。

可见，在网络系统中，还需要解决 Public Key 的安全分发问题，这就是 PKI（Public Key Infrastructure，公钥基础设施）存在的意义。

PKI 公钥基础设施

PKI（Public Key Infrastructure，公钥基础设施）是一种应用于非对称加密的 Public Key 管理标准，用于防范 Public Key 分发过程中的中间人攻击，以此来支撑数据传输的机密性和完整性。

PKI 是一种标准，其关键的实体主要有 2 个：

1. CA（Certificate Authority，证书签发机构）：提供数字签名证书的签发、证书持有者身份认证等一系列信息安全服务。在公网环境中，CA 需要是一个具有权威和公信力的第三方机构；而在内网环境中，则可以创建自己的 CA，用于签发只在内网有效的证书。
2. 数字签名证书：是一个由 CA 签发的 “特殊公钥“，通过这个公钥，Client 可以识别发送者是否为中间人。

数字签名证书

首先来看数字签名证书，它遵循着 X.509 标准。其中目前常用的 X.509 v3 格式定义如下图所示：

1. Version（版本号）：v3 版本的值为 2。
2. Serial Number（证书序列号）：指定由 CA 分配给证书的唯一标识。
3. Signature Algorithm（签名算法标识符）：指定 CA 对证书执行数据签名时所使用的签名算法。
4. Issuer（证书签发者）：指定 CA 自己的 X.500 DN-Distinguished Name，用于确定 CA 的权威性。包括：
   • C：国家
   • ST：省市
   • L：地区
   • O：组织机构
   • OU：单位部门
   • CN：通用名
   • 邮箱地址
5. Validity（有效期）：包括证书开始生效的日期和证书失效的日期。
6. Subject（证书持有者）：指定证书持有者的 X.500 DN-Distinguished Name，用于确定证书持有者的身份合法性。包括：
   • C：国家
   • ST：省市
   • L：地区
   • O：组织机构
   • OU：单位部门
   • CN：通用名
   • 邮箱地址
7. Subject PublicKey Info（证书持有者的 Public Key 信息）：包含 2 个重要信息:
   • 证书持有者的 Public Key，用于后续建立非对称加密安全通道。
   • Public Key 的签名算法标识符。
8. Extension（扩展项）：v3 开始支持的证书扩展信息，用于扩展证书的作用。
9. Issuer’s Signature（数字签名值）：是一个非常重要的字段。先通过对上述 Data（1～8 个字段）进行 HASH 得到数字摘要，然后再使用 CA 私钥进行加密得到数字签名。

值得注意的是，证书只有 Signature 是加密的，而 Data 是明文传输的，尽可能的减少了非必要加密数据的运算量。Signature 就可以确保证书本身的数据机密性和完整性。

CA 机构

CA 通常是可信任的第三方机构，能够对数据签名证书的真实性和有效性进行认证，全球性的 CA 机构有：Symantec、Comodo，GlobalSign，DigiCert，GeoTrust 等等。这些 CA 机构之间存在上下级的关系，多层级 CA 之间存在 “证书信任链”，目的是为了加强数字签名证书的可信度和安全性。

在实际的应用中，我们可以将证书分为以下几种类型，在后续的流程介绍中，需要区分理解：

• CA 私钥：作为 CA 自身的私钥，用于加密 CA 证书。
• CA 公钥证书：作为 CA 自身的公钥，由上级 CA 签发。CA 公钥会发送给信任该 CA 的通信双方保存。
• CA 根证书：如果 CA 自身就是最顶级机构，那么 CA 就需要自己给自己签发一个 CA 公钥证书，称为根证书，其签发者和持有者都是自己。所以顶级 CA 的公信力要求最高。
• CA 证书：又称为 Server 本地设备证书，是由 CA 签发给申请者（通常是 Server）的证书，证书中的签发者名称是 CA 的名称，而持有者就是申请者的名称。

CA 证书的签发和认证

以 HTTPS 网站向 CA 申请签发 CA 证书为例：

1. 网站在本地创建自己的 Private Key 和 Public Key；
2. 网站向 CA 提交自己的公司信息、网站域名信息、Public Key 信息等并申请签发。
3. CA 通过线上、线下等多种手段验证网站提供的信息的真实性，例如：公司是否存在、域名是否合法等等。
4. 审核通过后，CA 会向网站签发一张与域名对应的 CA 证书。

所谓 “签发”，实际上就是对 CA 证书的内容进行 “摘要和加密”，最终生成 Issuer’s Signature（数字签名值）：

• CA 证书数字摘要：首先，对 CA 证书除了 Issuer’s Signature 字段之外的 Data 字段的内容先进行 HASH（e.g. SHA1、MD5）得到数字摘要，用于保证 CA 证书的完整性。
• CA 摘要加密：然后，使用 CA 私钥对数字摘要进行加密后得到 Signature。由于 Signature 使用了 CA 私钥进行加密，所以也只有 CA 公钥证书能对其进行解密，以此来保证 CA 证书的机密性。

可见，Issuer’s Signature 是 Client 用于保证 CA 证书合法性的关键，继而基于对 CA 的信任，也保证了 CA 证书内含的 Server Public Key 的合法性。

CA 签发了证书之后，HTTPS 网站实际的 HTTP Server 就可以加载相应的 CA 公钥证书和 CA 证书并启动 TLS 协议了。后续，当 Client 向 Server 发起 HTTPS 请求时，Server 就会把 CA 证书返回。Client 拿着 CA 证书发起 CA 认证流程：

1. Client 首先会从 CA 证书的签发机构下载一张 CA 公钥证书；
2. 然后用 CA 公钥证书对从 Server 接收到的 CA 证书的 Signature 进行解密，得到一份数字摘要。
3. 同时用 CA 证书指定的 HASH 函数对 CA 证书的 Data 部分进行计算，得到另一份数字摘要。
4. 如果 2 份 “数字摘要“ 相同，则表示 Client 收到的 CA 证书一定是 Server 下发的。

因为 HASH 的唯一性特征，即便中间人拥有了 CA 公钥证书，能够解析并篡改 CA 证书的 Data 和数字摘要，但是中间人却没有 CA 私钥来重新加密得到 Signature。如果中间人强行篡改 Data，那么在 Client 处也无法通过 Signature 得到一致的数字摘要。

那第三方攻击者能否让自己的证书显示出来的信息也是服务端呢？（伪装服务端一样的配置）显然这个是不行的，因为当第三方攻击者去 CA 那边寻求认证的时候 CA 会要求其提供例如域名的 whois 信息、域名管理邮箱等证明你是服务端域名的拥有者，而第三方攻击者是无法提供这些信息所以他就是无法骗 CA 他拥有属于服务端的域名。

使用 OpenSSL 自建 CA 并签发证书

OpenSSL 是一个强大的安全套接字层密码库，利用 OpenSSL 我们可以自建企业内部网络环境中使用的 CA 中心，并生成 CA 证书、证书签名请求（CSR）和 CRLs（证书回收列表），还能够通过 CA 证书签发本地设备证书。

数字证书文件的常见格式有：

• DER：二进制格式证书，包含公钥，不包含私钥，常用后缀为 .der、.cer、.crt。
• PEM：ASCII 格式证书，包含公钥，不包含私钥，以 —–BEGIN CERTIFICATE—–、以 —–END CERTIFICATE—– 结尾。常用后缀为 .pem、.cer、.crt。
• PKCS#12：二进制格式证书，包含公钥，可以包含私钥，也可以不包含私钥，常用的后缀为 .P12 和 .PFX。

具体流程如下：

1. 自建 CA 中心，并生成 CA 中心的私钥和公钥，公钥就是 CA 证书。如果 CA 中心没有上级 CA 机构，那么这个 CA 证书就是根证书。
2. Server 生成自己的私钥和公钥，然后拿着公钥到 CA 中心申请签发本地设备证书。
3. CA 中心审查通过后，将申请者的公钥、申请者的明文信息、以及通过申请者明文信息 HASH 出来的数字签名写入到本地设备证书中。然后返回给申请者。
4. S 启动 SSL 进程时，需要加载两个文件：本地私钥，以及本地设备证书。
5. 客户端（C）请求 SSL 访问 S 时，S 首先将本地设备证书发送到 C。C 收到本地设备证书之后需要根据从 CA 机构得到的 CA 证书进行解密。C 获得 CA 证书的方式通常有两种，手动下载或浏览器下载。C 本地会存在一个证书库。
6. C 对 S 的本地设备证书进行验证主要完成两件事情：1）使用 CA 证书解密 S 证书，因为 S 证书是使用 CA 私钥进行加密的，所以可以使用 CA 证书进行解密。解密成功后 C 得到了 S 的公钥以及数字签名 A；2）C 使用 S 证书标注的 HASH 算法对 S 证书的明文消息进行解密得到数字签名 B。
7. C 通过数字签名 A、B 的比对可以确定 S 证书的真实性，通过 CA 证书解密可以确定 S 身份的可靠性。从而判定 S 是可以建立安全连接的。
8. C 再拿着 S 公钥开始非对称加密通信流程。

• 生成 RSA 私钥：

openssl genrsa [args] [numbits]

	-des: CBC 模式的 DES 加密
	-des3: CBC 模式的 3DES 加密
	-aes128: CBC 模式的 AES128 加密
	-aes192: CBC 模式的 AES192 加密
	-aes256: CBC 模式的 AES256 加密
	-passout arg    arg 为对称加密（des、3des、aes）的密码，使用该参数可以省去指令行交互提示输入密码环节
	-out file       输出证书私钥文件
	[numbits]       密钥长度

# 生成一个 1024 位的 RSA 私钥，并用 3DES 加密 (密码为 1111），保存为 server.key 文件。
$ openssl genrsa -out server.key -passout pass:1111 -des3 1024 

• 生成证书签名请求（CSR）：

openssl req [options] <infile> outfile

	-inform arg      输入文件格式 DER、PEM
	-outform arg     输出文件格式 DER、PEM
	-in arg          待处理文件
	-out arg         待输出文件
	-passin          用于签名待生成的请求证书的私钥文件的解密密码
	-key file        用于签名待生成的请求证书的私钥文件
	-keyform arg     DER、NET、PEM
	-new             新的请求
	-x509            输出一个 X509 格式的证书 
	-days            X509 证书的有效时间  
	-newkey rsa:bits 生成一个 bits 长度的 RSA 私钥文件，用于签发  
	-[digest]        HASH 算法 md5、sha1、md2、mdc2、md4
	-config file     指定 openssl 配置文件
	-text            text 显示格式

# 利用 CA 的 RSA 密钥创建一个自签署的 CA 证书（X.509 结构）。
$ openssl req -new -x509 -days 3650 -key server.key -out ca.crt 

# 用 server.key 生成证书签署请求 CSR（这个 CSR 用于之外发送待 CA 中心等待签发）。
$ openssl req -new -key server.key -out server.csr

# 查看 CSR 的细节。
$ openssl req -noout -text -in server.csr

• x509 证书操作：

openssl x509 [args]    

	-inform arg       待处理 X509 证书文件格式 DER、NET、PEM
	-outform arg      待输出 X509 证书文件格式 DER、NET、PEM
	-in arg           待处理 X509 证书文件
	-out arg          待输出 X509 证书文件
	-req              表明输入文件是一个 “请求签发证书文件（CSR）”，等待进行签发 
	-days arg         表明将要签发的证书的有效时间 
	-CA arg           指定用于签发请求证书的根 CA 证书 
	-CAform arg       根 CA 证书格式（默认是 PEM）
	-CAkey arg        指定用于签发请求证书的 CA 私钥证书文件，缺省认为私有密钥在 CA 证书文件里有
	-CAkeyform arg    指定根 CA 私钥证书文件格式（默认为 PEM 格式）
	-CAserial arg     指定序列号文件（serial number file）
	-CAcreateserial   如果序列号文件（serial number file）没有指定，则自动创建它

# 转换 DER 证书为 PEM 格式
$ openssl x509 -in cert.cer -inform DER -outform PEM -out cert.pem

# 使用根 CA 证书对 "请求签发证书" 进行签发，生成 x509 格式证书
$ openssl x509 -req -days 3650 -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt

# 打印出证书的内容
$ openssl x509 -in server.crt -noout -text

• CA 签名：

openssl ca [options]:

	-selfsign       使用对证书请求进行签名的密钥对来签发证书。即 “自签名”，这种情况发生在生成证书的 CA 客户端与签发证书的 CA 服务器都是同一台机器，此时我们可以使用同一个密钥对来进行 “自签名”
	-in file        需要进行处理的 PEM 格式的证书
	-out file       处理结束后输出的证书文件
	-cert file      用于签发的根 CA 证书
	-days arg       指定签发的证书的有效时间
	-keyfile arg    CA 的私钥证书文件
	-keyform arg    CA 的根私钥证书文件格式: PEM、ENGINE 
	-key arg        CA 的根私钥证书文件的解密密码（如果加密了的话）
	-config file    配置文件

# 利用 CA 证书 ca.crt 签署请求证书 server.crt。
$ openssl ca -in server.csr -out server.crt -cert ca.crt -keyfile ca.key

Step 1. 搭建 CA 中心

所谓 CA 中心，在 Linux 中表现为一个固定的目录结构：

/*
CA 中心目录结构
-- CA/
    |-- index.txt
    |-- newcerts/
    |-- private/
    |-- serial
*/

CERT_DIR=/root/CA
mkdir -p $CERT_DIR
cd $CERT_DIR
mkdir newcerts private
chmod 700 private

# prepare files
touch index.txt
echo 01 > serial

• newcerts Dir：存放 CA 签署（颁发）过的数字证书。
• private Dir：存放 CA 的私钥。
• serial File：存放证书序列号，可自定义第一张证书的序号（e.g. 01），之后每新建一张证书，序列号会自动加 1。
• index.txt File：存放证书信息。

Step 2. 生成 CA 的 RSA 私钥

$ openssl genrsa -passout pass:foobar -des3 -out $CERT_DIR/private/cakey.pem 2048
Generating RSA private key, 2048 bit long modulus
....................+++
..................................................+++
e is 65537 (0x10001)

$ ll $CERT_DIR/private/cakey.pem
-rw-r--r--. 1 root root 1751 Nov  9 07:18 /root/demoCA/private/cakey.pem

$ cat $CERT_DIR/private/cakey.pem
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,B017FD40FE243E30

QKV/gR2rC/E5gogSoDuascRfQKoVUfBekIiTtROUPKmW6R74EYh4SoxRhW1WKNQa
xtD4583SC99aCjrKCETUPrQAijX9wxuL3bSevWzH6Uxba1XX9YEUOMA8vRThR1e4
rK+HKXT/S7w39ku8+YfwjmO64DCkGVl1T35GHe+De2oXxE6gaUbpgz/KZiOuo0yV
1SRHCK03PQ6nYEqMyk67UGT0gQ1NLwEEB4eTZxHkyheTAXrCazAYrSGqTXsx5rCJ
mOU2G63/w/ktbW+YGphk7P4myhvkgNflm/Lh9JOGxrAgjAk6Ay6T7wMT17zKqKYk
j9AqLh36Ph6876PYnxnf2UFMye8yl+boxUlfnc+GA1C2SEXHcucDHcic+ae5tGwy
mltY7EeC0+MB/U1UvdeBZOK1wAoKW5nS7WW5C2Mg9ZJZ1H7FXUk8h9oLwS1sgcVN
hOwsHRJtR8k1+iutcOTnDcN07IWDaCzFQi4Z9K+w1uCIH1Zky2DYixr2HNpmbEFD
CcBDMpmqZD92ReVVW5Taa1i4TB6YgCVKCMysNmTGE9QqiMcCdZQ1jBhN3+Z0SAaR
sHCWK0gOVF6lIdYEk8y6bW1VPgINNzsKL0aX/gt44JBS9Z7xKwJlS1yCNnHVVtZQ
wRd+gwMEPxXq+U8OQsvyBFHCXZWEbLSWAYMsNGU3iH84gNEhEH54PmEtBKRSt6KJ
83BUu+P9wcXBvnc6GncDPXa7+O6xmdKHzdYKrJPLlkW8XL0zOqgnpe6/vx+WZiDN
N4f0ej83VhuwrIfhfC6vU7kTPPcM9fmS0B4NCa6MR6W/Q2Y6NIV+jI3IX6YvyLUA
aPxX2sAirahGpFgMGzAPCNw3Bsqsf7lOsw8baH3jkeCj61PCEQhBwHJRzjl2yuVu
0w3c5kKDepiqlq2hnQtx3XGScDwhrAVitGtTRBhxfZoiy1vLLvB/fye/DLbqP/z3
MnNRSM9rIxYap6Usy0rpBQGyeNAYlpWKhhl3qWQLV84OVkV8cfkp0vEhgstXyIKv
A/klaloD5gCt5WBt/iBjuFxf1W/DfzVD9FAgRG+9qL3ZZBLqs7Q6OPXSISlnaK6r
/uGTHgenPHkdVDN+eWhpMKYAPvwKiBBTq8WIz4zkBJQGxs9JVgEzKmvQXAbcafFj
HWvuykPo3WZ59ACLl59vDoPMNl+Mi11mH0Ye3jsxckWIMCzE3N+INwqdBmF90vbU
jelvO+QFyY4bpx3+T3kJydDIAJSjwRMA+4mPdYlH9hyE9rOLt4ObWY1//5fHEVuw
3SSW3Cf1FTSTsRvyuTm0ORPNogzPsIfnnUFnSoukXYBvFmbXXeWxKbbomzcubjCx
FP5O6/6LVw4V0YOl4E9CAJZ8pcHDRz6uauXM4Ig8MTpHdNyd07o0hC56bD07mTnt
0ifBucs9grQ0mxdCbIl3BNgg2J7mRYpXAtIhXDR9VyGxvoa5cgeKUsdECyAavfJp
xJgvC/0NFWNampB5fhMp9mnLRy7LzqnmHdUJpXntKzfH16Vu6MB3jE8YVORc313v
wFv5k7AiQVAplWBLEU4/opFkB97FuvRlmms5lK2umePezGjPunpobq4Qe5Gwocw2
-----END RSA PRIVATE KEY-----

Step 3. 生成 CA 的公钥（CA 证书）

NOTE：因为该 CA 中心是我们自建的，所以没有上级的 CA 机构，那么这个 CA 证书就是根证书。

需要注意的是，签发证书的时候可以指定 Domain Name，那么该证书就仅对该 Domain Name 有效。

# 下述指令完成了 CA 证书签名请求 & 对证书进行自签名两件事情。
# -key 指定了新建证书使用的密钥文件。
# -x509 生成 x509 标准的证书。
$ openssl req -x509 -passin pass:foobar -new -nodes -key $CERT_DIR/private/cakey.pem -days 365 -subj "/C=US/ST=Denial/L=Springfield/O=Dis/CN=web.apigw.com" -out $CERT_DIR/ca_01.pem

$ cat $CERT_DIR/ca_01.pem
-----BEGIN CERTIFICATE-----
MIIDizCCAnOgAwIBAgIJALnLH5qhisxdMA0GCSqGSIb3DQEBCwUAMFwxCzAJBgNV
BAYTAlVTMQ8wDQYDVQQIDAZEZW5pYWwxFDASBgNVBAcMC1NwcmluZ2ZpZWxkMQww
CgYDVQQKDANEaXMxGDAWBgNVBAMMD3d3dy5leGFtcGxlLmNvbTAeFw0xODExMDkw
NzI3NTFaFw0xOTExMDkwNzI3NTFaMFwxCzAJBgNVBAYTAlVTMQ8wDQYDVQQIDAZE
ZW5pYWwxFDASBgNVBAcMC1NwcmluZ2ZpZWxkMQwwCgYDVQQKDANEaXMxGDAWBgNV
BAMMD3d3dy5leGFtcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAMw1gfu9C4Unw/wekXS2qp4SjI/zU4N3E8/grq+fF31t1Ce0PCdyKkVoEMZr
Z1N3FY+3LfMzq6HnogKipJIAoeYeNyPKtFpA5glCoGxb+m0VkxM6laHmOuf7XjKr
0Dr7Yy8vGGigjxB32aFNo26JQbVFlF4y+cg2CJm4qrVzVtohZ27xUbitzntOBpeS
+Djp3Ti9iLYEWQsbpskKyEmNhD9EqXIuv0xIIUv1P++fXJCfq/P7ySC84+jmecV1
GkVh7UfsViJSlEBMi6t6q21o7eYJ40/v8w6MNG5rlCGhctfFztFh8LsTHRy/tKpk
4v2oPJsXnN+dm06EX7Hf2SIZ4UUCAwEAAaNQME4wHQYDVR0OBBYEFHPUtuHJXbnO
cJEFB6PEnC397rijMB8GA1UdIwQYMBaAFHPUtuHJXbnOcJEFB6PEnC397rijMAwG
A1UdEwQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEBAErS0J6mfiEl1yBLjZgOUhUt
kNC8RWiQchBBskA8XbvUMrlquqaVY0oejAzzfgPYS1f16CNJrqdWIkn87lypc3UG
eKEUdfH6ebZ8ibzsOPoLnzIMR4aeMDyFrl4PWmKgtlFkxKvt8b54/6nBbpNMeahL
zbgp++rfTeUJqVRpiVak0ht0LKdsrCQ0PZwdbMZkgnHVzKc+w6auMhm8KbubFa3N
wGcgbhQrmvuCMjCEcwRlSToXSB7nfZLp+55x8BFIORgJfk5iy5qQavsnH0z0rGub
TKeG4H3pjtLy0OzzCadgrXMLGtvhIVfPPSLz4L7iZ13qc92QetxH6p/3fXLoJYc=
-----END CERTIFICATE-----

可以看见新建的 CA 证书内含了与密钥文件对应的公钥信息。

$ openssl x509 -in ca_01.pem -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            b9:cb:1f:9a:a1:8a:cc:5d
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=Denial, L=Springfield, O=Dis, CN=www.example.com
        Validity
            Not Before: Nov  9 07:27:51 2018 GMT
            Not After : Nov  9 07:27:51 2019 GMT
        Subject: C=US, ST=Denial, L=Springfield, O=Dis, CN=www.example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:cc:35:81:fb:bd:0b:85:27:c3:fc:1e:91:74:b6:
                    aa:9e:12:8c:8f:f3:53:83:77:13:cf:e0:ae:af:9f:
                    17:7d:6d:d4:27:b4:3c:27:72:2a:45:68:10:c6:6b:
                    67:53:77:15:8f:b7:2d:f3:33:ab:a1:e7:a2:02:a2:
                    a4:92:00:a1:e6:1e:37:23:ca:b4:5a:40:e6:09:42:
                    a0:6c:5b:fa:6d:15:93:13:3a:95:a1:e6:3a:e7:fb:
                    5e:32:ab:d0:3a:fb:63:2f:2f:18:68:a0:8f:10:77:
                    d9:a1:4d:a3:6e:89:41:b5:45:94:5e:32:f9:c8:36:
                    08:99:b8:aa:b5:73:56:da:21:67:6e:f1:51:b8:ad:
                    ce:7b:4e:06:97:92:f8:38:e9:dd:38:bd:88:b6:04:
                    59:0b:1b:a6:c9:0a:c8:49:8d:84:3f:44:a9:72:2e:
                    bf:4c:48:21:4b:f5:3f:ef:9f:5c:90:9f:ab:f3:fb:
                    c9:20:bc:e3:e8:e6:79:c5:75:1a:45:61:ed:47:ec:
                    56:22:52:94:40:4c:8b:ab:7a:ab:6d:68:ed:e6:09:
                    e3:4f:ef:f3:0e:8c:34:6e:6b:94:21:a1:72:d7:c5:
                    ce:d1:61:f0:bb:13:1d:1c:bf:b4:aa:64:e2:fd:a8:
                    3c:9b:17:9c:df:9d:9b:4e:84:5f:b1:df:d9:22:19:
                    e1:45
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                73:D4:B6:E1:C9:5D:B9:CE:70:91:05:07:A3:C4:9C:2D:FD:EE:B8:A3
            X509v3 Authority Key Identifier:
                keyid:73:D4:B6:E1:C9:5D:B9:CE:70:91:05:07:A3:C4:9C:2D:FD:EE:B8:A3

            X509v3 Basic Constraints:
                CA:TRUE
    Signature Algorithm: sha256WithRSAEncryption
         4a:d2:d0:9e:a6:7e:21:25:d7:20:4b:8d:98:0e:52:15:2d:90:
         d0:bc:45:68:90:72:10:41:b2:40:3c:5d:bb:d4:32:b9:6a:ba:
         a6:95:63:4a:1e:8c:0c:f3:7e:03:d8:4b:57:f5:e8:23:49:ae:
         a7:56:22:49:fc:ee:5c:a9:73:75:06:78:a1:14:75:f1:fa:79:
         b6:7c:89:bc:ec:38:fa:0b:9f:32:0c:47:86:9e:30:3c:85:ae:
         5e:0f:5a:62:a0:b6:51:64:c4:ab:ed:f1:be:78:ff:a9:c1:6e:
         93:4c:79:a8:4b:cd:b8:29:fb:ea:df:4d:e5:09:a9:54:69:89:
         56:a4:d2:1b:74:2c:a7:6c:ac:24:34:3d:9c:1d:6c:c6:64:82:
         71:d5:cc:a7:3e:c3:a6:ae:32:19:bc:29:bb:9b:15:ad:cd:c0:
         67:20:6e:14:2b:9a:fb:82:32:30:84:73:04:65:49:3a:17:48:
         1e:e7:7d:92:e9:fb:9e:71:f0:11:48:39:18:09:7e:4e:62:cb:
         9a:90:6a:fb:27:1f:4c:f4:ac:6b:9b:4c:a7:86:e0:7d:e9:8e:
         d2:f2:d0:ec:f3:09:a7:60:ad:73:0b:1a:db:e1:21:57:cf:3d:
         22:f3:e0:be:e2:67:5d:ea:73:dd:90:7a:dc:47:ea:9f:f7:7d:
         72:e8:25:87

Step 4. 生成 Server 的密钥 & 证书签名请求文件

同样使用了 RSA 机制，创建出 Server 的私钥及 Server 证书签名请求文件。

$ mkdir $CERT_DIR/web.apigw.com

$ openssl req -newkey rsa:2048 -nodes -keyout $CERT_DIR/web.apigw.com/server.key -subj "/C=US/ST=Denial/L=Springfield/O=Dis/CN=web.apigw.com" -out $CERT_DIR/web.apigw.com/server.csr
Generating a 2048 bit RSA private key
.........+++
....................................................................................................................................................................................................+++
writing new private key to '/root/CA/web.apigw.com/server.key'
-----

$ cat /root/CA/web.apigw.com/server.key
-----BEGIN PRIVATE KEY-----
MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDVcT7tbL0rgQiP
Rn/24h2Lv8KUm1JPWY4UzKPIIpSGwDTD6b8PgBmCkozAFWU2jDLj7XryHxz/fAVA
HXLKDyv1GyGGF7WFffmAd7xDKEqd13737zT5CsGyhYCqY2+sd/eWZrAad6C7OXO2
1z1eDOWJ9a1cm2/ytW8/HHEHCyG0vmiFYXIV2mEWVw35kzl7Pp19OQL4HkhPuCj0
B0+jUb1s7UVzA626+CkaGFb37KT0PSwifLMJ8KdKnIcTjKSA47Igk0CgfdA6GIt+
rD+P0OtZnTYW91jM8fFTEpREIuvhdaXTJSQrfxj7mE77k8T36AuC2GX7bXHG5QXT
XwSKHv2bAgMBAAECggEALwdMvjN/Wt6LbEY0W8lmiSwvS18Nu74XuC1+yNIVt7sR
5TjTiC7JcCOqL4iHTIWHkQD6Xe7NDN3eqknSyQKexNq9gDYpIMio+M1pBcMS7cRV
jXt/SIA+PX984g4WxQGJ4/GsS6igGaCHBnpWYyqkSMmA8S6uc+PWJym1HcAuJQyI
J7EYe56KGnJYxDwMAl01qT6RqYrJA6D3AKi+UlYURQr/+VyvBU99I2v7M2idzyGP
BZTh5g45We5z6+38z8sTHGgU52+d57iy3edexUD2UZwQl8dXIsjggYpC6VpyJSgl
g0jIIbOVc8YSoC42GiwrKiA61tHQGG/RXNXbU+waAQKBgQDrw68zDPRgVaazcF7v
Wgh6wHVMttmEkWM1L610tnllyyJSqqKfUjBQLZAe9BU7Xf7ZpyfmfsyGPEhxIO//
8Rr8F3FHEbxuNc4b9jgz+cslT8FkPzEVZ9NwOkvTIOyV7kGVT2sAln990218ifvH
a9ZckpnkScKoyLFAsSEShD2OuwKBgQDnwxemfF0t1ir6ZsvmT5FUsDVoGwm3//aW
+4bVMovr7dNefrAMPxwMyA/5Ddf1Ss1RXMTaP6+y2kftM2S/1P+MEE8x3zvT6qUE
nonyHeYVIhGs5j38TSZjaW13LlJbEBiAo89+l3xJwkWn7Rx9Cz+u060vu/Aoi5tF
1NFNVC4OoQKBgFmgUHAl0pj0tqSsaUqwfVy84VrCgDpnUsGbWGNwIwJRkMDAYYYT
po40Y/+AZrnk58cyRnbXaUT2kct/6/zuWYXQG54a3fk/txTmK0OHCHUstqY3Z59t
kvGtF7oxX/83TfNG97SHgfwBbjPT+MU894bFrH8ek0O617dyHtJ9NzGVAoGBAKjN
AovC5sb8xx7MAlSDvXE2Sh/CGakHaB39ou3jO+AhvyKDGUxCJvb0PBYEzDcfPT22
WLYxTpHwxBRyqz3BMENemZ/UXKnzrC8aHZTXy/22a7NHmvwJYR1k61KzzU4AAiin
pvgn82FxevRdEbPNnpuCFxC+TKPrUrNg1vUAi+8hAoGBANHqyKux1GXIhCP6wziS
am34NBqcynDWjivmFiSBJLxf5vFpsyTMhslpkvrtU8sdLY4wM706LhAT07ZDwjz1
kFMkyF87LTpS4XgUA0dqqEMu8CYEBrNhMNphme/r9TNN1xcroHjfwccynp2TOizU
kOs1SaEBhB1Go1OefL7mfhlq
-----END PRIVATE KEY-----

$ cat /root/CA/web.apigw.com/server.csr
-----BEGIN CERTIFICATE REQUEST-----
MIICnzCCAYcCAQAwWjELMAkGA1UEBhMCVVMxDzANBgNVBAgMBkRlbmlhbDEUMBIG
A1UEBwwLU3ByaW5nZmllbGQxDDAKBgNVBAoMA0RpczEWMBQGA1UEAwwNd2ViLmFw
aWd3LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANVxPu1svSuB
CI9Gf/biHYu/wpSbUk9ZjhTMo8gilIbANMPpvw+AGYKSjMAVZTaMMuPtevIfHP98
BUAdcsoPK/UbIYYXtYV9+YB3vEMoSp3XfvfvNPkKwbKFgKpjb6x395ZmsBp3oLs5
c7bXPV4M5Yn1rVybb/K1bz8ccQcLIbS+aIVhchXaYRZXDfmTOXs+nX05AvgeSE+4
KPQHT6NRvWztRXMDrbr4KRoYVvfspPQ9LCJ8swnwp0qchxOMpIDjsiCTQKB90DoY
i36sP4/Q61mdNhb3WMzx8VMSlEQi6+F1pdMlJCt/GPuYTvuTxPfoC4LYZfttccbl
BdNfBIoe/ZsCAwEAAaAAMA0GCSqGSIb3DQEBCwUAA4IBAQDP3bkzv3j8YCPINVTQ
We2c0G2Z0Q7OKgaCpXeucNbbCHKaQeytZdzmJ+ywlDvqYw53Y4MxRVRtde9Jxr3I
nwPzP+6gJhRIV4ghbG4YxjsjEH/ueOWw6cOvEJJf3zCv4QHpzyk87y37wwjEsAx5
U2JAWUi1kxjHtyaiHpabSHuFIGnqHrO4YVe8iGATtsiatwLlH2EzA7QInjkqUhuJ
k4qaD249KZMYiWYm/ZG4TC1GDLIoRHh1Ji0rY8iJHXqYjLKtS6uH0c6LHkpEHQI/
67wHyXJW67F2O5YQ6TQixOOV+uWcX3VpgfowoyOuaV79UdiMuDkmx/19CrZ9XCGO
47i+
-----END CERTIFICATE REQUEST-----

Step 5. 签发 Server 的本地设备证书

• 设定 OpenSSL CA 配置文件：默认的配置文件为 /etc/pki/tls/openssl.cnf，每个 CA 中心可以指定一个配置文件。

$ mkdir /root/CA

$ cp /etc/pki/tls/openssl.cnf /root/CA/openssl.cnf

$ vi /root/CA/openssl.cnf
...
[ CA_default ]

# 因为 OpenSSL 解析不了 “~” 这样的特殊字符，所以配置文件应该使用绝对路径。
dir             = /root/CA              # Where everything is kept
...
certificate     = $dir/ca_01.pem        # The CA certificate
...

NOTE：签发 Server 证书时，会根据该配置文件 openssl.cnf 加载 CA 证书和 Server 的证书签名请求文件来完成签名。所以如果下述指令报错，建议检查 openssl.cnf 中各证书文件路径配置是否正确。

# -config 指定 CA 中心对应的 openssl.cnf 配置文件的路径。
$ openssl ca -passin pass:foobar -config /root/CA/openssl.cnf -in $CERT_DIR/web.apigw.com/server.csr -out /root/CA/newcerts/server.pem -batch
Using configuration from /root/CA/openssl.cnf
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 1 (0x1)
        Validity
            Not Before: Jan  5 07:31:30 2021 GMT
            Not After : Jan  5 07:31:30 2022 GMT
        Subject:
            countryName               = US
            stateOrProvinceName       = Denial
            organizationName          = Dis
            commonName                = web.apigw.com
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            Netscape Comment:
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier:
                6B:F9:65:7C:9A:9A:95:64:2C:7B:A7:BB:27:7C:6D:B1:7B:D2:96:6C
            X509v3 Authority Key Identifier:
                keyid:CB:15:A9:D0:5F:66:1B:F1:F0:05:0E:8B:0E:84:D3:88:E4:ED:36:70

Certificate is to be certified until Jan  5 07:31:30 2022 GMT (365 days)

Write out database with 1 new entries
Data Base Updated

$ cat /root/CA/newcerts/server.pem
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=Denial, L=Springfield, O=Dis, CN=web.apigw.com
        Validity
            Not Before: Jan  5 07:31:30 2021 GMT
            Not After : Jan  5 07:31:30 2022 GMT
        Subject: C=US, ST=Denial, O=Dis, CN=web.apigw.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:d5:71:3e:ed:6c:bd:2b:81:08:8f:46:7f:f6:e2:
                    1d:8b:bf:c2:94:9b:52:4f:59:8e:14:cc:a3:c8:22:
                    94:86:c0:34:c3:e9:bf:0f:80:19:82:92:8c:c0:15:
                    65:36:8c:32:e3:ed:7a:f2:1f:1c:ff:7c:05:40:1d:
                    72:ca:0f:2b:f5:1b:21:86:17:b5:85:7d:f9:80:77:
                    bc:43:28:4a:9d:d7:7e:f7:ef:34:f9:0a:c1:b2:85:
                    80:aa:63:6f:ac:77:f7:96:66:b0:1a:77:a0:bb:39:
                    73:b6:d7:3d:5e:0c:e5:89:f5:ad:5c:9b:6f:f2:b5:
                    6f:3f:1c:71:07:0b:21:b4:be:68:85:61:72:15:da:
                    61:16:57:0d:f9:93:39:7b:3e:9d:7d:39:02:f8:1e:
                    48:4f:b8:28:f4:07:4f:a3:51:bd:6c:ed:45:73:03:
                    ad:ba:f8:29:1a:18:56:f7:ec:a4:f4:3d:2c:22:7c:
                    b3:09:f0:a7:4a:9c:87:13:8c:a4:80:e3:b2:20:93:
                    40:a0:7d:d0:3a:18:8b:7e:ac:3f:8f:d0:eb:59:9d:
                    36:16:f7:58:cc:f1:f1:53:12:94:44:22:eb:e1:75:
                    a5:d3:25:24:2b:7f:18:fb:98:4e:fb:93:c4:f7:e8:
                    0b:82:d8:65:fb:6d:71:c6:e5:05:d3:5f:04:8a:1e:
                    fd:9b
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            Netscape Comment:
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier:
                6B:F9:65:7C:9A:9A:95:64:2C:7B:A7:BB:27:7C:6D:B1:7B:D2:96:6C
            X509v3 Authority Key Identifier:
                keyid:CB:15:A9:D0:5F:66:1B:F1:F0:05:0E:8B:0E:84:D3:88:E4:ED:36:70

    Signature Algorithm: sha256WithRSAEncryption
         8a:de:6a:20:af:cd:ec:60:a5:e0:31:03:ce:8b:f2:bd:37:c1:
         cb:b5:d0:88:17:d2:12:53:51:26:95:16:3b:94:f8:1f:cc:91:
         b3:1d:68:84:99:dc:5b:4a:2e:2d:82:e6:7a:d1:5e:f3:77:ec:
         e2:62:3b:a5:b1:8c:91:9e:fd:25:4c:8c:cc:86:58:08:99:1d:
         fc:ec:3e:83:ef:c9:13:b0:8e:bf:ec:33:0a:76:99:0f:52:34:
         af:49:ae:11:98:33:e3:27:26:54:b0:db:79:9a:7b:e1:83:04:
         e8:21:f5:a2:3f:fd:05:53:8d:4d:19:1e:1e:d0:59:4e:d4:71:
         95:62:dd:4e:f5:fe:e9:b0:86:1e:70:d1:c7:e8:4a:7a:1c:81:
         7b:a0:3d:31:d1:aa:5e:c0:f4:04:0b:83:5e:49:aa:80:6e:ef:
         43:fe:c8:9d:ce:8f:32:95:2e:c9:e1:3e:82:4f:55:20:3a:b5:
         f7:cb:90:92:57:99:de:40:eb:59:cb:20:ed:3f:b4:46:92:2f:
         bd:1b:38:36:85:fa:d8:53:88:89:db:c4:69:0e:dd:01:1e:f6:
         0b:2a:87:3b:83:f5:ac:95:d1:be:17:34:e0:93:06:9c:14:fc:
         e3:c6:69:36:12:ca:f6:db:f0:b5:20:ff:72:7e:17:02:f9:4d:
         50:bf:1c:5b
-----BEGIN CERTIFICATE-----
MIIDlDCCAnygAwIBAgIBATANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJVUzEP
MA0GA1UECAwGRGVuaWFsMRQwEgYDVQQHDAtTcHJpbmdmaWVsZDEMMAoGA1UECgwD
RGlzMRYwFAYDVQQDDA13ZWIuYXBpZ3cuY29tMB4XDTIxMDEwNTA3MzEzMFoXDTIy
MDEwNTA3MzEzMFowRDELMAkGA1UEBhMCVVMxDzANBgNVBAgMBkRlbmlhbDEMMAoG
A1UECgwDRGlzMRYwFAYDVQQDDA13ZWIuYXBpZ3cuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEA1XE+7Wy9K4EIj0Z/9uIdi7/ClJtST1mOFMyjyCKU
hsA0w+m/D4AZgpKMwBVlNowy4+168h8c/3wFQB1yyg8r9Rshhhe1hX35gHe8QyhK
ndd+9+80+QrBsoWAqmNvrHf3lmawGneguzlzttc9XgzlifWtXJtv8rVvPxxxBwsh
tL5ohWFyFdphFlcN+ZM5ez6dfTkC+B5IT7go9AdPo1G9bO1FcwOtuvgpGhhW9+yk
9D0sInyzCfCnSpyHE4ykgOOyIJNAoH3QOhiLfqw/j9DrWZ02FvdYzPHxUxKURCLr
4XWl0yUkK38Y+5hO+5PE9+gLgthl+21xxuUF018Eih79mwIDAQABo3sweTAJBgNV
HRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZp
Y2F0ZTAdBgNVHQ4EFgQUa/llfJqalWQse6e7J3xtsXvSlmwwHwYDVR0jBBgwFoAU
yxWp0F9mG/HwBQ6LDoTTiOTtNnAwDQYJKoZIhvcNAQELBQADggEBAIreaiCvzexg
peAxA86L8r03wcu10IgX0hJTUSaVFjuU+B/MkbMdaISZ3FtKLi2C5nrRXvN37OJi
O6WxjJGe/SVMjMyGWAiZHfzsPoPvyROwjr/sMwp2mQ9SNK9JrhGYM+MnJlSw23ma
e+GDBOgh9aI//QVTjU0ZHh7QWU7UcZVi3U71/umwhh5w0cfoSnocgXugPTHRql7A
9AQLg15JqoBu70P+yJ3OjzKVLsnhPoJPVSA6tffLkJJXmd5A61nLIO0/tEaSL70b
ODaF+thTiInbxGkO3QEe9gsqhzuD9ayV0b4XNOCTBpwU/OPGaTYSyvbb8LUg/3J+
FwL5TVC/HFs=
-----END CERTIFICATE-----

升级至 OpenSSL 1.1.1

OpenSSL 最新的 1.1.1 版本提供了 TLS 1.3 的支持，而且和 1.1.0 版本完全兼容。

CentOS7 检查是否开启了 TLS 1.3：

openssl s_client --help ｜ grep tls1_3

CentOS7 开启 TLS 1.3：

1. 下载 OpenSSL 1.1.1 版本

cd /opt
wget https://github.com/openssl/openssl/archive/OpenSSL_1_1_1-stable.zip
unzip OpenSSL_1_1_1-stable.zip

2. 编译安装

./config enable-tls1_3 --prefix=/usr/local/openssl
make && make install

3. 配置

mv /usr/bin/openssl /usr/bin/openssl.old
mv /usr/lib64/openssl /usr/lib64/openssl.old
mv /usr/lib64/libssl.so /usr/lib64/libssl.so.old
ln -s /usr/local/openssl/bin/openssl /usr/bin/openssl
ln -s /usr/local/openssl/include/openssl /usr/include/openssl
ln -s /usr/local/openssl/lib/libssl.so /usr/lib64/libssl.so
echo "/usr/local/openssl/lib" >> /etc/ld.so.conf
ldconfig -v 

4. 查看版本并验证

openssl version
openssl s_client --help | grep tls1_3