[[315625]]

 HTTPS 解決什么問題

HTTPS解決兩個問題：

• 加密傳輸保證客戶端和服務器之間的信息不是明文傳輸，保證信息的機密性
• 身份認證HTTPS協議能夠證明服務端的身份，防止假冒網站冒充自己的身份。

對稱加密算法

這一部分需要密碼學的基礎，本段僅做相關總結。對稱加密因為密鑰只有一個，存在密鑰被枚舉出來的問題，加密安全性不夠高。

常見的對稱加密有 DES，3DES，AES

因為性能比非對稱加密高，所以用在HTTPS內容加密上，HTTPS通過非對稱加密算法做密鑰協商生成密鑰，用作頁面內容的對稱加密。

非對稱加密算法

常見的非對稱加密算法都是基于數學難題，在當前計算能力下破解較難，常見的算法有RSA，ECC等。抽象出幾個名詞概念：公鑰，私鑰。

公鑰和私鑰可以通過數學算法計算相互對明文密文進行數學計算并驗證。

加密： 通過公鑰(或私鑰)對明文計算(如RSA)生成密文

解密： 通過另一個密鑰對密文進行計算生成明文

上面加解密的概念是相對的，在日常應用中，常見的兩個場景：

• 發送方通過接收方公鑰對明文加密，接收方通過自己的私鑰進行解密
• 需要身份認證的場景下，用自己的私鑰對待簽名的內容進行電子簽章，需要驗證的時候，驗證者獲取簽名者的公鑰進行驗證(公鑰對密文進行數學計算解密)

非對稱加密算法的場景 – 身份認證和PKI

身份認證

上節提到非對稱加密算法的一個場景是數字簽名，數字簽名是身份認證的手法。因為自己的私鑰是別人不知道的也是別人不可復制的，如同人的指紋一樣，是能代表自己本人的。但是問題來了?我想讓別人拿著我的公鑰和我進行加密通信，對方是如何知道這是我的公鑰呢?

怎么證明我是我?

證明我是我，只能拿著本人的身份證去派出所查詢，然后讓官方出具一份“本人證明”，因為有關部門是可信的，所以如果官方說這個是合法的，那就能證明這就是我。

那么電子世界的有這個官方機構嗎?有!

PKI 基礎設施

PKI是安全世界的基礎設施，CA機構是其主要成員，CA機構通過向申請證明“我就是我”的用戶頒發證書，用戶通過校驗證書的有效性，來判斷是否是自己需要通信的對方。當然，CA是盈利機構，企業申請證書證明“我就是我”需要花費不少費用的，當然，不差錢!

證書頒發

證書內容：證書 = 使用者公鑰 + 主體信息如公司名稱等 + CA對信息的確認簽名 + 指紋

證書頒發流程大概分為：

• 申請者生成CSR，申請時填寫公司主體身份信息，生成CSR和私鑰，CSR內容相當于公鑰和身份信息。
• 選擇CA證書簽發機構，如亞馬遜，Globalsign，或免費機構
• 提交CSR，CA會驗證公司主體信息，沒問題后會對申請者提交上來的CSR進行簽名，生成web服務器能部署的公鑰
• 發送給申請者

可見在可信官方CA機構的簽發下，大家看到這個證書后都可以認為這就是你本人沒錯了。客戶端都內置可信機構的根證書，所以承認這個官方機構，這個在之后的信任鏈部分會詳細介紹。

但是問題又來了，隨著HTTPS越來越多，頒發機構忙不過來怎么辦?各國之間語言溝通障礙怎么辦?如同現實世界，官方機構會授權子公司或者新開總公司分部，同理，CA機構們也會增加自己的分公司，從而產生了中級證書和交叉證書的概念。

中級證書：不使用根證書的私鑰對申請者的CSR進行簽名，而采用中級證書對申請者的CSR進行簽名頒發證書.

交叉證書：不同根證書之間的相互簽名，改變信任起始點

信任鏈和信任錨

 

 

 

 

