http协议叫做超文本传输协议，他可是互联网的基石，在外面访问服务器时候。
http定义了一下规则。
请求方法：GET请求非常常见，也可以用脚本/post/put/delete等
请求头：content-type用于指示请求或响应中数据的媒体类型/user-agent请求设备/Content-Length：请求主体的字节长度。
客户端响应状态码：200/403/502等
SSL 的全称是 Secure Sockets Layer，即安全套接字层。它是一种标准协议，用于在客户端（如浏览器）和服务器之间建立加密连接，确保数据传输的安全性和完整性。
SSL 由 Netscape Communication 公司开发，主要用于以下目的：
数据加密：通过加密技术保护传输中的数据，防止被窃取或篡改。
身份验证：通过数字证书验证服务器的真实性，确保用户访问的是合法网站。（次要作用）
数据完整性：确保数据在传输过程中未被修改。
SSL 的工作原理
SSL 的核心是通过握手协议建立安全连接。以下是其主要步骤：
握手协议：客户端与服务器相互验证身份，并协商加密算法和密钥。
记录协议：在握手完成后，使用协商的密钥对数据进行加密和完整性校验。
警报协议：在发现错误时，发送警报并终止连接。
SSL 与 HTTPS 的关系
HTTPS 是基于 SSL 的安全协议，其全称为 Hypertext Transfer Protocol Secure。简单来说，HTTPS = HTTP + SSL。通过部署 SSL 证书，网站可以实现 HTTPS 加密访问，从而提升安全性。
SSL 的主要作用
保护数据传输：防止敏感信息（如密码、支付信息）被窃取或篡改。
验证网站身份：防止用户访问钓鱼网站。
提升用户信任：浏览器地址栏显示 HTTPS 和安全锁标志，增强用户对网站的信任。
有利于 SEO：搜索引擎更倾向于优先排名 HTTPS 网站。
DV证书 (Domain Validation) 和 EV证书 (Extended Validation) 的区别
DV证书 和 EV证书 都是 SSL/TLS 证书，它们的主要区别在于验证过程、信任度和用户的可见性，而不是加密技术本身。它们的加密安全性是相同的，使用的加密算法（如 RSA、ECC 等）也是一样的。
DV证书
• 验证方式：仅验证域名所有权。你需要证明你对该域名有控制权（例如通过 DNS 记录或 HTTP 文件验证）。
• 安全性：DV证书提供标准的加密保护，确保数据传输的安全，防止中间人攻击、窃听等，但它没有验证企业或个人身份。
• 适用场景：适合个人网站、小型企业博客、开发者站点等不涉及用户敏感数据（如银行信息、个人隐私等）的应用。
EV证书
• 验证方式：进行更严格的身份验证。申请者必须提供详细的公司或组织信息，CA 会对其进行背景检查，确保该组织是合法的并且具备经营资质。
• 安全性：EV证书本身在加密保护上和 DV证书没有本质区别，但它具有 身份验证 的附加保障，确保用户访问的网站是真实的公司或组织。
• 适用场景：适用于涉及用户敏感数据的应用，尤其是银行、金融机构、电子商务网站等，用户在浏览器中会看到绿色的地址栏和公司名称，进一步增强了网站的可信度。
重点：加密安全性：DV与EV证书的一致性，说白了就是你交了钱时间可以长一点，给你颁发一个绝对可信任，证明你是合法官方网站服务器，比如你买了腾讯的证书，那你就有他们腾讯颁发，加密做中间证书站出来告诉你他很正哈哈哈哈！确保该组织是合法的并且具备经营资质。就跟备案一样。
所以，从 加密保护 的角度，DV证书和EV证书是一样安全的！没有区别。
1.证书有专门的证书申请机构CA，如免费平台Let‘s Encrypt公司digicert公司等。我们需要提交CSR文件。
CSR文件一般有，网站域名，dns解析，申请IP地址，公司名称，地理位置，邮箱等还有你想要的加密算法（sha256）和准备公钥。
这是当今最常见的验证方式。 Let’s Encrypt 向您的 ACME 客户端提供一个令牌，然后您的 ACME 客户端将在您对 Web 服务器的 http://<你的域名>/.well-known/acme-challenge/<TOKEN>（用提供的令牌替换 <TOKEN>）路径上放置指定文件。 该文件包含令牌以及帐户密钥的指纹。 一旦您的 ACME 客户端告诉 Let’s Encrypt 文件已准备就绪，Let’s Encrypt 会尝试获取它（可能从多个地点进行多次尝试）。 如果我们的验证机制在您的 Web 服务器上找到了放置于正确地点的正确文件，则该验证被视为成功，您可以继续申请颁发证书。 如果验证检查失败，您将不得不再次使用新证书重新申请。
我们的 HTTP-01 验证最多接受 10 次重定向。 我们只接受目标为“http:”或“https:”且端口为 80 或 443 的重定向。 我们不目标为 IP 地址的重定向。 当被重定向到 HTTPS 链接时，我们不会验证证书是否有效（因为验证的目的是申请有效证书，所以它可能会遇到自签名或过期的证书）。
HTTP-01 验证只能使用 80 端口。 因为允许客户端指定任意端口会降低安全性，所以 ACME 标准已禁止此行为。
优点：
它可以轻松地自动化进行而不需要关于域名配置的额外知识。
它允许托管服务提供商为通过 CNAME 指向它们的域名颁发证书。
它适用于现成的 Web 服务器。
它也可以用于验证 IP 地址。
缺点：
如果您的 ISP 封锁了 80 端口，该验证将无法正常工作（这种情况很少见，但一些住宅 ISP 会这么做）。
Let’s Encrypt 不允许您使用此验证方式来颁发通配符证书。
您如果有多个 Web 服务器，则必须确保该文件在所有这些服务器上都可用。
此验证方式要求您在该域名下的 TXT 记录中放置特定值来证明您控制域名的 DNS 系统。 该配置比 HTTP-01 略困难，但可以在某些 HTTP-01 不可用的情况下工作。 它还允许您颁发通配符证书。 在 Let’s Encrypt 为您的 ACME 客户端提供令牌后，您的客户端将创建从该令牌和您的帐户密钥派生的 TXT 记录，并将该记录放在 _acme-challenge.<YOUR_DOMAIN> 下。 然后 Let’s Encrypt 将向 DNS 系统查询该记录。 如果找到匹配项，您就可以继续颁发证书！
由于 Let’s Encrypt 在查找用于 DNS-01 验证的 TXT 记录时遵循 DNS 标准，因此您可以使用 CNAME 记录或 NS 记录将验证工作委派给其他 DNS 区域。 这可以用于将 _acme-challenge 子域名委派给验证专用的服务器或区域。 如果您的 DNS 提供商更新速度很慢，那么您也可以使用此方法把验证工作委派给更新速度更快的服务器。
大多数 DNS 提供商都有一个“更新时间”，它反映了从更新 DNS 记录到其在所有服务器上都可用所需的时间。 这个时间可能很难测量，因为这些提供商通常也使用任播，这意味着多个服务器可以拥有相同的 IP 地址，并且根据您在世界上的位置，您和 Let’s Encrypt 可能会与不同的服务器通信（并获得不同的应答）。 最好的情况是 DNS API 为您提供了自动检查更新是否完成的方法。 如果您的 DNS 提供商没有这样的方法，您只需将客户端配置为等待足够长的时间（通常多达一个小时），以确保在触发验证之前更新已经完全完成。
您可以为同一名称提供多个 TXT 记录。 例如，如果您同时验证通配符和非通配符证书，那么这种情况可能会发生。 但是，您应该确保清理旧的 TXT 记录，因为如果响应大小太大，Let’s Encrypt 将拒绝该记录。
优点：
您可以使用此验证方式来颁发包含通配符域名的证书。
即使您有多个 Web 服务器，它也能正常工作。
即使服务器不对公网开放，您也可以通过此方式验证其域名。
缺点：
在 Web 服务器上保留 API 凭据存在风险。
您的 DNS 提供商可能不提供 API。
您的 DNS API 可能无法提供有关更新时间的信息。
IP 地址不能通过此方式验证。
这一验证类型是在 TLS-SNI-01 被弃用后开发的， 与 TLS-SNI-01 一样，它通过 443 端口上的 TLS 执行。 但是，它使用自定义的 ALPN 协议来确保只有知道此验证类型的服务器才会响应验证请求。 这还允许对此质询类型的验证请求使用与要验证的域名匹配的SNI字段，从而使其更安全。
这一验证类型并不适合大多数人。 它最适合那些想要执行类似于 HTTP-01 的基于主机的验证，但希望它完全在 TLS 层进行以分离关注点的 TLS 反向代理的作者。 目前这一群体主要是大型的网站托管服务商。
优点：
它在 80 端口不可用时仍可以正常工作。
它可以完全仅在 TLS 层执行。
它也可以用于验证 IP 地址。
缺点：
ACME 客户端对这种方式的支持较为有限。
与 HTTP-01 一样，如果您有多台服务器，则它们需要使用相同的内容进行应答。
此方法不能用于验证通配符域名。
ACME 的草案版本中定义了这一验证方式。 其原理是与 443 端口执行 TLS 握手时使用特殊的 SNI 字段，并验证证书是否包含特定信息。 这种方式不够安全，因此已于 2019 年 3 月被废除。
2.CA对网站进行检查，提交文件是否为正确的。如果没问题会颁发一个证书。
3.服务器接收到CA办法的证书，将证书部署上即可。
现在你已经有一个网站，有服务器，做好了dns解析，部署了ssl证书开启https。
在 SSL/TLS 加密中，公钥 和 私钥 是一对密钥，分别用来加密和解密信息。它们是 非对称加密的基础，意思是用一个公密钥加密的信息只能用另一个密钥解密
• 公钥：公开给所有人的密钥，用于加密数据。任何人都可以使用你的公钥来加密数据，但只有拥有 私钥 的人才能解密。
• 私钥：只有证书所有者（网站服务器）拥有的密钥，用于解密由公钥加密的数据，并用于签名数据。
SSL/TLS（即 Secure Sockets Layer / Transport Layer Security）协议用于加密客户端（通常是浏览器）与服务器之间的通信。下面是一个常见的 SSL 握手（SSL Handshake）流程，重点说明公钥和私钥如何在其中起作用：
1. 客户端发起请求
• 当你访问一个网站时，浏览器（客户端）会向服务器发起一个 SSL 握手 请求。此时，浏览器和服务器之间尚未建立加密通道。
2. 服务器响应并发送证书
• 服务器收到客户端请求后，返回一个 SSL 证书。证书中包含了 服务器的公钥 和证书颁发机构（CA）签发的其他信息，如：
• 证书持有者（服务器）信息
• 证书有效期
• 公钥
• 由 CA 签名的证书链
3. 客户端验证证书
• 客户端（浏览器）收到服务器的证书后，会验证证书的有效性：（通过哈希值计算解密证书内容）
• 检查证书是否在有效期内。
• 验证证书是否由受信任的 CA 签发。
• 验证证书的域名是否与访问的域名匹配（即域名验证）。
• 如果证书验证成功，客户端信任该服务器的公钥，继续进行后续步骤。如果证书无效或被篡改，浏览器会提示用户风险。
4. 客户端生加密数据
• 客户端对信任的公钥匙在加上自己的数据和算法，对数据加密并传送服务器
• 客户端自己通过公钥生成会话密钥
• 由于只有服务器有 私钥，因此只有对应服务器可以解密这个密钥。
5. 客户端发送加密的预主密钥
• 客户端将加密后的预主密钥（经过公钥加密的乱码）发送给服务器。
6. 服务器解密并生成对称密钥
• 服务器使用 私钥 解密客户端发送的加密的预主密钥。
• 一旦服务器解密了预主密钥，它和客户端都可以基于这个预主密钥生成一个 对称密钥（也叫会话密钥）。对称密钥是加密和解密数据的“共享密钥”，这将是后续通信中使用的密钥（对称加密）。
7. 客户端和服务器使用对称密钥加密数据
• 之后，客户端和服务器之间的所有通信都将使用 对称加密（例如 AES、DES 等）来进行数据加密和解密。对称加密的优势是加密速度更快，适合大量数据的传输。
• 由于对称加密需要双方共享相同的密钥，所以它们使用之前生成的预主密钥来协商出该密钥。
8. 数据交换和验证
• 双方确认密钥交换成功后，开始通过加密的连接进行数据传输。
• 在每次数据传输时，双方都会使用 会话密钥 对数据进行加密，以保证数据的机密性。
• 同时，客户端和服务器会对每一条传输的数据进行 完整性检查，确保数据在传输过程中没有被篡改（通常使用哈希算法，如 SHA-256）。
9. 通信结束
• 当通信结束时，SSL/TLS 会话终止。双方可以选择销毁会话密钥
总结，tls通过非对称加密公钥和私钥生成对称加密密钥（会话密钥）来完成安全的解密，用来防止会话密钥被传改劫持等。
因为非对称加密是不可逆的，确保生产会话私钥安全。
用完后需要重新生成建立tcp握手关系。
流程图如下：
https协议通过dns运营商颁发证书，来确定你的服务器上是真实的，不是黑客私自生产的假证书。来充当公钥。这样就解决了中间人劫持攻击的风险，建成CA数字证书（公钥私钥）
最后温馨提示，为了你的安全和防止ssl劫持，请使用tls1.2及以后的版本哦！
