SSL证书验证原理和https加密

爱被打了一巴掌 2024-04-01 11:57 71阅读 0赞

### 1、首先了解一下数字证书： ###

它有点像身份证，是由权威的CA机构颁发的，证书的主要内容有：公钥（Public Key）、ISSUER（证书的发布机构）、Subject（证书持有者）、证书有效期、签名算法、指纹及指纹算法。

例如csdn的CA证书内容：

![e605eabec4ae4020b160fbe360771707.jpeg][]

可以看到公钥是一串很长的2048 Bits的字符串，同时也可以看到<使用者>的内容包含了csdn.net网址，这个网址是CSDN唯一拥有的，后面验证链接url是否正确的时候用到，还有颁发者、有效期、签名哈希算法等等。当然还有指纹及指纹算法等其他内容，我们滚动到下面看看另外一个截图：

![8ca61aad685c4b7e9ddf9b9f1a5309ad.jpeg][]

上面是CSDN网站CA证书，颁发者是GeoTrust，它就是权威的CA机构之一。到这里特别说明一下，CA机构除了给别人颁发证书以外，它也有自己的证书，为了区分我们称它为根证书，根证书也有自己的公钥和私钥，我们称之为根公钥和根私钥。然后根公钥和加密算法是向外公布的，而根私钥是机构自己绝对保密的。这个根证书在验证证书的过程中起着核心的作用。

**1.1）什么是自签名 SSL 证书？**

SSL 证书包含以下信息：

*  针对其颁发证书的域名
 *  证书颁发给哪一个人、组织或设备
 *  证书由哪一证书颁发机构颁发
 *  证书颁发机构的数字签名
 *  关联的子域
 *  证书的颁发日期
 *  证书的到期日期
 *  公钥（私钥为保密状态）

从技术上讲，任何人都可以通过生成公私钥对，并包括上述所有信息来创建自己的 SSL 证书。此类证书称为自签名证书，因为使用的数字签名将是网站自己的私钥，而不是来自 CA。

但若使用自签名证书，就没有外部权威来验证源站服务器是否是它声称的身份。浏览器认为自签名证书不可信，并且尽管使用了 https:// URL，但可能仍然将站点标记为“不安全”。它们也可能会完全终止连接，从而阻止网站加载。

#### **1.2）创建自签证书** ####

**1）SSL使用证书来创建安全连接。有两种验证模式：**

*  仅客户端验证服务器的证书，客户端自己不提供证书；（单向认证）
 *  客户端和服务器都互相验证对方的证书。（双向认证）

显然第二种方式安全性更高，一般用网上银行会这么搞，但是，普通的Web网站只能采用第一种方式。

客户端如何验证服务器的证书呢？服务器自己的证书必须经过某“权威”证书的签名，而这个“权威”证书又可能经过更权威的证书签名，这么一级一级追溯上去，最顶层那个最权威的证书就称为根证书。根证书直接内置在浏览器中，这样，浏览器就可以利用自己自带的根证书去验证某个服务器的证书是否有效。

如果要提供一个有效的证书，服务器的证书必须从VeriSign这样的证书颁发机构签名，这样，浏览器就可以验证通过，否则，浏览器给出一个证书无效的警告。申请一个证书签名的费用是一年几十~几百刀不等，所以如果只是出于管理目的，可以创建自签名证书，保证管理员通过浏览器安全连接到服务器。

**2）创建自签名证书需要安装openssl，使用以下步骤：**

*  创建Key；
 *  创建签名请求；
 *  将Key的口令移除；
 *  用Key签名证书。

脚本见：[itranswarp.js/gencert.sh at master · michaelliao/itranswarp.js · GitHub][itranswarp.js_gencert.sh at master _ michaelliao_itranswarp.js _ GitHub]

为HTTPS准备的证书需要注意，创建的签名请求的CN必须与域名完全一致，否则无法通过浏览器验证。

![35660f36c58a46f7a3b37efe7947f1de.jpeg][]

在当前目录下会创建出4个文件：

www.test.com.crt：自签名的证书

www.test.com.csr：证书的请求

www.test.com.key：不带口令的Key

www.test.com.origin.key：带口令的Key

服务器需要把www.test.com.crt发给浏览器验证，然后用www.test.com.key解密浏览器发送的数据，剩下两个文件不需要上传到Web服务器上。以Nginx为例，需要在server \{...\}中配置：

![7ecb42e3b51a4f4381e4490bdd1edd09.jpeg][]

如果一切顺利，打开浏览器，就可以通过HTTPS访问网站。第一次访问时会出现警告（因为我们的自签名证书不被浏览器信任），把证书通过浏览器导入到系统（Windows使用IE导入，Mac使用Safari导入）并设置为“受信任”，以后该电脑访问网站就可以安全地连接Web服务器了：

![6e07cf519851412392dc650381d11e1b.jpeg][]

