白话 HTTPS

最近研究了一番 https 的知识，总结如下，为了更好的让零基础用户理解，下面用最直白的话描述，可能不够严谨，但能帮助理解。

水平有限，不足之处，还请高手多多指点！

在早期，客户端（这里指浏览器）和服务器之间（这里指 http 服务器）传输数据是明文传输的，这就是 http 协议。这有个缺点，任何人都可以通过抓包拦截网络传输中的数据包，甚至拦截后重发，这很不安全。

后来有聪明的人提出了加密，所谓加密就是通过一个密钥（通常是一个密码一样的字符串，通常由浏览器生成），然后通过某种算法对数据进行打乱，只有知道密钥的人才能解密这段数据，这通常叫做对称加密。

但，又有聪明的人提出了，想法很好，但你的密钥怎么告诉服务器，密钥传输中也可能被拦截，这样，别也知道你的秘钥了，加密还有什么用。

这就很尴尬了，后来又有一个更聪明的人，提出了一种加密算法，就是秘钥不是有一个，而是两个，一个加密，另一个解密，这两个秘钥通常称为公钥和私钥，而这种加密方式称为非对称加密，通常公钥用于加密，私钥用于解密，但在签名场景则通常私钥加密消息摘要，生成签名，而公钥解密签名，获取消息摘要。总之，有了这种加密算法，就可以用这种加密算法把对称加密密钥进行加密后再传给服务器，这样就解决了对称密钥被窃取的风险。

但问题又来了，怎么把私钥和公钥传给服务器或者说两者该怎么协商呢，仍然没能解决上面说的秘钥被拦截问题，而浏览器也不是针对一家服务器，不可能事先与你协商秘钥。

后来，又有大聪明提出了一个想法，通过第三方机构，没错，这个有点像支付宝担保支付，找一家大家都信任的第三方进行担保，这就是所谓的第三方证书颁发机构，那么这个颁发的证书中包含了一系列信息，包括个人或组织信息，域名，第三方机构等信息，当然也包含公钥，这就是所谓的安全证书。

当你想搭建一个 https 的网站时，你先要去第三方机构去申请安全证书（通常通过证书颁发网站申请），申请前先用 OpenSSL 生成私钥，然后用这个私钥生成 CSR，CRS 中包含公钥以及关于您的域名、组织信息等，然后把 CSR 发给颁发证书网站，然后安全证书网站会对你的个人或组织信息及域名等进行验证，验证通过后，会生成一个安全证书给你，证书中包含证书公钥和 CA 签名（签名主要为了防止证书被篡改）。注意，有些第三方机构（比如某云平台）为了降低用户使用难度可能会自动帮你生成 CSR 文件，你只需要填写资料申请，验证域名，颁发，下载证书相关文件即可。这个相关文件是因为下载的文件里包含了证书和私钥，没错，云平台帮你生成了私钥，严格意义上说这不够安全，当然，一般这个文件通常只有用户自己的账号才能访问，相对是安全的，要说不安全那你的文件还放在平台呢。

然后，你需要把证书（通常是 crt 文件）和私钥（通常是 key 文件）放到服务器，并在 http 服务器中进行配置，这样，当浏览器请求你的网站时，服务器会把证书及证书公钥发送给浏览器。浏览器拿到证书后，会做两件事，第一，根据证书去验证证书的可靠性，包括机构是否受信任，证书是否过期，是否和域名匹配等，第二件事，如果第一件事验证通过，则随机生成一个对称加密的密钥，然后用证书公钥进行加密，然后发送给服务器，由于这个密钥被非对称加密了，除了拥有证书私钥的人（即服务器外），无人能解密，这样就保证了传输的安全性。

然后，服务器收到浏览器发送过来的密钥后，通过证书私钥进行解密，然后就拿到对称密钥了。然后服务器发送数据给浏览器时就可以通过这个对称密钥进行加密了，而浏览器也可以通过这个密钥进行解密，自己发过去的密钥自己自然知道了。这样就保证了数据传输过程中的安全。

有时你也可能或见到 .p12 文件，它包含了证书和私钥，通常会使用密码进行加密，以增加安全性。这意味着需要提供密码才能从中提取证书和私钥。这种格式的文件通常用于需要将证书和私钥一起打包和分发的场景，例如移动应用开发、桌面应用程序配置等。

下面是 https 验证过程示意图

问题列表：

1. 浏览器是怎么验证证书是可靠的呢？

   浏览器预先安装一系列受信任机构的根证书，这些根证书是颁发机构自己生成的用于验证自己身份的证书。当你向颁发机构申请证书时，颁发机构会用根证书或中间证书（由根证书直接或间接签名的证书）给你的证书进行签名。而当浏览器访问您的网站时，它会检查你的证书是否由一个已知的、受信任的根证书所签名。这样就形成了一条信任链，从最终用户证书到中间证书再到根证书。

