07Https证书配置

目录

Https协议

不安全的Http协议

凯撒密码百度百科

对称加密

加密算法的弱点

对称加密算法不安全的原因

非对称加密原理

第一步： 从443端口去下载公钥

第二步：公钥加密、私钥解密

​ 第三步： 从443端口去下载公钥

伪造客户端

伪造服务端

解决思路：CA机构

如何实现

Window下证书的位置

证书

证书自签名

什么叫证书字签名呢？

---

Https协议

不安全的Http协议

HTTP 协议是因为它不安全，它究竟怎么不安全呢？

正常用户上网访问我们的服务器的基本的流程，它要接入互联网，然后我们的服务器要接入互联网。在底层网络上，是通过我们的这个客户端的最底层的 socket，  也就是基本的网络接口，是基于网卡的那个特别基础的网络接口，它可以向外去发送数据包。我们在这儿管它叫 socket ，在 socket 编程，会学习 TCP 的编程和 UDP 的编程，那么这两种就已经是这个稍微上层一点的网络协议了。
        这 socket  是基于我们操作系统更底层的协议，它和物理硬件去完成连接，或者说他基本上是我们无法操作的这种协议，通过这个操作系统的内核和这个网卡驱动去传输数据                  在上头的 TCP/IP 协议在数据传输的时候其实也是偏向于比较底层的。我们如果要是发送一个数据包过去对方的服务器基本上是不知道这个数据包它到啥时候会终止，基本的 TCP IP 协议只是传递数据的。那我们通常会在 TCPIP 协议上再加一层我们的应用层的协议。

        前面这两个都是底层协议，后边的 HTTP 协议就属于是应用层的高级协议了。

        一个 HTTP 的数据请求包它会分为头和体，那它的 header 和 body ,  head 里边会包含这些参数，然后 body 里面会真实地去传递我们想传递的数据，比如想上传一张图片，那么这个图片是在 body 里的对吧？那么说 HTTP 协议它不安全，因为它用了这几个底层协议，它没有一个是能够保证数据在传输过程当中是安全不会被劫持的。

         我们电脑一般来说都会装防火墙对吧？那我们的这个服务器也都得装防火墙，这防火墙能不能防住，我们数据不被别人这个窃听，其实是不会的，只能够防住，我们的一些端口不莫名其妙的别往外去传递数据，

        那它我们本地的防火墙还会防什么呢？
        一些病毒或者一些未知的程序，它像网络去发送数据。那这个其实和我们正常访问也是不一样，正常访问的情况下它就不安全，它不在防火墙的这个安全规则之内，也就是它无法保证我们数据传递的安全性。
        服务器端也是服务器端的防火墙，一般来说会屏蔽一些端口号，只开放某些端口，对互联网可以访问。然后还有一些更高级的规则，比如说你重复去刷新间隔时间过短，这边的防火墙会根据规则去屏蔽一些用户的访问，但它都没法去保证在互联网的传递过程当中这份数据的安全性。

        那这份数据究竟有多不安全？
        我们在接入互联网的时候，我们每一个接入互联网的这些设备，比如我的手机。                      
        如果你访问的目标服务器是在美国，可能会穿过的节点多达十几甚至二三十个。那么每一个节点，都会把这个数据包传递到下一个节点，一个节点到另外一个节点。这种不间断的传递，到最终才能访问到我们的服务器。那在每一次传递的过程当中，节点内数据其实都是我们可以看到的。  这份数据在传递的过程当中，它以二进制（10）的形式存在。

        那么这一份数据，一但被我们中间的这个节点所拦截，并且猜出来我们用的是什么协议，比如说你是HTTP（ 或者 TCP） 协议，按照 HTTP 协议去解这个数据本解包，就能直接把它给解开，解开之后就能读到你的明文，他读到这个明文之后，我就知道你的内容。
所以 HTTP 协议在数据传输的过程当中是不安全的，而且有很多节点都可以监听得到。
 

        想要解决这个问题，那我们就势必要增加一层安全的协议。  那这种安全的协议就要基于 HTTP 或者是基于 TCP 不管是基于哪层协议，我们让其安全，那我们在两端都要额外加一层安全协议。

协议：

        安全协议、HTTP协议，这都是协议，协议就是双方要达成共识。那客户端要遵守，服务器端也同要遵守，两边都要遵守同一份协议，那么他们才能够互相配合，才能够互相去协同去工作。

        那我们在 HTTP 协议下传递数据包的时候，它其实是透明的，这种透明的数据包的传递，我们想要在此基础之上再增加一层安全的协议。