由于中級證書的采用，整個證書有效性校驗流程里有了信任鏈的概念，信任鏈就是客戶端從服務器實體證書向上逐級校驗，每一級證書校驗過程是通過拿到證書簽發者(Issuer)的證書中的公鑰(證書 = 使用者公鑰 + 主體信息如公司名稱等 + CA對信息的確認簽名 + 指紋)對本級證書(Subject)的簽名進行數學驗證，驗證成功即證書有效。

整個一級一級驗證上去，形成信任鏈。直到一個證書的簽發者和使用者是同一個人，則這個點為信任錨，即信任鏈的起始點，起始點需要在客戶端系統或者瀏覽器的根證書信任列表中，整個流程結束后，證書可信。

PS：不同瀏覽器(客戶端)的可信根證書列表是不同的，Chrome讀取系統中的根證書列表，而FireFox瀏覽器則使用自己瀏覽器內置的可信根證書列表。

Nginx部署證書和校驗分析

Nginx服務器證書部署使用base64編碼格式的證書。通過CA頒發證書后獲得一個base64格式的證書，和私鑰一起部署在服務器中。

 

ssl on; 
ssl_certificate /opt/soft/ssl/0xfe.com.cn_chain.crt; 
ssl_certificate_key /opt/soft/ssl/0xfe.com.cn_key.key; 

0xfe.com.cn_chain.crt為公鑰文件，0xfe.com.cn_key.key為私鑰文件。

 

