HTTPS解决什么问题HTTPS解决两个问题：加密传输保证客户端和服务器之间的信息不是明文传输，确保信息的保密性身份认证HTTPS协议可以证明服务器的身份，防止假网站冒充自己。这部分对称加密算法需要有密码学基础，本段只做相关总结。因为对称加密只有一个密钥，存在密钥被枚举的问题，加密安全性不够高。常见的对称加密有DES、3DES、AES，因为其性能高于非对称加密，所以被用在HTTPS内容加密中。HTTPS使用非对称加密算法进行密钥协商，生成用于页面内容对称加密的密钥。非对称加密算法常见的非对称加密算法都是基于数学问题，在目前的计算能力下很难破解。常见的算法有RSA、ECC等。抽象出几个名词概念：公钥、私钥。公钥和私钥可以通过数学计算相互计算和验证明文和密文。加密：通过公钥（或私钥）计算出明文（如RSA），生成密文解密：通过另一个密钥计算出密文，生成明文上面的加密和解密的概念是相对的。在日常应用中，常见两种场景：发送方用接收方的公钥加密明文，接收方用自己的私钥解密。在需要身份认证的场景下，使用自己的私钥对待签名内容进行电子签名。当需要验证时，验证者获取签名者的公钥进行验证（公钥对密文进行数学计算和解密）非对称加密算法的场景——身份认证和PKI身份认证上一节是数字签名，数字签名是身份认证的方法。因为你自己的私钥是别人不知道的，别人无法复制，就像人的指纹一样，可以代表你自己。但是问题来了？我希望有人持有我的公钥以便与我进行加密通信。对方怎么知道这是我的公钥呢？我怎么证明我是我？要证明我是我，只能拿着自己去派出所查身份证，然后请官方出具“身份证明”，因为相关部门是可信的，所以如果官方这么说是合法的，可以证明这是我。那么电子世界有这样的官方机构吗？是的！PKI基础设施PKI是安全世界的基础设施，CA组织是其主要成员。CA组织向申请的用户颁发证书，证明“我就是我”，用户通过验证证书的有效性来判断是否是自己需要通信的对方。当然，CA是一个营利机构。一个企业要申请一个证明“我就是我”的证书，需要花费大量资金。信息确认签名+指纹证书签发流程大致分为：申请人生成CSR，申请时填写公司主体身份信息，生成CSR和私钥。CSR的内容相当于公钥和身份信息。选择一个CA证书颁发机构，如Amazon、Globalsign或免费机构提交CSR。CA将验证公司的主要信息。如果没有问题，它将对申请者提交的CSR进行签名，并生成一个公钥，该公钥可以被Web服务器部署并发送给申请者。可见，在受信任的官方CA机构颁发的情况下，大家看到这张证书就可以认为这是你。客户端内置了一个可信组织的根证书，所以这个官方组织是被认可的，在后面的信任链部分会详细介绍。但是问题又来了。HTTPS越来越多，发证机构忙不过来怎么办？国与国之间的语言沟通障碍呢？就像在现实世界中，官方机构会授权子公司或总公司开设新的分支机构，同时CA机构也会因此增加自己的分支机构，由此产生了中间证书和交叉证书的概念。中间证书：不使用根证书的私钥对申请人的CSR进行签名，而是使用中间证书对申请人的CSR进行签名来颁发证书。交叉证书：不同根证书之间的相互签名，改变了信任起点trustchain和trustanchor由于采用了中间证书，整个证书有效性验证过程有了信任链的概念。信任链是客户端从服务器实体证书开始一步步验证。每一级证书验证过程得到证书颁发者（Issuer）证书中的公钥（证书=用户公钥+公司名称等主体信息+CA的确认签名+指纹）对当前证书的签名进行数学验证级证书（Subject），验证成功即证书有效。整个逐级验证向上，形成信任链。直到一个证书的颁发者和使用者是同一个人，这个点就是信任锚，也就是信任链的起点。起点需要在客户端系统或浏览器的根证书信任列表中。整个过程完成后，证书可信。PS：不同浏览器（客户端）的可信根证书列表不同。Chrome读取系统中的根证书列表，而FireFox浏览器使用其浏览器内置的受信任根证书列表。Nginx部署证书及验证分析Nginx服务器证书部署使用base64编码格式的证书。CA颁发证书后，会得到一个base64格式的证书，连同私钥一起部署到服务器上。sslon;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-----BEGINCERTIFICATE-----MIIFpjCCBI6gAwIBAgIQBjLXXyMcU5DDZQ7gshcXdTANBgkqhkiG9w0BAQsFADByMQswCQYDVQQGEwJDTjElMCMGA1UEChMcVHJ1c3RBc2lhIFRlY2hub2xvZ2llcywgSW5jLjEdMBsGA1UECxMURG9tYWluIFZhbGlkYXRlZCBTU0wxHTAbBgNVBAMTFFRydXN0QXNpYSBUTFMgUlNBIENBMB4XDTE5MDgxNjAwMDAwMFoXDTIwMDgxNTEyMDAwMFowFjEUMBIGA1UEAxMLMHhmZS5jb20uY24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDcNNv3Ap4P+LRHrPHPWwuHHZhexQiSCPBAba/kSAcXjFAxaI7oNdyiuBmUhPoGeV3YvIpzV9nsgcar94yDWef/L6Dl5SpVlHYYudgDwa+MKibhPGaLncW3urpPok3LFngSz63n2xg77Of4gEcOOeMPdzUb9UT6tKrZlPKXRjrGXKbLTwTjAQo4MhvmS8ZddmaRjCTSxhJrZ8n4W2YfgBjITZEqNDDQyhxkS5Sr8/8OQ8wfn38crrd6FMAgnjnEZZVi3ivd4+XEz+g/DNE/m7+8cmRuHfG8ELXjGnswquJstgllNyUlqumW3dfE9YVIJlQkvEQWFMsw5dzxHidJWTFLAgMBAAGjggKSMIICjjAfBgNVHSMEGDAWgBR/05nzoEcOMQBWViKOt8ye3coBijAdBgNVHQ4EFgQUlKhM50RH3AC7pIcyqEoULdttwXUwJwYDVR0RBCAwHoILMHhmZS5jb20uY26CD3d3dy4weGZlLmNvbS5jbjAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMEwGA1UdIARFMEMwNwYJYIZIAYb9bAECMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwCAYGZ4EMAQIBMIGSBggrBgEFBQcBAQSBhTCBgjA0BggrBgEFBQcwAYYoaHR0cDovL3N0YXR1c2UuZGlnaXRhbGNlcnR2YWxpZGF0aW9uLmNvbTBKBggrBgEFBQcwAoY+aHR0cDovL2NhY2VydHMuZGlnaXRhbGNlcnR2YWxpZGF0aW9uLmNvbS9UcnVzdEFzaWFUTFNSU0FDQS5jcnQwCQYDVR0TBAIwADCCAQQGCisGAQQB1nkCBAIEgfUEgfIA8AB2AO5Lvbd1zmC64UJpH6vhnmajD35fsHLYgwDEe4l6qP3LAAABbJg76VwAAAQDAEcwRQIhAO5fxTuzbUnz6fna1BAyOzzAxoSwN1xo0lnXrMr2bVBrAiAe2PWp7rCX0eMzO+ZdICzFwQtcULLHSGehHv8CgMqbNQB2AId1v+dZfPiMQ5lfvfNu/1aNR1Y2/0q1YMG06v9eoIMPAAABbJg76eAAAAQDAEcwRQIhAItx6WPv2a2nKIBRVDuvns5D4fElzlPAHMVM9gKDA4HcAiB/D+n/UCFAH5YYL6r+vLKgLRJCfq5Vw0kaLWA+P3a5RDANBgkqhkiG9w0BAQsFAAOCAQEAllOZKfyYhoyC5/FRnEhoY/6v/kbzPlVsgZvUVtk3IDnyo7GOaUUigQaLSmL0oWTnwmMOweb7UhP1TL+RCYcw2fc39l4FIaOKjMmSaPLZw2Fm9Lk/ie5BZ3pLD5A3exz4nMgVjJB6X??C0ZiBgTsCOl3K3vFefL4x4ewoR0KwN5fTwkxKKT7XUCMTcIOMgWX2ubUXhjM2cyc9lRPTy2joO4za9AS6sR5JExLY/kJ3dR7t99gko5MnJZINcPD8WIUySw5oQZA22YOhFVBGiERcH+oD6TNoZuqu2pSfrAIFT3dWpb1bGgiCxblsN2yH1REXmnTx3bmuy2UAXfwUlUhtmRbw==-----ENDCERTIFICATE----------BEGINCERTIFICATE-----MIIErjCCA5agAwIBAgIQBYAmfwbylVM0jhwYWl7uLjANBgkqhkiG9w0BAQsFADBhMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSAwHgYDVQQDExdEaWdpQ2VydCBHbG9iYWwgUm9vdCBDQTAeFw0xNzEyMDgxMjI4MjZaFw0yNzEyMDgxMjI4MjZaMHIxCzAJBgNVBAYTAkNOMSUwIwYDVQQKExxUcnVzdEFzaWEgVGVjaG5vbG9naWVzLCBJbmMuMR0wGwYDVQQLExREb21haW4gVmFsaWRhdGVkIFNTTDEdMBsGA1UEAxMUVHJ1c3RBc2lhIFRMUyBSU0EgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCgWa9X+ph+wAm8Yh1Fk1MjKbQ5QwBOOKVaZR/OfCh+F6f93u7vZHGcUU/lvVGgUQnbzJhR1UV2epJae+m7cxnXIKdD0/VS9btAgwJszGFvwoqXeaCqFoP71wPmXjjUwLT70+qvX4hdyYfOJcjeTz5QKtg8zQwxaK9x4JT9CoOmoVdVhEBAiD3DwR5fFgOHDwwGxdJWVBvktnoAzjdTLXDdbSVC5jZ0u8oq9BiTDv7jAlsB5F8aZgvSZDOQeFrwaOTbKWSEInEhnchKZTD1dz6aBlk1xGEI5PZWAnVAba/ofH33ktymaTDsE6xRDnW97pDkimCRak6CEbfe3dXw6OV5AgMBAAGjggFPMIIBSzAdBgNVHQ4EFgQUf9OZ86BHDjEAVlYijrfMnt3KAYowHwYDVR0jBBgwFoAUA95QNVbRTLtm8KPiGxvDl7I90VUwDgYDVR0PAQH/BA??QDAgGGMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjASBgNVHRMBAf8ECDAGAQH/AgEAMDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEIGA1UdHwQ7MDkwN6A1oDOGMWh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEdsb2JhbFJvb3RDQS5jcmwwTAYDVR0gBEUwQzA3BglghkgBhv1sAQIwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzAIBgZngQwBAgEwDQYJKoZIhvcNAQELBQADggEBAK3dVOj5dlv4MzK2i233lDYvyJ3slFY2X2HKTYGte8nbK6i5/fsDImMYihAkp6VaNY/en8WZ5qcrQPVLuJrJDSXT04NnMeZOQDUoj/NHAmdfCBB/h1bZ5OGK6Sf1h5Yx/5wR4f3TUoPgGlnU7EuPISLNdMRiDrXntcImDAiRvkh5GJuH4YCVE6XEntqaNIgGkRwxKSgnU3Id3iuFbW9FUQ9Qqtb1GX91AJ7i4153TikGgYCdwYkBURD8gSVe8OAco6IfZOYt/TEwii1Ivi1CqnuUlWpsF1LdQNIdfbW3TSe0BhQa7ifbVIfvPWHYOu3rkg1ZeMo6XRU9B4n5VyJYRmE=-----ENDCERTIFICATE-----cat/opt/soft/ssl/0xfe.com.cn_key.key-----BEGINRSAPRIVATEKEY-----省略-----ENDRSAPRIVATEKEY-----公钥文件中，在-----BEGINCERTIFICATE-----和-----ENDCERTIFICATE-----之间为证书，第一的首先必须是域名实体证书，然后是中间证书或交叉证书。经过测试，第一个域名实体证书必须排在最前面，后面的中间证书可以互相交换。通常建议在最后添加中间证书。CER在线阅读工具将上述第一段输入在线阅读工具，输出如下：CER解码结果：通用名：0xfe.com.cn可用域名：DNS：0xfe.com.cn，DNS：www.0xfe.com.cn有效期：2019-08-16-2020-08-15序号：8239351073242680476627775209099171701发行人：TrustAsiaTLSRSACA有效期：2020-08-1520:00:00将以上第二段输入在线阅读工具，输出CER解码结果如下：通用名称：TrustAsiaTLSRSACA公司组织名称：TrustAsiaTechnologies,Inc.有效期：2017-12-08-2027-12-08序列号：7311534772508790650765434802415791662颁发机构：DigiCertGlobalRootCA有效期：2027-282-02:26上面可以看出，两端的base64证书分别对应域名实体证书和中间证书。上述证书的信任链为：0xfe.com.cn<----Verification----TrustAsiaTLSRSACA<----Verification----DigiCertGlobalRootCA（存在于系统或浏览器中）客户端通过TrustAsiaTLSRSACA证书中的公钥验证0xfe.com.cn证书中的签名，客户端通过DigiCert全球根CA证书中的公钥验证TrustAsiaTLSRSACA证书中的签名，通过。上面的DigiCertGlobalRootCA称为根证书。为了验证上述过程，可以禁用系统的根证书。下图禁用DigiCertGlobalRootCA并将其标记为不受信任。可以看到浏览器将0xfe.com.cn标记为不可信。百度网站证书分析实例可知，百度证书验证信任链为：baidu.com<--verification--GlobalSignOrganizationValidationCA-SHA256-G2<--verification--GlobalSignRootCA（存在于系统或浏览器中）客户端通过GlobalSignOrganizationValidationCA-SHA256-G2证书中的公钥验证baidu.com证书中的签名；客户端通过GlobalSign根CA证书中的公钥验证GlobalSignOrganizationValidationCA-SHA256-G2证书中的签名已签名，已批准。上面的GlobalSignRootCA称为根证书。使用GlobalSignCA交叉证书更改信任锚MAC。最新内置的GlobalSignCA有5个：组织单元叫做：RootCAGlobalSignRootCA-R2GlobalSignECCRootCA-R5GlobalSignECCRootCA-R4GlobalSignRootCA-R3是R1到R5，在FireFox浏览器里有R6，也就是说Gloabalsign一共有这些根证书在使用。以下场景需要使用交叉证书：当GlobalSign启用根CA颁发证书时，客户端可能没有时间更新根CA。例如客户端只有R1到R3三个根证书，缺少其他几个根证书。.这时，较新的根证书如R4签发的域名证书会被客户端标记为不安全。此时，GlobalSign将提供一个交叉证书，将信任锚从较新的CA根证书（如R4）指向客户端现有的根证书R1，解决客户端无法访问的问题。下面将用一个例子来形象地表示这个场景：baidu.com<----Verification----GlobalSignOrganizationValidationCA-SHA256-G2<----Verification----GlobalSignRootCA-R4（GlobalSignRootCA-R4不存在在客户端）GlobalSignRootCA-R4不存在于客户端的信任根证书列表中，因此信任链不完整，无法正常访问。不重发中间证书如何解决GlobalSignOrganizationValidationCA-SHA256-G2终端问题呢？根据上面的分析，只需要在Nginx服务器的公钥文件后面加上交叉证书的base64编码版本即可。此时信任链会增加一个新的层次，信任锚点将从R4根证书转移到R1根证书。部署nginx时，添加交叉证书并更改信任锚。修改后的信任链为：baidu.com<----verification----GlobalSignOrganizationValidationCA-SHA256-G2<----verification----R1-R4cross-certificate<----verification----RootCA（RootCA为GlobalSignRootCAR1，存在于系统中）使用R1-R4交叉证书对GlobalSignOrganizationValidationCA-SHA256-G2进行签名验证，使用RootCA对R1-R4交叉证书进行签名验证，传递信任从R4根证书到R1根证书的锚点。系统中存在R1根证书，可以解决较新的CA根证书颁发的证书不可信任的问题。备注：GlobalSign于2019年5月27日迁移了颁发SSL证书的中间CA，使用RSA算法密钥的OVSSL证书将在新的中间CA下颁发，与GlobalSignR3根证书链接。如果使用该算法颁发证书，请在系统中保留R3根证书，之前颁发的证书中的中间证书链在GlobalSignR1根证书下。变化如下图所示：变化前，中间证书链接到R1根证书：变化后，中间证书链接到R3根证书：使用GlobalSignCA的用户要注意改变的影响，可以在证书文件中添加GlobalSignR1R3交叉证书来解决问题客户端的R3根证书没有问题。