其实最简单来说，有一个叫凯撒密码

凯撒密码百度百科

    在密码学中，恺撒密码（英语：Caesar cipher），或称恺撒加密、恺撒变换、变换加密，是一种最简单且最广为人知的加密技术。
它是一种替换加密的技术，明文中的所有字母都在字母表上向后（或向前）按照一个固定数目进行偏移后被替换成密文。例如，当偏
移量是3的时候，所有的字母A将被替换成D，B变成E，以此类推。这个加密方法是以罗马共和时期恺撒的名字命名的，当年恺撒曾用
此方法与其将军们进行联系。

        那么我们服务器端还看得懂，看不懂，默认情况下他看不懂。服务器端也得实现这个加密的协议，把这套算法，引入这个服务器端，通过这套算法去解密，把这个密文解密解出来，才能得到明文。
 
        这是最简单的一种加密算法。那这种加密算法在网络当中传递，它传递的是密文，两边传递都是密文。客户端在发送请求的时候把明文加密成密文，然后再发向网络。然后这个服务器端接到之后把密文转换成明文。读懂之后想要返回的数据也把它通过相同的加密算法。给他改返回去，中间拦截者得到的数据也就是加密的密文了，他也看不懂。

对称加密

  所谓的对称加密，就是双方采用同一种算法，然后互相去加密和解密数据。这种加密的方式比较简单。

加密算法的弱点

        尤其是在互联网环境下，我们使用那种对称的加密算法呢？这种加密算法究竟有多少个？那首先这种加密算法我们一定要知道，它一定要内置到我们的服务器当中，这就导致我们加密算法可以在互联网当中使用。或者说对称加密算法在互联网当中使用不安全的决定性因素。因为对称加密算法它一定是固定的。比如凯撒加密算法，但不管是你怎么做这种对称加密，你这种对称加密的算法，一定要内置在服务器端。
 

举例：
        我们现在正在学的是啥服务器端是什么？就是 nginx ，我们想要在 nginx 里使用它的这种对称加密算法，那么这个 nginx 它是不是公开和开源的，那既然它是开源的，它就是面向于互联网的，那么这种互联网上是不是任意 用户都可以下载得到这个 nginx  并且能读懂它的这种对称加密算法，获得到了他的这种对称加密算法列表之后，中间拦截者是不是也能得到这个对称加密算法的列表，不管是你三种五种还是 500 种，我就拿着几百种加密算法，挨个去破解你的这个密文是不是也能行得通。因此对称加密已经不安全了【因为它必须得是公开，开源的对吧？
我们的客户端也是，我们的客户端，假如说我们使用浏览器，那么他也要内置这些加密算法。他如果没有加密算法，那他就没法加密数据，服务端也读不懂对吧？所以浏览器也是没有我们用户参与进来。然后服务器端这些加密算法又是公开的。那么所有人都能知道你现在可以使用的加密算法的这些列表，拿过来之后就挨着个去尝试是不是就可以破解了。因此对称加密已经不安全了，】

对称加密算法不安全的原因

       那对称加密算法它的不够灵活。这是单一的加密和解密，才导致它现在这个不够安全。

        在对称加密算法之下，我们是不是可以在客户端请求服务器端的时候和他商量一下？接下来我们要怎么干？这个商量就可以让他在原来的算法之上加入一个因子。
        也就是说在给你传递一个数据包，这个数据包我先压缩加密 （zip），把数据用zip 压缩工具压缩打包 。打包后加一个密码，这个密码是客户端在第一次请求的时候加的。那我在加这个密码之前，先向服务端发一个请求，这个请求是用来干嘛呢？（告诉我的加密密码，为 666）

        此时就安全了？

        你想想，那我以后再发这个数据包的时候，这个数据包是有密码的。然后这个加密协议我加入一个因子，你拿这个密码然后才能够解开，你没有密码就解不开，这样就达到了灵活的特性。

对称加密协议都是比较固定的，那想要说它灵活，那这样是不是就灵活了？

但此时有一个巨大严重的问题，那这个加密告诉过程又是不安全的，
因为这次加密你只能基于 TCP 协议 或者基于 HTTP 协议 ，这不能基于安全的这种协议，即使你是用对称加密，它也是不安全的。所以对称加密算法在这是无解的。因为你在互联网的数据传递过程当中，这个加密的密文数据是不被保证安全的。（对称加密此时无法使用）