注：在生成证书的时候可能报错 SSL routines:SSL\_CTX\_use\_certificate:ee key too small 解决方法 openssl genrsa -des3 -out server.key 1024 改成2048

**1.3）其他：**

如何在应用服务器中配置证书呢？例如Tomcat等。正确的做法是不配置，让Nginx处理HTTPS，然后通过proxy以HTTP连接后端的应用服务器，相当于利用Nginx作为HTTPS到HTTP的安全代理，这样即利用了Nginx的HTTP/HTTPS处理能力，又避免了应用服务器不擅长HTTPS的缺点。

参考：[给Nginx配置一个自签名的SSL证书 - 廖雪峰的官方网站][Nginx_SSL_ -]

### 2、证书验证和https加密 ###

指纹是什么？指纹是一个证书的签名，是通过指纹算法sha1计算出来的一个hash值，是用来验证证书内容有没有被篡改的。

证书在发布之前，CA机构会把所颁发证书的内容通过指纹算法计算得到一个hash值，并用自己的根私钥加密；这个加密后的hash值只有对应的根公钥才能解密，所以在验证证书的时候，我们通过同样的指纹算法将证书内容通过计算得到另一个hash值，如果这个hash值跟证书上的签名解析出来的hash值相同，就代表证书没有被篡改过。

#### 2.1）一个证书验证的过程： ####

1.  首先浏览器通过URL网址去请求某个后台服务器，后台接收到请求后，就会给浏览器发送一个自己的CA数字证书。
2.  浏览器接收到数字证书以后，就要开始进行验证工作了。首先从证书的内容中获取证书的颁发机构，然后从浏览器系统中去寻找此颁发机构是否为浏览器的信任机构。这里解析一下，世界上就几个权威的CA机构，这几个机构的信息都是预先嵌入到我们的浏览器系统中的。如果收到的一个数字证书但其颁发机构没有在我们浏览器系统中的，那么就会有警告提示无法确认证书的真假。如果是受信任的机构，那么就到下一步。
3.  浏览器中找到CA机构的根公钥，用这个公钥去解析证书的签名得到一个hash值H1，上面提到过，这个签名是证书发布之前CA机构用自己的根私钥加密而成的，所以这里只能由根证书的根公钥去解密。然后用证书的指纹算法对证书的内容再进行hash计算得到另一个hash值H2，如果此时H1和H2是相等的，就代表证书没有被修改过。
4.  在证书没有被修改过的基础上，再检查证书上的使用者的URL（比如csdn.net）和我们请求的URL是否相等，如果相等，那么就可以证明当前浏览器连接的网址也是正确的，而不是一些钓鱼网之类的。

**说明**：这里我们假设，如果浏览器的连接被某个钓鱼网截取了，钓鱼网也可以发一个自己的证书给浏览器，然后也可以通过证书没有被篡改的验证，但是在证书没有被篡改的情况下，通过对比证书上的URL和我们请求的URL，就可以发现这个证书的URL不是我们所要连接的网址，所以说钓鱼网也骗不了我们。（中间人攻击）

**总结：**

看到这里如果还不是很明白证书验证过程的话，我特别解析一下，我们知道CA机构有自己的根公钥和根私钥。在证书颁发之前，机构会用根私钥将这个证书内容加密得到一个签名，这个签名只能用对应的根公钥去解密。在客户端（浏览器）收到服务端发过来的证书以后，我们首先从浏览器中拿到机构的根公钥，用这个根公钥去解析证书的签名得到一个哈希值H1，这个H1代表证书的原始内容，假设这个证书上的签名是不法分子伪造的，但是伪造的签名不可能是根私钥加密生成的（因为根私钥是CA机构私有），所以根公钥也不可能去解密任何第三方生成的签名（加密内容只能由对应的公钥私钥解析）。然后我们再用同样的哈希算法对收证书内容进行计算得到哈希值H2，通过对比H1和H2是否相等就知道证书有没有被褚篡改过了。讲到这里，我们应该明白证书是否被篡改的验证机制了吧。

#### 2.2）https加密过程： ####

到这里，已经验证了证书是没有被篡改的并且确认连接的URL也是正确的，然后我们获取到了证书上的公钥。下一步有一个很重要的任务就是，如何将一个对称加密算法的秘钥安全地发给服务器。

1.  首先随机生成一个字符串S作为我们的秘钥，然后通过证书公钥加密成密文，将密文发送给服务器。因为此密文是用公钥加密的，这是一个非对称加密，我们知道，这个密文只有私钥的持有者才能进行解密，所以说任何第三方截取到密文也是没用的，因为没有对应的私钥所以解析不出来。
2.  还有一个关键步骤，发送密文的时候也会对消息内容进行签名操作。签名上面讲解过，就是对密文内容进行hash计算得到的一个hash值，将这个签名加密以后和消息内容一起发送出去。接收方收到消息以后，通过私钥解析出密文和签名的hash值，同时也会对接收的消息内容进行同样的计算得到另一个hash值，通过比对两个hash值是否相同来判断密文是否有修改过。
3.  通过了上面的步骤以后，此时客户端和服务端都持有了对称加密算法的秘钥，然后兄弟两就可以愉快地安全通信了。