cat /opt/soft/ssl/0xfe.com.cn_chain.crt 
-----BEGIN CERTIFICATE----- 
MIIFpjCCBI6gAwIBAgIQBjLXXyMcU5DDZQ7gshcXdTANBgkqhkiG9w0BAQsFADBy 
MQswCQYDVQQGEwJDTjElMCMGA1UEChMcVHJ1c3RBc2lhIFRlY2hub2xvZ2llcywg 
SW5jLjEdMBsGA1UECxMURG9tYWluIFZhbGlkYXRlZCBTU0wxHTAbBgNVBAMTFFRy 
dXN0QXNpYSBUTFMgUlNBIENBMB4XDTE5MDgxNjAwMDAwMFoXDTIwMDgxNTEyMDAw 
MFowFjEUMBIGA1UEAxMLMHhmZS5jb20uY24wggEiMA0GCSqGSIb3DQEBAQUAA4IB 
DwAwggEKAoIBAQDcNNv3Ap4P+LRHrPHPWwuHHZhexQiSCPBAba/kSAcXjFAxaI7o 
NdyiuBmUhPoGeV3YvIpzV9nsgcar94yDWef/L6Dl5SpVlHYYudgDwa+MKibhPGaL 
ncW3urpPok3LFngSz63n2xg77Of4gEcOOeMPdzUb9UT6tKrZlPKXRjrGXKbLTwTj 
AQo4MhvmS8ZddmaRjCTSxhJrZ8n4W2YfgBjITZEqNDDQyhxkS5Sr8/8OQ8wfn38c 
rrd6FMAgnjnEZZVi3ivd4+XEz+g/DNE/m7+8cmRuHfG8ELXjGnswquJstgllNyUl 
qumW3dfE9YVIJlQkvEQWFMsw5dzxHidJWTFLAgMBAAGjggKSMIICjjAfBgNVHSME 
GDAWgBR/05nzoEcOMQBWViKOt8ye3coBijAdBgNVHQ4EFgQUlKhM50RH3AC7pIcy 
qEoULdttwXUwJwYDVR0RBCAwHoILMHhmZS5jb20uY26CD3d3dy4weGZlLmNvbS5j 
bjAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMC 
MEwGA1UdIARFMEMwNwYJYIZIAYb9bAECMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v 
d3d3LmRpZ2ljZXJ0LmNvbS9DUFMwCAYGZ4EMAQIBMIGSBggrBgEFBQcBAQSBhTCB 
gjA0BggrBgEFBQcwAYYoaHR0cDovL3N0YXR1c2UuZGlnaXRhbGNlcnR2YWxpZGF0 
aW9uLmNvbTBKBggrBgEFBQcwAoY+aHR0cDovL2NhY2VydHMuZGlnaXRhbGNlcnR2 
YWxpZGF0aW9uLmNvbS9UcnVzdEFzaWFUTFNSU0FDQS5jcnQwCQYDVR0TBAIwADCC 
AQQGCisGAQQB1nkCBAIEgfUEgfIA8AB2AO5Lvbd1zmC64UJpH6vhnmajD35fsHLY 
gwDEe4l6qP3LAAABbJg76VwAAAQDAEcwRQIhAO5fxTuzbUnz6fna1BAyOzzAxoSw 
N1xo0lnXrMr2bVBrAiAe2PWp7rCX0eMzO+ZdICzFwQtcULLHSGehHv8CgMqbNQB2 
AId1v+dZfPiMQ5lfvfNu/1aNR1Y2/0q1YMG06v9eoIMPAAABbJg76eAAAAQDAEcw 
RQIhAItx6WPv2a2nKIBRVDuvns5D4fElzlPAHMVM9gKDA4HcAiB/D+n/UCFAH5YY 
L6r+vLKgLRJCfq5Vw0kaLWA+P3a5RDANBgkqhkiG9w0BAQsFAAOCAQEAllOZKfyY 
hoyC5/FRnEhoY/6v/kbzPlVsgZvUVtk3IDnyo7GOaUUigQaLSmL0oWTnwmMOweb7 
UhP1TL+RCYcw2fc39l4FIaOKjMmSaPLZw2Fm9Lk/ie5BZ3pLD5A3exz4nMgVjJB6 
XC0ZiBgTsCOl3K3vFefL4x4ewoR0KwN5fTwkxKKT7XUCMTcIOMgWX2ubUXhjM2cy 
c9lRPTy2joO4za9AS6sR5JExLY/kJ3dR7t99gko5MnJZINcPD8WIUySw5oQZA22Y 
OhFVBGiERcH+oD6TNoZuqu2pSfrAIFT3dWpb1bGgiCxblsN2yH1REXmnTx3bmuy2 
UAXfwUlUhtmRbw== 
-----END CERTIFICATE----- 
-----BEGIN CERTIFICATE----- 
MIIErjCCA5agAwIBAgIQBYAmfwbylVM0jhwYWl7uLjANBgkqhkiG9w0BAQsFADBh 
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3 
d3cuZGlnaWNlcnQuY29tMSAwHgYDVQQDExdEaWdpQ2VydCBHbG9iYWwgUm9vdCBD 
QTAeFw0xNzEyMDgxMjI4MjZaFw0yNzEyMDgxMjI4MjZaMHIxCzAJBgNVBAYTAkNO 
MSUwIwYDVQQKExxUcnVzdEFzaWEgVGVjaG5vbG9naWVzLCBJbmMuMR0wGwYDVQQL 
ExREb21haW4gVmFsaWRhdGVkIFNTTDEdMBsGA1UEAxMUVHJ1c3RBc2lhIFRMUyBS 
U0EgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCgWa9X+ph+wAm8 
Yh1Fk1MjKbQ5QwBOOKVaZR/OfCh+F6f93u7vZHGcUU/lvVGgUQnbzJhR1UV2epJa 
e+m7cxnXIKdD0/VS9btAgwJszGFvwoqXeaCqFoP71wPmXjjUwLT70+qvX4hdyYfO 
JcjeTz5QKtg8zQwxaK9x4JT9CoOmoVdVhEBAiD3DwR5fFgOHDwwGxdJWVBvktnoA 
zjdTLXDdbSVC5jZ0u8oq9BiTDv7jAlsB5F8aZgvSZDOQeFrwaOTbKWSEInEhnchK 
ZTD1dz6aBlk1xGEI5PZWAnVAba/ofH33ktymaTDsE6xRDnW97pDkimCRak6CEbfe 
3dXw6OV5AgMBAAGjggFPMIIBSzAdBgNVHQ4EFgQUf9OZ86BHDjEAVlYijrfMnt3K 
AYowHwYDVR0jBBgwFoAUA95QNVbRTLtm8KPiGxvDl7I90VUwDgYDVR0PAQH/BAQD 
AgGGMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjASBgNVHRMBAf8ECDAG 
AQH/AgEAMDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Au 
ZGlnaWNlcnQuY29tMEIGA1UdHwQ7MDkwN6A1oDOGMWh0dHA6Ly9jcmwzLmRpZ2lj 
ZXJ0LmNvbS9EaWdpQ2VydEdsb2JhbFJvb3RDQS5jcmwwTAYDVR0gBEUwQzA3Bglg 
hkgBhv1sAQIwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t 
L0NQUzAIBgZngQwBAgEwDQYJKoZIhvcNAQELBQADggEBAK3dVOj5dlv4MzK2i233 
lDYvyJ3slFY2X2HKTYGte8nbK6i5/fsDImMYihAkp6VaNY/en8WZ5qcrQPVLuJrJ 
DSXT04NnMeZOQDUoj/NHAmdfCBB/h1bZ5OGK6Sf1h5Yx/5wR4f3TUoPgGlnU7EuP 
ISLNdMRiDrXntcImDAiRvkh5GJuH4YCVE6XEntqaNIgGkRwxKSgnU3Id3iuFbW9F 
UQ9Qqtb1GX91AJ7i4153TikGgYCdwYkBURD8gSVe8OAco6IfZOYt/TEwii1Ivi1C 
qnuUlWpsF1LdQNIdfbW3TSe0BhQa7ifbVIfvPWHYOu3rkg1ZeMo6XRU9B4n5VyJY 
RmE= 
-----END CERTIFICATE----- 

 