非对称加密原理

数据传出的过程当中，这个算法不能丢

对称加密，它这个算法是固定的，没法去加入任何的因子计算因子，而且你加了之后其实没有什么用，因为加密因子也得在互联网当中去传递，

所以就演化出来了。另外一种加密算法叫非对称加密算法。

这个非对称加密算法相比对称加密算法来说，它的这个参加计算的因子不一样了。

        我们之前的算法没有因没有计算因子，或者是加了这个计算因子之后，我们需要在公网去明文地去传输。那这个非对称加密算法可以生成一个加密因子。然后这个加密因子不在互联网当中去传输，非对称加密算法，加密和解密的这个方式它不一样

第一步： 从443端口去下载公钥

        加密的时候需要加入一个计算因子，这东西叫公钥，在客户端这一端是公开的，然后在服务器端藏有一个私钥。用户在请求服务器数据的时候，第一次请求先不走这个我们正常的请求   ，如果是 HTTP 协议的话，先不走正常的这个 80 端口，正常是 80 端口对吧，他走这个 443 端口。从443 端口，先去下载公钥。

第二步：公钥加密、私钥解密

        拿到公钥之后，用户再次真正去请求我们的服务器，把想要发送的明文通过这个公钥作为计算因子，再加上加密算法得到密文。这个密文再传递给我们的服务器。服务器拿私钥 + 加密算法去解这个密文，然后就能得到密文。

        然后在得到明文之后响应用户请求。比如你想跟我找一个图片，找着这个图片之后我再发送给你。注意此时 拿 私钥 + 加算法去加密数据，这是服务器端，它跟客户端不一样，客户端加密 是 公钥 + 加算法，服务器端是私钥 + 加密算法，私钥 + 算法得到的数据再传输给我们用户。用户 拿  公钥 +  算法可以把它给解开。

        公钥加密，公钥是计算因子，是在算法里边的参数，私钥可以解密，这也是我们第一次数据传输的过程。然后在传输回来之后，它可以用私钥去加密，然后我们客户端可以用公钥去解密，这都是能正常完成的操作这是非对称加密算法。

 第三步： 从443端口去下载公钥

        我们第一次请求还记得，我们是从443端口 把公钥下载到我们的客户端的，那么它在下载的过程当中，下载公钥的过程，也需要要经历所有的互联网？就像刚才所说的传递密文一样。要经历我们所有中间路由网关，一旦路由网关把公钥给它拦截住了，或者我给你复制一份，我还能让你保持正常通讯。
        他复制了一份公钥，这里边问题就出来了，这就不安全了，他在本地留了一份公钥。       如果此时传递的数据用公钥加密（公钥在互联网中是传递的）、公钥能解开、那么拦截者就能够获取我们的信息。

        私钥不在互联网中传递，一定要保证私钥的安全。
        对称加密是算法一定要安全
        非对称加密是私钥一定要安全

非对称加密需要保证的三点：
            1、从443端口去下载公钥
            2、公钥加密、私钥解密
            3、从443端口去下载公钥

        如果这个非对称加密算法允许公钥加密公钥能解，那这套加密算法它也是不安全的。那这套非对称加密算法就是我们现在 HTTPS 协议的底层算法。那么光靠这层非对称加密的底层算法，我们的互联网还不是绝对安全的。

伪造客户端

        未成功、公钥加密公钥解不了

伪造服务端

        用户在请求我们某一个服务器的时候，比如说我下载证书，我知道了你想要请求的地址，因为你刚开始你这次请求虽然说经历了443端口，但是它是明文请求。你不是想加载这个公钥吗？那我直接给你一个公钥（假）不就完了吗？。此时这次请压根就不让你请求到服务器端，然后我再替你去请求服务器端。
        我把假的公钥给你。接下来 你跟我 看起来也是建立了安全连接，我跟服务端也建立了安全连接。（看起来正常），那接下来真正的请求，拿着拦截者给你的公钥（假）去加密，拦截者用拦截者私钥去解密。用户信息就此泄露。然后解密完的数据，我再包装一下，拿服务器端给我的公钥（真）去加密，然后服务器端再拿他自己的私钥（真）去解密，信息篡改完成。    

此时：非得是加密算法在此时也是不安全的