下面基于一个简单的图例，去分析整个HTTPS的数字证书验证过程：

![e1a486e010ce4bfc8f39f0ae38149ec1.jpeg][]

总结：数字证书的验证有两个重要的步骤，第一是验证数字证书没有被篡改以及连接的URL是否正确，第二是通过RSA机制的原理安全地将对称加密算法的秘钥发送给对方。这两步都完成以后，整个HTTPS的数字证书的验证就算是成功了。

好了，通过上面 的讲解，相信我们已经掌握了https的数字证书验证原理了。

#### 2.3）如何申请一个证书？ ####

从上面我们知道了证书验证原理，简单梳理一下都需要哪些：

客户端用到的如下：

*  CA机构的公钥：已经内置到系统中不需要处理
 *  公钥证书：服务器端发送给客户端的，为了安全客户端一般会通过CA公钥解密出指纹进行对比校验，来验证真伪（如果不验证证书的真伪，直接取出来公钥也是可以进行https通信的，但是防止不了中间人攻击）；
 *  服务器公钥：客户端用CA公钥解密证书获得
 *  随机数生成对称秘钥：自动生成

服务器端：

*  服务器端私钥：手动生成，并保存好
 *  服务器公钥：手动生成
 *  公钥证书：需要去申请、或者自签

客户端需要的工具不需要我们配置，主要是服务器端，如何来的呢？

1）首先我们在服务器端用ssh-keygen命令来生成公私钥：

在服务器端命令行中执行,ssh-keygen会在服务器的"~/.ssh"目录中生成两个文件 id\_rsa,id\_rsa.pub，前者不带pub后缀的为私钥，后者带pub后缀的为公钥。

2）申请证书：

拿着服务器端的公钥去权威CA机构申请证书，CA机构的客服一般会想你要你的服务器公钥和你的网站信息，然后CA机构用CA机构的私钥加密你的服务器公钥得到公钥证书，然后CA机构会将公钥证书颁发给你。

经过上面两部操作我们就会得到公钥证书和服务的私钥，拿到这两个文件我们可以使用配置https协议的网站了。

这里要说明一下，我们向有些CA机构申请证书时，它不需要你提交服务器公钥，而是它会自己生成一对服务器的公私钥，然后把服务器公钥用CA私钥加密成证书，和服务器私钥一起发送给你，阿里云的免费证书就是这样操作的。

参考：

[https://www.cnblogs.com/blogtech/p/16589237.html][https_www.cnblogs.com_blogtech_p_16589237.html]

[白话https原理][https]

[nginx如何配置https证书][nginx_https]

[e605eabec4ae4020b160fbe360771707.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/afa6836846cc432393001920e38ef8bf.jpeg
[8ca61aad685c4b7e9ddf9b9f1a5309ad.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/f10056bd925f458c93e90f71be49dcae.jpeg
[itranswarp.js_gencert.sh at master _ michaelliao_itranswarp.js _ GitHub]: https://github.com/michaelliao/itranswarp.js/blob/master/conf/ssl/gencert.sh
[35660f36c58a46f7a3b37efe7947f1de.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/a25bdf6a512549039cdf4c0fb782df6e.jpeg
[7ecb42e3b51a4f4381e4490bdd1edd09.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/4e2660d196a441f18e0c5d31d34b218b.jpeg
[6e07cf519851412392dc650381d11e1b.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/3de4f1797de649fcb972495c48b6f4d3.jpeg
[Nginx_SSL_ -]: https://www.liaoxuefeng.com/article/990311924891552
[e1a486e010ce4bfc8f39f0ae38149ec1.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/e23b9699947b468b88f1503b887fa8c8.jpeg
[https_www.cnblogs.com_blogtech_p_16589237.html]: https://www.cnblogs.com/blogtech/p/16589237.html
[https]: https://mp.weixin.qq.com/s?__biz=MzA4MTg4MDI5OQ==&mid=2456039491&idx=1&sn=63b44659eeead9c4a656c898e6a29cce&chksm=881ea5c7bf692cd1ba9bdc9eadf5a66d95a194743d3224812899f403d2e1321c978879fa470f&scene=21#wechat_redirect
[nginx_https]: https://mp.weixin.qq.com/s?__biz=MzA4MTg4MDI5OQ==&mid=2456039514&idx=1&sn=d63932526ee4b61fd392c94bbb18a277&chksm=881ea5debf692cc83cb8781d1780e774db9936e93621dc9105d3ad55cc2be9487ed9abe4ce9d&scene=21#wechat_redirect