HTTPS證書是怎么為網(wǎng)站正名的

這篇文章給大家分享的是有關(guān)HTTPS證書是怎么為網(wǎng)站正名的的內(nèi)容。小編覺得挺實(shí)用的，因此分享給大家做個(gè)參考，一起跟隨小編過來看看吧。

 HTTPS 解決什么問題

HTTPS解決兩個(gè)問題：

• 加密傳輸保證客戶端和服務(wù)器之間的信息不是明文傳輸，保證信息的機(jī)密性

• 身份認(rèn)證HTTPS協(xié)議能夠證明服務(wù)端的身份，防止假冒網(wǎng)站冒充自己的身份。

對(duì)稱加密算法

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

常見的對(duì)稱加密有 DES，3DES，AES

因?yàn)樾阅鼙确菍?duì)稱加密高，所以用在HTTPS內(nèi)容加密上，HTTPS通過非對(duì)稱加密算法做密鑰協(xié)商生成密鑰，用作頁面內(nèi)容的對(duì)稱加密。

非對(duì)稱加密算法

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

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

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

解密： 通過另一個(gè)密鑰對(duì)密文進(jìn)行計(jì)算生成明文

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

• 發(fā)送方通過接收方公鑰對(duì)明文加密，接收方通過自己的私鑰進(jìn)行解密

• 需要身份認(rèn)證的場景下，用自己的私鑰對(duì)待簽名的內(nèi)容進(jìn)行電子簽章，需要驗(yàn)證的時(shí)候，驗(yàn)證者獲取簽名者的公鑰進(jìn)行驗(yàn)證(公鑰對(duì)密文進(jìn)行數(shù)學(xué)計(jì)算解密)

非對(duì)稱加密算法的場景 – 身份認(rèn)證和PKI

身份認(rèn)證

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

怎么證明我是我?

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

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

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

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

證書頒發(fā)

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

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

• 申請(qǐng)者生成CSR，申請(qǐng)時(shí)填寫公司主體身份信息，生成CSR和私鑰，CSR內(nèi)容相當(dāng)于公鑰和身份信息。

• 選擇CA證書簽發(fā)機(jī)構(gòu)，如亞馬遜，Globalsign，或免費(fèi)機(jī)構(gòu)

• 提交CSR，CA會(huì)驗(yàn)證公司主體信息，沒問題后會(huì)對(duì)申請(qǐng)者提交上來的CSR進(jìn)行簽名，生成web服務(wù)器能部署的公鑰

• 發(fā)送給申請(qǐng)者

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

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

中級(jí)證書：不使用根證書的私鑰對(duì)申請(qǐng)者的CSR進(jìn)行簽名，而采用中級(jí)證書對(duì)申請(qǐng)者的CSR進(jìn)行簽名頒發(fā)證書.

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

信任鏈和信任錨

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

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

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

Nginx部署證書和校驗(yàn)分析

Nginx服務(wù)器證書部署使用base64編碼格式的證書。通過CA頒發(fā)證書后獲得一個(gè)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 Yh2Fk1MjKbQ5QwBOOKVaZR/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/h2bZ5OGK6Sf1h6Yx/5wR4f3TUoPgGlnU7EuP ISLNdMRiDrXntcImDAiRvkh6GJuH4YCVE6XEntqaNIgGkRwxKSgnU3Id3iuFbW9F 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-----之間即為一個(gè)證書，第一個(gè)必須為域名實(shí)體證書，后面的依次為中級(jí)證書或交叉證書，經(jīng)測試，第一個(gè)域名實(shí)體證書順序必須放第一個(gè)，后續(xù)中級(jí)證書可相互調(diào)換順序，通常增加中間證書建議追加到最后面。CER在線讀取工具

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

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

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

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

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

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

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

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

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

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

可見百度證書校驗(yàn)信任鏈為：

baidu.com <&mdash;-校驗(yàn)&mdash;- GlobalSign Organization Validation CA - SHA256 - G2 <&mdash;-校驗(yàn)&mdash;- GlobalSign Root CA (存在系統(tǒng)或?yàn)g覽器中)

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

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

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

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

MAC系統(tǒng)最新內(nèi)置的GlobalSign CA有5個(gè):

組織單位分別稱為：

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ā)證書的過程中，會(huì)出現(xiàn)客戶端沒有來得及更新根CA的情況，如客戶端只存在R1到R3三個(gè)根證書，缺少其他幾個(gè)根證書。

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

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

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

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

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

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

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

變更如下圖：

更改前，中級(jí)證書鏈到R1根證書：

更改后，中級(jí)證書鏈到R3根證書：

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

感謝各位的閱讀！關(guān)于“HTTPS證書是怎么為網(wǎng)站正名的”這篇文章就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，讓大家可以學(xué)到更多知識(shí)，如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到吧！