解决思路：CA机构

        没有办法判定是不是真正的服务端给的公钥，在中间可以增加一个环节，环节是可信任的环节。

        第三方  在客户端和服务端都存在  不能在网络当中传输的 起到的作用就是认证此次公钥没有问题，数据一旦有问题就不在去传递。同时早在服务端下发公钥之前就，对就下发公钥就行认证。一定得有不在网络当中去传递的数据。
    抽象一点，我们就可以把它理解成在我们的计算机里存了一个密码，然后在服务器上也存了一个密码，这俩密码不传，而且只有我们两知道这才行。

如何实现

        引入真正的第三方机构

作用：就是对于我们下发的非对称加密的公钥进行认证。

如何实现认证的：首先这个 CA 机构想要对这个公钥进行认证，服务器端生成公钥，接下来要向 CA 机构注意， 【CA 机构它也是一个这个非公立性的组织，但是他要收费，这个机构它也有自己运行的这套系统和服务器】，把公钥提交给这个 CA 机构。这是在首次还没有下发过任何的这个证书或者是公钥之前，就要把这个公钥进行一次认证。CA 机构的认证过程，首先对于我们用户提交的公钥，他会先识别一下，提交的是不是一个正常的公钥【正常的提供者】一定要认证一下你是否真正是当前网站的所有者。

        一旦认证了用户有这个权限，接下来会对你提交上来的公钥。再进行一次包装和加密。。这一层加密同样是非对称加密，这个非对称加密是靠 CA 机构自己的私钥，接下来给你生成了一份这东西，就叫证书【把这个公钥给我加密，再次加密，生成一个新的证书】。
        服务器端拿到这个证书之后，再有用户请求443 端口，想要这个公钥的话，我不直接给他公钥了，我给他这个证书，再次下发证书，其实就是我们的操作系统里边内置了 CA 机构的公钥，他拿 CA 机构的公钥能够正常地解开这个证书，说明在中间过程当中是没有被篡改过。

如何怎么证明这个过程当中没有被篡改？

        那就是因为 CA 机构在下发的证书里边，这个证书在传递的过程中。我们的中间拦截者，他想把这个证书解开，它能不能解开呢？它是可以解开的。但是他想要再次加密，他怎么加密？他需要有 CA 机构的私钥才能加密成 CA 机构。CA机构的私钥是不可能丢的。所以说中间拦截者加密出来的东西它不是 CA 机构的。那也就是说中间拦截者加密出来的东西，给了我们的用户，用户最终用户是不承认的。
        因为 CA 的这个私钥是比较特殊的一种私钥，我只能用操作系统里内置地去解，也必须要用操作性内置的去解。如果从网络下发出来的另外的一个 CA 机构的公钥，我直接把它解开了，这事就不安全了。操作系统是不信的，浏览器是不信的，我们用户也不信。 CA 机构的出现的就是去当一个证人使用的。那么获取到了这个证书之后，拿内置的这个 CA 机构公钥 把 数据 解开得到什么 ？得到服务器的公钥，接下来就可以拿服务器的公钥去加密数据。

        那这一份加密的数据有没有可能会被篡改？没可能。

        因为：在提交的时候，提交上去这边是公钥加密，造假者能不能拿到这个服务器的公钥？可以，但是它能篡改吗？篡改不了。公钥加密，私钥解密，公钥加密公钥解不开，造假者他持有了服务器端的公钥，也解不开这份数据，公钥加密，公钥解不开，只有私钥可以解，所以在传输的过程当中它就保证了安全性。所以在这里边最重要的就是有  CA 存在，有可信任的人这一定要可信任。
 

Window下证书的位置

 
 HTTPS 是被称为在 21 世纪互联网界最伟大发明。

证书

证书自签名

什么叫证书字签名呢？

        就是这个 CA 机构这个角色也是我们自己扮演的。这种应用场景使用非常的少。
因为如果你配到互联网上，你打开之后这个域名（浏览器）前面它不会有这个小锁头，浏览器不会认为你是一个安全可靠的连接。因为这个 CA 机构它不是操作系统里边内置的，是你自己给自己签的。那如果你想要让别人给咱们签，就需要咱们得在线去申请。
        这种场景实在是有点少，基本上没什么太大的用处，只有在这个内网环境下可能会用到这个自签名。还有这个这种 CS 这种连接也有可能会用到这个字签名，但是用处不大。一般来说都会在公网上去申请。

公网上去申请字签名的话可以用这个 OpenSSL 是非常非常著名的一款开源软件

图形化界面也是基于 OpenSSL 的  XCA

# 下载地址
https://www.hohnstaedt.de/xca/index.php/download