HTTPS证书是怎么为网站正名的

这篇文章给大家分享的是有关HTTPS证书是怎么为网站正名的的内容。小编觉得挺实用的，因此分享给大家做个参考，一起跟随小编过来看看吧。

创新互联专注于中大型企业的成都网站设计、做网站和网站改版、网站营销服务，追求商业策划与数据分析、创意艺术与技术开发的融合，累计客户数千家，服务满意度达97%。帮助广大客户顺利对接上互联网浪潮，准确优选出符合自己需要的互联网运用，我们将一直专注品牌网站设计和互联网程序开发，在前进的路上，与客户一起成长！

 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 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-----之间即为一个证书，第一个必须为域名实体证书，后面的依次为中级证书或交叉证书，经测试，第一个域名实体证书顺序必须放第一个，后续中级证书可相互调换顺序，通常增加中间证书建议追加到最后面。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根证书的问题。

感谢各位的阅读！关于“HTTPS证书是怎么为网站正名的”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，让大家可以学到更多知识，如果觉得文章不错，可以把它分享出去让更多的人看到吧！

文章标题：HTTPS证书是怎么为网站正名的
文章路径：http://6mz.cn/article/josccd.html