cat /opt/soft/ssl/0xfe.com.cn_key.key 
-----BEGIN RSA PRIVATE KEY----- 
省略 
-----END RSA PRIVATE KEY----- 

公鑰文件中，-----BEGIN CERTIFICATE-----和-----END CERTIFICATE-----之間即為一個證書，第一個必須為域名實體證書，后面的依次為中級證書或交叉證書，經測試，第一個域名實體證書順序必須放第一個，后續中級證書可相互調換順序，通常增加中間證書建議追加到最后面。CER在線讀取工具

將上述第一段輸入到在線讀取工具中，輸出如下：

 

CER解碼結果： 
 
通用名 ：0xfe.com.cn 
可用域名 ：DNS:0xfe.com.cn, DNS:www.0xfe.com.cn 
有效時間段 ：2019-08-16 - 2020-08-15 
序列號 ：8239351073242680476627775209099171701 
頒發者 ：TrustAsia TLS RSA CA 
有效期 ：2020-08-15 20:00:00 

將上述第二段輸入到在線讀取工具中，輸出如下：

 

CER解碼結果： 
 
通用名 ：TrustAsia TLS RSA CA 
公司組織名 ：TrustAsia Technologies, Inc. 
有效時間段 ：2017-12-08 - 2027-12-08 
序列號 ：7311534772508790650765434802415791662 
頒發者 ：DigiCert Global Root CA 
有效期 ：2027-12-08 20:28:26 

可見上述，兩端base64證書分別對應域名實體證書和中級證書。

 

上述證書信任鏈為： 
0xfe.com.cn <----校驗----   TrustAsia TLS RSA CA  <----校驗----  DigiCert Global Root CA （存在系統或瀏覽器中） 

客戶端通過TrustAsia TLS RSA CA證書中的公鑰驗證0xfe.com.cn證書中的簽名，通過客戶端通過DigiCert Global Root CA證書中的公鑰驗證TrustAsia TLS RSA CA證書中的簽名，通過。

上面的DigiCert Global Root CA稱為根證書。

 

 

 

 

