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格式的证书，和私钥一起部署在服务器中。
1 | ssl on; |
0xfe.com.cn_chain.crt为公钥文件，0xfe.com.cn_key.key为私钥文件。
1 | cat /opt/soft/ssl/0xfe.com.cn_chain.crt |
1 | cat /opt/soft/ssl/0xfe.com.cn_key.key |
公钥文件中，-----BEGIN CERTIFICATE-----和-----END CERTIFICATE-----之间即为一个证书，第一个必须为域名实体证书，后面的依次为中级证书或交叉证书，经测试，第一个域名实体证书顺序必须放第一个，后续中级证书可相互调换顺序，通常增加中间证书建议追加到最后面。
CER在线读取工具
将上述第一段输入到在线读取工具中，输出如下：
1 | CER解码结果： |
将上述第二段输入到在线读取工具中，输出如下：
1 | CER解码结果： |
可见上述，两端base64证书分别对应域名实体证书和中级证书。
1 | 上述证书信任链为： |
客户端通过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个:
组织单位分别称为：
1 | Root CA |
即R1到R5，FireFox浏览器中还存在R6
也就是说Gloabalsign一共有这些根证书在使用。
存在以下场景需使用交叉证书：
GlobalSign在根CA启用颁发证书的过程中，会出现客户端没有来得及更新根CA的情况，如客户端只存在R1到R3三个根证书，缺少其他几个根证书，这个时候使用较新根证书如R4颁发的域名证书会被客户端标记为不安全，这时候GlobalSign会提供交叉证书，将信任锚从较新CA根证书如R4指向到客户端存在的根证书R1上，解决客户端无法访问的问题。
下面将用一个例子直观的表示这个场景：
1 | 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时增加一段交叉证书，改变信任锚，修改后的信任链将为：
1 | 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根证书的问题。
支付宝打赏
微信打赏
赞赏支持一下
