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 700private

# 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 私鑰

opensslgenrsa [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 -passoutpass:foobar -des3-out$CERT_DIR/private/cakey.pem 2048
GeneratingRSA private key, 2048 bit long modulus
....................+++
..................................................+++
eis 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
-----BEGINRSA 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
-----ENDRSA PRIVATE KEY-----

Step 3. 生成 CA 公鑰證書

因為該 CA 是自建的，沒有上級 CA，所以這個 CA 公鑰證書就是根證書。

opensslreq [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-passinpass:foobar -new-nodes-key$CERT_DIR/private/cakey.pem -days365 -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
-----BEGINCERTIFICATE-----
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=
-----ENDCERTIFICATE-----

可以看見新建的 CA 公鑰證書內含了與 Public Key 信息。

$openssl x509 -inca_01.pem -text-noout
Certificate:
Data:
Version:3 (0x2)
SerialNumber:
b91fa1cc:5d
SignatureAlgorithm: sha256WithRSAEncryption
Issuer:C=US, ST=Denial, L=Springfield, O=Dis, CN=www.example.com
Validity
NotBefore: Nov 9 0751 2018 GMT
NotAfter : Nov 9 0751 2019 GMT
Subject:C=US, ST=Denial, L=Springfield, O=Dis, CN=www.example.com
SubjectPublic Key Info:
PublicKey Algorithm: rsaEncryption
Public-Key:(2048bit)
Modulus:
0035fb0b27fc91b6:
aa128f5377cfae9f:
176d273c7245106b:
67778f2d33a1a2a2:
a400e637ca5ae642:
a05b6d933aa13afb:
5eab3a632f688f77:
d94d6e41455ef936:
08b8b556216e51ad:
ce4e97f8e9388804:
591bc9c88d3fa92e:
bf484b3f9f90abfb:
c9bce8797545edec:
5652408b7a6ded09:
e3ef0e346b2172c5:
ce61bb1dbfaae2a8:
3c17df9b84b1d919:
e1:45
Exponent:65537 (0x10001)
X509v3extensions:
X509v3Subject Key Identifier:
73B6C9B97005A39CFDB8:A3
X509v3Authority Key Identifier:
keyidD4E15DCE9107C42DEEA3

X509v3Basic Constraints:
CA:TRUE
SignatureAlgorithm: 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 -newkeyrsa: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
Generatinga 2048 bit RSA private key
.........+++
....................................................................................................................................................................................................+++
writingnew private key to '/root/CA/web.apigw.com/server.key'
-----

$cat /root/CA/web.apigw.com/server.key
-----BEGINPRIVATE 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
-----ENDPRIVATE KEY-----

$cat /root/CA/web.apigw.com/server.csr
-----BEGINCERTIFICATE 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+
-----ENDCERTIFICATE 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 中各證書文件路徑配置是否正確。

opensslca [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 -passinpass:foobar -config/root/CA/openssl.cnf -in$CERT_DIR/web.apigw.com/server.csr -out/root/CA/newcerts/server.pem -batch
Usingconfiguration from /root/CA/openssl.cnf
Checkthat the request matches the signature
Signatureok
CertificateDetails:
SerialNumber: 1 (0x1)
Validity
NotBefore: Jan 5 0730 2021 GMT
NotAfter : Jan 5 0730 2022 GMT
Subject:
countryName= US
stateOrProvinceName= Denial
organizationName= Dis
commonName= web.apigw.com
X509v3extensions:
X509v3Basic Constraints:
CA:FALSE
NetscapeComment:
OpenSSLGenerated Certificate
X509v3Subject Key Identifier:
6B659A952CA7276D7B96:6C
X509v3Authority Key Identifier:
keyid15D066F1058B8488ED70

Certificateis to be certified until Jan 5 0730 2022 GMT (365days)

Writeout database with 1 new entries
DataBase Updated

$cat /root/CA/newcerts/server.pem
Certificate:
Data:
Version:3 (0x2)
SerialNumber: 1 (0x1)
SignatureAlgorithm: sha256WithRSAEncryption
Issuer:C=US, ST=Denial, L=Springfield, O=Dis, CN=web.apigw.com
Validity
NotBefore: Jan 5 0730 2021 GMT
NotAfter : Jan 5 0730 2022 GMT
Subject:C=US, ST=Denial, O=Dis, CN=web.apigw.com
SubjectPublic Key Info:
PublicKey Algorithm: rsaEncryption
Public-Key:(2048bit)
Modulus:
0071edbd818f7fe2:
1dbf94525914a322:
94c0c3bf80828c15:
658ce37a1fff051d:
720ff5211785f977:
bc289d7eeff9c185:
8063acf7661aa039:
73d75ee5f55c6fb5:
6f1c0721be8572da:
6157f9393e7d021e:
48b8f44f516c4503:
adf81a56ecf42c7c:
b3f04a878c80b293:
407d3a8bac8feb9d:
36f7ccf11244eb75:
a5252b1898fbc4e8:
0bd8fb71e5d3041e:
fd:9b
Exponent:65537 (0x10001)
X509v3extensions:
X509v3Basic Constraints:
CA:FALSE
NetscapeComment:
OpenSSLGenerated Certificate
X509v3Subject Key Identifier:
6B659A952CA7276D7B96:6C
X509v3Authority Key Identifier:
keyid15D066F1058B8488ED70

SignatureAlgorithm: sha256WithRSAEncryption
8a6aafeca531cef237
cbd0171251953bf8cc
b368995b2e827a5e77
e23bb191fd4ccc5899
fc3eef138eec0a9952
afae98e326b0797b83
e8f53f058d191e59d4
95ddf5e98670c74a1c
7b3dd15ef40b5eaa6e
43c8ce322ee182553a
f79057deebcbedb492
bd3885d888db69dd1e
0b8783acd117e00614
e36912f6f0207217f9
501c:5b
-----BEGINCERTIFICATE-----
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=
-----ENDCERTIFICATE-----

審核編輯：劉清