2. 什么是签名？什么是验签？消息摘要为什么加密？

   签名是防止数据被篡改的手段。比如，你需要给浏览器发送数据，在发送前，你先通过 hash 算法，给你的数据生成消息摘要（消息摘要就是把数据生成固定长度的字符串，每次生成都一样），然后用私钥给消息摘要进行加密，生成签名，发送时，把数据和签名及公钥一起发送，浏览器拿到这些数据后，通过公钥对签名进行解密，获取消息摘要，然后再通过对数据进行生成消息摘要，然后对比这两者的消息摘要是否一致，来确认数据是否被篡改。

   这里细心的朋友发现，这公钥是公开的，任何人都可以解密签名获取摘要，还有什么用？这里主要是消息摘要加密后，即使窃取者解密了，但他无法篡改数据，因为篡改了数据后，窃取方没有私钥，无法生成新的签名，如果附加假的签名或用原签名，验签都无法通过。而如果摘要不加密，那么窃取者可以篡改数据，并附加新的摘要，而接收方无法知道数据是否被篡改，以及是否发送方发送的数据，无法保证数据的安全。

3. 我可以自己生成根证书吗？

   是的，你可以通过 OpenSSL 给自己生成根证书，然后再给服务器生成证书，然后用你的根证书签名，然后把根证书导入浏览器即可。

4. 既然公钥和私钥都可以加密解密，公钥和私钥可以互换吗？比如私钥公开，公钥保密。

   不可以互换，因为私钥可以生成公钥，如果私钥公开，那么别人通过私钥可以生成公钥，因为私钥和公钥一一对应的，多次生成公钥的结果是一样的，这样就相当于你公钥和私钥都公开了。

5. 既然公钥和私钥可以加密解密了，传输数据为什么不用公钥和私钥加密，还加个对称加密干嘛？

   因为性能问题，对称加密性能更高，这样既保证了数据的安全传输，又不会因为加密过程而大幅增加计算负担。

6. 对称加密和非对称加密算法有哪些？

对称加密算法
    DES (Data Encryption Standard)
    AES (Advanced Encryption Standard)
    3DES (Triple DES)
    RC4 (Rivest Cipher 4)
    Blowfish
非对称加密算法
    RSA (Rivest-Shamir-Adleman)
    DSA (Digital Signature Algorithm)
    Diffie-Hellman Key Exchange
    ECC (Elliptic Curve Cryptography)

7. 关于公钥和私钥和数字证书之间的关系补充

有人说私钥里已包含公钥的说法是错误的，而是私钥和公钥之间在一种数学上的关系，使得可以从私钥计算出公钥，注意，这里是计算，并不是私钥中包含公钥。

当你生成一对非对称密钥时，通常是从随机数产生私钥，然后利用该私钥以及特定的算法（如 RSA、ECC 等）来计算出对应的公钥。这个过程是单向的，意味着可以从私钥计算出公钥，但反过来则不行。

所以，知道私钥可以很容易地计算出公钥，但反过来却非常困难（理论上说是不可能的）。

另外，有网友说，ca 颁发的私钥里已包含公钥，这种描述也是不准确的，应该是 ca 颁发的数字证书里已包含公钥，实际上，私钥和公钥都应该由用户自己生成，CA 不会直接发放私钥，而是验证用户的身份后为其生成的公钥签发数字证书。用户自己保留私钥，而公钥则被包含在数字证书中，并由 CA 签名确认其有效性。所以，这里的公钥和私钥都是用户自己生成的，数字证书里的公钥是用户通过 CSR 文件上传给 ca 机构的。

不过，像某某云，他们为了让用户更易操作，只需填写资料并验证域名后，会自动为用户生成私钥及数字证书，然后下载下来。但这并不是私匙里已包含公匙，私钥里并不包含私钥，而是存在一定的数学关系，可以计算出公钥，更不可能直接从中提取。

而数字证书中却包含有公钥，可以提取出来。

比如：数字证书中包含如下信息等

证书持有人信息：包括姓名、组织名称、所在城市、国家代码等。
公钥：与证书持有人关联的公钥。
有效期：证书的有效开始和结束日期。
颁发者信息：证书颁发机构的名称。
数字签名：使用颁发者的私钥对证书内容进行加密的数字签名，以确保证书的完整性和真实性。
另外，这里多说一句，数字证书和 ca 证书是不一样的，简单来说 ca 证书是 ca 机构颁发给自己的，用于证明自己的身份，浏览器中预装的是 ca 证书（ca 根证书）。而数字证书是颁发给用户的，广泛应用于各种场景，包括网站服务器、电子邮件、软件签名等，以证明持有者身份和公钥的所有权。

一般数字的证书验证过程是从用户证书到中间 ca 证书到根 ca 证书。

因为，一般用户的证书都不会直接由根 ca 机构颁发，大多数是中间 ca 机构颁发，那么，对于大多数证书验证过程，是从最终用户证书 -》中间 CA 证书 -》根 CA 证书，这样就构成了一条信任链，因为这些证书都被根证书直接或间接的签了名，形象点说就是官方已认证盖章。

本作品采用《CC 协议》，转载必须注明作者和本文链接