CIAA网络安全模型与TLS / HTTPS协议（上）

CIAA 网络安全模型

CIAA 网络安全模型，是构建安全网络通信的基本模型。包括了 4 个方面：

机密性（Confidentiality）：指在数据传输过程中，只有授权的用户可以查看数据，而未经授权的用户无法查看数据。机密性通常通过使用加密技术来实现。

完整性（Integrity）：指在数据传输过程中，数据没有被篡改。完整性通常使用 HASH 技术进行验证，发送方在传输数据时会生成一个 HASH Value 并将其附加到 Header 校验字段上，接收方在接收数据时会对数据进行完整性校验，以确保数据未被篡改。

认证性（Authentication）：指确认对方身份的过程，确保数据传输的安全性。常用的认证方式包括用户名和密码、数字证书等。

可用性（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 个：

CA（Certificate Authority，证书签发机构）：提供数字签名证书的签发、证书持有者身份认证等一系列信息安全服务。在公网环境中，CA 需要是一个具有权威和公信力的第三方机构；而在内网环境中，则可以创建自己的 CA，用于签发只在内网有效的证书。

数字签名证书：是一个由 CA 签发的 “特殊公钥“，通过这个公钥，Client 可以识别发送者是否为中间人。 数字签名证书。 首先来看数字签名证书，它遵循着 X.509 标准。其中目前常用的 X.509 v3 格式定义如下图所示：

Version（版本号）：v3 版本的值为 2。

Serial Number（证书序列号）：指定由 CA 分配给证书的唯一标识。

Signature Algorithm（签名算法标识符）：指定 CA 对证书执行数据签名时所使用的签名算法。

Issuer（证书签发者）：指定 CA 自己的 X.500 DN-Distinguished Name，用于确定 CA 的权威性。包括：

–C：国家

–ST：省市

–L：地区

–O：组织机构

–OU：单位部门

–CN：通用名

–邮箱地址

Validity（有效期）：包括证书开始生效的日期和证书失效的日期。

Subject（证书持有者）：指定证书持有者的 X.500 DN-Distinguished Name，用于确定证书持有者的身份合法性。包括：

– C：国家

– ST：省市

– L：地区

– O：组织机构

– OU：单位部门

– CN：通用名

– 邮箱地址

Subject PublicKey Info（证书持有者的 Public Key 信息）：包含 2 个重要信息:

– 证书持有者的 Public Key，用于后续建立非对称加密安全通道。

– Public Key 的签名算法标识符。

Extension（扩展项）：v3 开始支持的证书扩展信息，用于扩展证书的作用。

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 证书为例：

网站在本地创建自己的 Private Key 和 Public Key。

网站向 CA 提交自己的公司信息、网站域名信息、Public Key 信息等并申请签发。

CA 通过线上、线下等多种手段验证网站提供的信息的真实性，例如：公司是否存在、域名是否合法等等。

审核通过后，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 就可以加载相应的 Server Private Key 和 CA 证书并启动 TLS 协议了。后续，当 Client 向 Server 发起 HTTPS 请求时，Server 就会把 CA 证书返回。Client 拿着 CA 证书发起 CA 认证流程：

Client 首先会从 CA 证书的签发机构安装一张 CA 公钥证书。

然后用 CA 公钥证书对从 Server 接收到的 CA 证书的 Signature 进行解密，得到一份数字摘要。

同时用 CA 证书指定的 HASH 函数对 CA 证书的明文 Data 部分进行计算，得到另一份数字摘要。

如果 2 份 “数字摘要“ 相同，则表示 Client 收到的 CA 证书一定是 Server 下发的。

因为 HASH 的唯一性特征，即便中间人拥有了 CA 公钥证书，能够解析并篡改 CA 证书的 Data 和数字摘要，但是中间人却没有 CA 私钥来重新加密得到 Signature。如果中间人强行篡改 Data，那么在 Client 处也无法通过 Signature 得到一致的数字摘要。浏览器会出现以下画面，告诉你正在遭受中间人攻击，因为证书被篡改了。



使用 OpenSSL 自建 CA 并签发证书

OpenSSL 是一个强大的安全传输层应用库，利用 OpenSSL 可以自建企业内网环境中使用的 CA 中心，并支持根据不同的需要生成多种类型的数字签名证书，包括：

•DER：二进制格式证书，包含公钥，不包含私钥，常用后缀为 .der、.cer、.crt。

•PEM：ASCII 格式证书，包含公钥，不包含私钥，以 —–BEGIN CERTIFICATE—–、以 —–END CERTIFICATE—– 结尾。常用后缀为 .pem、.cer、.crt。

•PKCS#12：二进制格式证书，包含公钥，可以包含私钥，也可以不包含私钥，常用的后缀为 .P12 和 .PFX。

自建 CA 并签发证书的流程如下图所示：



Step 1. 创建 CA 工作目录和配置文件

OpenSSL 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 私钥

openssl genrsa [args] [numbits]

• -des：使用 CBC 模式的 DES 加密算法。

• -des3：使用 CBC 模式的 3DES 加密算法。

• -aes128：使用 CBC 模式的 AES128 加密算法。