為了校驗上述流程，可通過禁用系統的根證書，下圖將DigiCert Global Root CA禁用，標為不信任，可見瀏覽器將0xfe.com.cn標記為不信任。

 

 

 

 

 

 

 

 

 

 

 

 

百度網站證書分析舉例

 

 

 

 

可見百度證書校驗信任鏈為：

baidu.com <—-校驗—- GlobalSign Organization Validation CA - SHA256 - G2 <—-校驗—- GlobalSign Root CA (存在系統或瀏覽器中)

客戶端通過GlobalSign Organization Validation CA - SHA256 - G2證書中的公鑰驗證baidu.com證書中的簽名，通過;

客戶端通過GlobalSign Root CA證書中的公鑰驗證GlobalSign Organization Validation CA - SHA256 - G2證書中的簽名，通過。

上面的GlobalSign Root CA稱為根證書。

使用GlobalSign CA 交叉證書改變信任錨

MAC系統最新內置的GlobalSign CA有5個:

 

 

 

 

組織單位分別稱為：

 

Root CA 
GlobalSign Root CA - R2 
GlobalSign ECC Root CA - R5 
GlobalSign ECC Root CA - R4 
GlobalSign Root CA - R3 

即R1到R5，FireFox瀏覽器中還存在R6

也就是說Gloabalsign一共有這些根證書在使用。

存在以下場景需使用交叉證書：

GlobalSign在根CA啟用頒發證書的過程中，會出現客戶端沒有來得及更新根CA的情況，如客戶端只存在R1到R3三個根證書，缺少其他幾個根證書。

這個時候使用較新根證書如R4頒發的域名證書會被客戶端標記為不安全，這時候GlobalSign會提供交叉證書，將信任錨從較新CA根證書如R4指向到客戶端存在的根證書R1上，解決客戶端無法訪問的問題。

下面將用一個例子直觀的表示這個場景：

 

baidu.com <----校驗----  GlobalSign Organization Validation CA - SHA256 - G2  <----校驗----  GlobalSign Root CA - R4 （GlobalSign Root CA - R4不存在客戶端中） 

GlobalSign Root CA - R4不存在客戶端可信任根證書列表中，所以信任鏈不完整，無法正常訪問，如何在無需重新簽發中級證書GlobalSign Organization Validation CA - SHA256 - G2的情況下解決客戶端問題呢?根據上面的分析，只需要在Nginx服務器公鑰文件后面增加交叉證書的base64編碼版本即可，此時信任鏈會新會增加一級，將信任錨點從R4根證書轉移到R1根證書。

在部署nginx時增加一段交叉證書，改變信任錨，修改后的信任鏈將為：

 

baidu.com <----校驗----  GlobalSign Organization Validation CA - SHA256 - G2  <----校驗---- R1-R4交叉證書<----校驗---- Root CA  （Root CA 為GlobalSign Root CA R1，存在于系統中） 

即使用R1-R4交叉證書簽名且驗證GlobalSign Organization Validation CA - SHA256 - G2,使用Root CA簽名且驗證R1-R4交叉證書，將信任錨點從R4根證書轉移到R1根證書，R1根證書存在于系統中，所以可以解決因為較新CA根證書頒發的證書不可信問題。備注：GlobalSign2019年5月27日遷移簽發 SSL 證書的中級 CA，使用 RSA 算法密鑰的 OV SSL 證書將在新的中級 CA 下簽發，該中級 CA 將鏈到 GlobalSign R3 根證書下。如使用此算法頒發的證書，請保持系統中R3根證書存在，在這之前頒發的證書中的中級證書鏈到 GlobalSign R1 根證書下。

變更如下圖：

更改前，中級證書鏈到R1根證書：

 

 

 

 

更改后，中級證書鏈到R3根證書：

 

 

 

 

使用GlobalSign CA 的用戶請注意變更帶來的影響，可增加GlobalSign R1R3交叉證書到證書文件，解決客戶端不存在R3根證書的問題。