[[315625]]

 HTTPS 解決什么問題

HTTPS解決兩個問題：

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

對稱加密算法

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

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

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

非對稱加密算法

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

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

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

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

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

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

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

身份認證

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

怎么證明我是我?

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

那么電子世界的有這個官方機構(gòu)嗎?有!

PKI 基礎(chǔ)設(shè)施

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

證書頒發(fā)

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

證書頒發(fā)流程大概分為：

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

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

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

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

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

信任鏈和信任錨

 

 

 

 

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

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

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

Nginx部署證書和校驗分析

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

 

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-----之間即為一個證書，第一個必須為域名實體證書，后面的依次為中級證書或交叉證書，經(jīng)測試，第一個域名實體證書順序必須放第一個，后續(xù)中級證書可相互調(diào)換順序，通常增加中間證書建議追加到最后面。CER在線讀取工具

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

 

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

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

 

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

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

 

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

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

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

 

 

 

 

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

 

 

 

 

 

 

 

 

 

 

 

 

百度網(wǎng)站證書分析舉例

 

 

 

 

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

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

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

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

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

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

MAC系統(tǒng)最新內(nèi)置的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，F(xiàn)ireFox瀏覽器中還存在R6

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

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

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

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

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

 

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

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

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

 

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

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

變更如下圖：

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

 

 

 

 

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

 

 

 

 

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