• -aes192：使用 CBC 模式的 AES192 加密算法。

• -aes256：使用 CBC 模式的 AES256 加密算法。

• -passout arg：指定加密 CA 私钥文件的密码，私钥文件的安全级别非常高。

• -out file：指定输出 Private Key 的文件名。

• [numbits]：指定密钥长度。

$ 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 是自建的，没有上级 CA，所以这个 CA 公钥证书就是根证书。

openssl req [options] outfile

• -inform arg：指定输入文件格式，例如：DER、PEM。

• -outform arg：指定输出文件格式，例如：DER、PEM。

• -in arg：指定待输入文件。

• -out arg：指定待输出文件。

• -passin：指定 Private Key 的解密密码。

• -key file：指定 CA Private Key 文件。

• -keyform arg：指定 Private Key 的加密算法，例如：DER、NET、PEM。

• -new：指示生成一个新的 CSR。

• -x509：指定使用 X509 标准。

• -days：指定 X509 证书的有效日期和时间。

• -[digest]：指定 HASH 算法，例如：md5、sha1、md2、mdc2、md4。

• -config file：指定 openssl 配置文件。

• -text：指示使用 text 显示格式。

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

$ 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 公钥证书内含了与 Public Key 信息。

$ openssl x509 -in ca_01.pem -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
b91fa1cc:5d
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=Denial, L=Springfield, O=Dis, CN=www.example.com
Validity
Not Before: Nov 9 0751 2018 GMT
Not After : Nov 9 0751 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:
0035fb0b27fc91b6:
aa128f5377cfae9f:
176d273c7245106b:
67778f2d33a1a2a2:
a400e637ca5ae642:
a05b6d933aa13afb:
5eab3a632f688f77:
d94d6e41455ef936:
08b8b556216e51ad:
ce4e97f8e9388804:
591bc9c88d3fa92e:
bf484b3f9f90abfb:
c9bce8797545edec:
5652408b7a6ded09:
e3ef0e346b2172c5:
ce61bb1dbfaae2a8:
3c17df9b84b1d919:
e1:45
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
73B6C9B97005A39CFDB8:A3
X509v3 Authority Key Identifier:
keyidD4E15DCE9107C42DEEA3

X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: sha256WithRSAEncryption
4ad0a621d74b98522d
d0459010b23cbb326a
a6631e0c7ed857e849
a722fc5c7306a175fa
b689ecfa9f0c863085
5e5aa051c4edbeffc1
93794bb8fbdfe5a969
56d274a7ac349c6c64
71cc3ea632bcbb15cd
676e2bfb3284044917
1e7de99ef048187e62
9a6a274cac9ba7e0e9
d2d0f3a7ad0bdb21cf
22e0e25d7390dceaf7
7225:87

Step 4. 生成 Server 公钥和私钥

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

$ 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. CA 签发 Server 的 CA 证书

设定 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
...

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

openssl ca [options]

• -selfsign：使用 CSR 文件来进行签发，即：“自签名”，这种情况发生在生成证书的 CA 客户端与签发证书的 CA 服务器都是同一台机器，此时可以使用同一个密钥对来进行 “自签名”。

• -in file：指定待签发的文件。

• -out file：指定输出的 CA 证书文件。

• -cert file：指定 CA 公钥证书。

• -days arg：指定 CA 证书的签有效日期和时间。

• -keyfile arg：指定 CA 私钥文件。

• -keyform arg：指定 CA 私钥文件的格式，例如：PEM、ENGINE。

• -key arg：指定 CA 私钥文件的解密密码。

• -config file：配置文件。

$ 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 0730 2021 GMT
Not After : Jan 5 0730 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:
6B659A952CA7276D7B96:6C
X509v3 Authority Key Identifier:
keyid15D066F1058B8488ED70

Certificate is to be certified until Jan 5 0730 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 0730 2021 GMT
Not After : Jan 5 0730 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:
0071edbd818f7fe2:
1dbf94525914a322:
94c0c3bf80828c15:
658ce37a1fff051d:
720ff5211785f977:
bc289d7eeff9c185:
8063acf7661aa039:
73d75ee5f55c6fb5:
6f1c0721be8572da:
6157f9393e7d021e:
48b8f44f516c4503:
adf81a56ecf42c7c:
b3f04a878c80b293:
407d3a8bac8feb9d:
36f7ccf11244eb75:
a5252b1898fbc4e8:
0bd8fb71e5d3041e:
fd:9b
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
6B659A952CA7276D7B96:6C
X509v3 Authority Key Identifier:
keyid15D066F1058B8488ED70

Signature Algorithm: sha256WithRSAEncryption
8a6aafeca531cef237
cbd0171251953bf8cc
b368995b2e827a5e77
e23bb191fd4ccc5899
fc3eef138eec0a9952
afae98e326b0797b83
e8f53f058d191e59d4
95ddf5e98670c74a1c
7b3dd15ef40b5eaa6e
43c8ce322ee182553a
f79057deebcbedb492
bd3885d888db69dd1e
0b8783acd117e00614
e36912f6f0207217f9
501c: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-----

审核编辑：刘清