http其它的报头
直接看图片：
上图中的第一个和第二个类型之前已经使用过了也就不多做说明了，第三个报头类型使用的很少了。第四个报头类型主要就使用在一些灰度更新的应用上，确定用户使用的软件的版本不让其访问该版本不能访问的功能。下一个refer主要适用于某些网站并不想接收某一个特定的网站发来的请求。使用refer就可以实现。在网络安全的领域可能会使用到。网站可以检查请求的refer如果这个refer是来自于该网站禁止的哪一个网站发来的，就可以拒绝提供服务。最后两个之前也已经说明过了。
https协议原理
通过使用http可以知道，客户端通过Gett请求可以从远端获取资源(网页，视频，音频等等)。客户端也可以通过GET/Post方法向服务器上传资源（可以通过往url中写信息让服务端分析url得到，或者写到请求的正文中让服务器得到）。其中post就是通过正文进行传参的，在传递的时候更加具有私密性，但是两者都是不安全的。凡是数据只要在网络中明文传递就是不安全的。随时随地都可以被别人拿到。
而想要让数据安全的传递就必须要进行加密，也就是要学习https。https无法做实验以理论为主。
首先http和https的关系是什么呢？
首先网络是具有层状结构的，除了物理层之外就是应用层（之前写的代码主要就是在这一层）,传输层(udp/tcp),网络层（ip），数据链路层（mac）。
其中数据链路层是网卡驱动做的，传输层和网络层是os做的。
应用层就是使用系统调用接口(socket进行网络通信)。
Https属于那一层呢？https也属于应用层。
首先在http的下面增加了一个TLS/SSL（加密/解密层，真实名字不是这个只是这样说便于理解）
而在使用协议的时候不经过加密解密层直接到下层就是普通的http了。
如果在使用的时候经过了下层就是https了。
由此就能得到https的概念了:
为了防止被篡改就需要对http传递的信息进行加密一般加密都是在正文部分进行加密。
加密的概念
那么什么是加密呢？
加密就是把明⽂(要传输的信息)进⾏⼀系列变换, ⽣成 密⽂ . 解密就是把 密⽂ 再进⾏⼀系列变换, 还原成 明⽂ . 在这个加密和解密的过程中, 往往需要⼀个或者多个中间的数据, 辅助进⾏这个过程, 这样的数据称为 密 钥 (正确发⾳ yue 四声, 不过⼤家平时都读作 yao 四声) .
主要就是出现了原文，密文和密钥。
使用一个简单的例子： 现在假设服务端想要给客户端发送一个数据7，但是为了防止7被其他人得到，所以这里我就和客户端一起约定了一个密钥5，我在发送7的时候让7^5（异或） = 2然后让2通过网络发送给客户端，客户端在得到2之后再让2^5就变成7了。而中间截取数据的人因为不知道5所以就只得到了2。
但是实际的加密算法比这个复杂的多，但是通过这里只需要知道具有密文，密钥和明文就够了。
这些主要是从密码学来的概念:密码学的奠基⼈, 也正是计算机科学的祖师爷之⼀, 艾伦·⻨席森·图灵。
为什么要进行加密
要进行加密是因为有人会盗取我的数据，那么是谁要盗取我的数据呢?
当你和某些人在统一局域网的时候，某些人可以盗取你的数据，也可以通过让你的电脑中一些病毒来盗取你的数据。
然后下面也是一种你的信息被别人盗取的现象:
在正常的情况下点击下载获得的就是天天动听的软件
如果这个请求被劫持（盗取了）
上图中获取下载链接使用的http是明文的，需要获取下载链接。之后就有人篡改了下载链接就造成了上面的场景。
图片解释:
通过图片能够知道篡改信息的就是运营商/中间人（所有的民用网络都是要走运营商的）。后面会说明运营商的好与坏。
因为http的内容是明⽂传输的，明⽂数据会经过路由器、wifi热点、通信服务运营商、代理服务 器等多个物理节点，如果信息在传输过程中被劫持，传输的内容就完全暴露了。劫持者还可以篡改传 输的信息且不被双⽅察觉，这就是中间⼈攻击 ，所以我们才需要对信息进⾏加密。
那么为什么运营商要修改数据呢？
其实我也可以使用一个最简单的方法成为中间人，那就是使用你的手机在人多的地方开一个免费的热点，让别人去链接你的热点然后去上网，此时别人的请求需要经过你的手机去发送请求，你的手机也就成为了一个中间人。
这是成为中间人的最简单的方法，而建立一个小型基站等等，这些硬件的方法更不用说了。通过上面的学习能够知道一点明文传递信息是一个很危险的事情。所以需要进行加密。
常见的加密方式
常见的加密方式分成两种一种是对称加密，一种是非对称加密。
对称加密
什么是对称加密呢？
对称加密也就是但密钥加密，也就是同一个密钥既可以用来加密也可以用来解密.。特点就是加密和解密使用的密钥都是相同的。例如上面举得那个异或的例子就是对称加密。
对于这些加密算法网络当中是有很多的开源项目的。可以直接使用别人的.h文件等等。
总结一下对称加密的特点:
非对称加密
什么是非对称加密呢？非对称加密需要两个密钥进行加密和解密，其中一个密钥是一个公开的密钥，一个是私有密钥，当然也不是在网络上直接给所有机器发送我的公开密钥。公开密钥也就是这个密钥别人可以自由传送，可以随意获取。还有一个私有密钥是别人不能知道的，只能自己知道的密钥也就是私有密钥。原则上两个密钥谁是公钥谁是私钥可以随意选择一个。
然后还有一个特点:
也就是私钥和公钥可以互相加密和解密。但是如果你使用了公钥进行加密只能使用私钥进行解密，如果你使用了私钥进行加密，只能使用公钥进行解密。
常见的非对称加密的算法:
RSA主要用于大数据运算或者大的因式分解。也因此这种方法的实现是比较复杂的，也就导致了运算速度是很慢的。
如果你的数据量比较大并且加密/解密算法写的不好，那么传递信息的速度就达到了秒级别了。这和非对称加密来说慢的不止一个数量级。
总结非对称加密:
数据摘要/数据指纹
首先数据摘要等于数据指纹也就是两者是同一个东西。只不过摘要更加技术化一点，指纹更加形象一点。
数字指纹(数据摘要),其基本原理是利⽤单向散列函数(Hash函数)对信息进⾏运算,⽣成⼀串固定⻓度的数字摘要（就是将你的数据经过哈希函数生成一串新的数据）。数据指纹并不是⼀种加密机制,但可以⽤来判断数据有没有被篡改。那么为什么数据指纹不算加密呢？因为这种方式并没有什么方法进行解密。也就是如果一个数据进行哈希了是没有什么方法还原的。
既然不是用来加密的，这是用来干什么的呢？这个算法有一个特点，如果你对你的数据进行了一点点的修改（哪怕只改一个字段）那么生成的散列值和原来没有进行修改的数据形成的散列值是完全不同的，差别是非常大的。还有一个特点，这里即使你使用10000份数据不同的文件经过相同的哈希函数西形成的固定长度的散列值大体都是不一样的。虽然有概率发生冲突但是这个概率非常的低。
所以不同的数据经过哈希之后形成的是几乎不会一样的固定长度的散列值（当然相同的文件，经过相同的哈希形成的散列值是一样的）
常见的哈希算法比如:md5。
那么这个有什么应用场景呢？
假设这里有一个服务，需要用户登录之后才能提供服务，现在某一个张三的用户，之前已经注册过了，在服务器的数库中已经存在了自己的信息。
那么在第一次链接的时候张三输入自己的用户名和密码交给服务器，服务器在内部进行判断之后形成一个session返回给用户，之后张三就可以使用session进行服务的获取了。
但是这里假设一下，如果服务器mysql中的数据泄露了，那么造成的影响是不可估量的，因为如果数据库中的数据泄露了不可能要求所有用户修改密码，如果你的用户很多，这个服务器吃不消的。所以这里就可以使用这个数据指纹了。首先当一个新用户注册的时候提交给数据库的信息是用户名和经过md5的密码信息，那么储存在数据中的密码即使泄露了造成的影响也没有之前没有使用md5的时候大了（用户的密码已经被哈希过了）。那么如果老用户登录的时候要如何进行对比呢？一样的对用户提交的密码进行md5之后和数据库中的md5进行对比，根据md5算法的特点，如果对比失败这个用户的密码就是不正确的。也一样能够完成登录的功能。
当然程序员也就不能看到密码了，本来也不应该能够看到。
如果再对数据库中的数据进行加密，安全级别就更加高了。
还有一个使用场景就是在百度网盘了。如果现在两个用户都想往网盘的服务器上上传两个100G的一样的数据。难道网盘的服务器就真的将两个100G的数据一起上传了吗？（假设网盘上已经有这个100G的数据了）当然不是，在上传的时候会对这个上传的数据进行哈希得到一串哈希值。然后将这个哈希值和服务器中的已经存在的文件的哈希值进行对比，如果是一样的，那么百度的服务器是不会储存两个一样的数据的。而是会将那个已经存在的数据映射到这个用户的区域中。这个功能也就是妙传功能。将另外一个用户已经存在的数据映射到自己的数据区域中。不考虑异常的情况。当然这只是一个最简单的原理，还有很多的技术细节，我不了解就不说明了。
百度网盘通过数据指纹甄别相同的文件（100G的数据也可以哈希形成数据指纹）。这就是为什么数据摘要还叫作数据指纹。数据指纹的作用
如果两个100万的文章有抄袭的嫌疑，就可以通过数据摘要的方法判断。除此之外如果某一个文件我在8点的时候形成的摘要和在10点形成的摘要是不同的，说明这个文件被篡改了。
还有一个概念是数字签名，数据摘要经过加密就能得到数据签名，后面再详细的说明。
以上是https的概念摘要。
对于https的学习，通过https的发展历史来学习https
通过上图中的历程来学习https。
Https的工作过程探究
为了传输的安全必须要对数据进行加密，加密主要分成两个部分对称和非对称加密。
方案1：只使用对称加密
使用这种方案，黑客即使在中间截获了我的数据因为截获的数据都是密文的，所以无法获取这个信息。
这种方案存不存在问题呢？这种方案存在一个典型的问题:s双方客户端必须约定好一个密钥。而在约定密钥的时候，客户端能够得到这个密钥，那么中间人也能得到这个密钥。并且世界上的客户端是很多的，难道给每一个客户端 都内置一个密钥吗？这种做法很草率，并且就算给所有的客户端都内置了密钥那么这个密钥是否是一样的呢？如果是一样的，那么黑客也能拿到这个密钥。如果都不一样，那么服务器端也要管理这么多的密钥，密钥如果很多，服务器的负载就太大了。所以这种内置密钥这种做法不太现实。
那么能否服务器端动态生成一个密钥然后发送给客户端呢？那么思考一个问题，在服务器向客户端发送密钥的时候这个密钥本身需不需要加密呢？这个密钥如果是明文传送的，所以黑客想要拿到这个明文密钥是很容易的。所以使用对称加密的难点就在于如何让服务端和客户端如何安全的约定好一个密钥
方案二：只使用非对称加密
首先服务器生成一个公钥一个私钥。然后在客户端链接服务端的时候将公钥传递给客户端：
此时在中间是存在中间人的。中间人也能得到公钥。
然后客户端在发送信息的时候使用公钥进行加密，因为非对称加密的特点这个密文只能使用私钥进行解密，因为中间人只有公钥，所以即使中间人存在公钥也无法得到解密后的真正的数据。这样就保证了从用户到服务器端数据的安全（暂时，其实还是存在问题的，之后说明问题在哪里）。
但是还有问题，如果服务端想要给客户端发送信息的话，因为客户端只有公钥，所以服务端只能使用私钥进行加密(公钥解密)，在传递信息的时候因为中间人也有公钥这个由服务端发送的数据就被中间人截获了。
所以只使用非对称加密这种方法是有问题的，只能貌似保证单向的安全性。
方案三:双方都使用非对称加密
首先直接让双方都具有自己的公钥和私钥。然后双方都将自己的公钥交给对方,此时的中间人也一样能够得到这两份公钥。
带'的是私钥，没有带的是公钥。
现在客户端想要发送请求给服务端，刚好我知道服务端的公钥我就使用服务端的公钥进行加密，让这个请求只能使用私钥解密。这样中间人就得不到真实的数据了。
这也就是上面说的从左向右保证数据的安全性。同理如果服务端想要给客户端发送信息，因为服务端知道客户端的公钥所以使用公钥进行加密，依旧能够让这个响应只让客户端拿到有效的数据而让中间人得不到（因为中间人只有公钥）
这样不就做到了双端的安全性。但是这个方法存在两个问题:
第一个使用的方法是非对称加密，而非对称加密的速度非常慢，如果真的使用的是非对称加密，如果数据量大，加密解密算法又不好，那么你在访问网站的时候几秒都无法打开网站。这就导致了效率过低。同时这个方案三依旧存在安全问题，这个问题待会再将下面的方法之后一起说明。
这里还有一个点需要知道在密码领域不考虑一些特殊的场景，比如某一个正在传输的数据的价值非常的高，不惜一切的场景都需要将这个数据解析出来。这种场景不做考虑，比如一个普通人发送的正常的信息你使用超级计算机以穷举的方法去破解数据。这些情景都是不考虑的，一般认为如果一个黑客要解析出你这个数据所需要的花费大于了这条数据本身的价值就认为这条数据是安全的（数据价值：100，破解花费为1000，此时就认为这个数据是安全的）。任何人都知道吃力不讨好的道理。通过这个需要知道的是一个普通的数据并不是一定不可被破解。因为当你计算机的算力很强的时候通过穷举是能够进行破解的。
回到方案三，方案三既然存在问题，那么使用下一种方案:
非对称加密+对称加密
图片说明:
首先服务端生成一个公钥s和私钥s',然后当客户端访问服务端的时候服务端给客户端响应回去一个公钥s。中间人也能得到S
然后客户端也动态的形成一个动态密钥C。此时在这个世界上只有客户端一个人知道这个动态密钥C。然后客户端使用服务器发送过来的公钥将这个C发送给服务端，因为中间人没有私钥S'所以无法得到这个C，之后客户端和服务端就使用这个C以对称加密的形式进行通信。
这样在不经意间就让服务端拿到了C。此时前半部分使用非堆成加密的方式进行对称密钥的交换。后半部分再采用对称密钥的方式进行通信。虽然这里也采用了非对称加密的方式，但是非对称密钥传递的数据量不大，并且次数也少，导致的时间成本忽略不计，之后使用对称密钥，而对称密钥的特点就是速度快。这样就解决了效率的问题。那么这种方法就是完美的吗？
当然不是，现在要优化这个方案就需要找到这个方案的问题在哪里,只要方案四的问题出来了，那么方案三的问题也就一起出来了。
为了找到缺点，切换一下视角将视角切换为中间人的视角。
使用中间人的视角定制一种攻击方案。
首先中间人也形成一个公钥M和私钥M'。然后服务器发起了一个请求，然后中间人能够得到这个请求已经公钥S。之前的中间人什么都没有做直接放这个请求过去了。
中间人首先将S保存好，然后将这个S替换成为M，此时中间人给客户端返回的这个公钥不是服务器的公钥S，而是中间人的公钥M，而客户端不知道这个公钥是谁的，只知道这就是个公钥。就相当于你获得了100现钱，但是这个现钱之前的主人是谁我不知道。
此时客户端就是用这个公钥M+对称密钥X形成密文，然后将请求发送给服务端。此时的中间人就能够通过M'解密获得对称密钥X然后中间人使用密钥S将这个X发送给服务端，服务端也不知道这个密文是从中间人那里加工后得到的。此时的中间人也获得了对称密钥X，从之后客户端和服务端的数据中间人就都能知道了，并且即使中间人将里面的数据全部改了客户端和服务端也都是不知道的
这就让方案四不再安全了。既然方案四存在这个问题，方案三一样也有这个问题。方案3在服务端发送的请求时我将服务端的公钥S修改为我的公钥M，然后客户端就是之后就使用用M进行加密，中间人就能使用M'解密获得数据了。同样发送给服务端的C中间人也可以修改为M之后服务端就会使用M进行加密，而中间人依旧可以使用M'获取数据，这样方案三也就不安全了。
首先需要明确一下方案四和核心问题是什么？核心问题就在于客户端被骗了。客户端不知道这个获得的公钥是从服务器来的还是从中间人来的。
也就是:
如果客户端能够甄别出来这是一个坏的公钥，直接将这个公钥进行丢弃，那么中间人也就无法进行攻击了。现在要解决的问题就是如何甄别这个公钥的合法性。
到现在为止，因为这个公钥只是一个数据，所以客户端是无法甄别这个公钥是否是合法的。所以需要给这个传递的数据增加一些东西。
由此就需要引入证书这个东西了。在提出方案5之前需要先知道证书这个东西。只有理解了证书才能理解方案5.
证书
首先在访问某些网站的时候会看到一些弹窗的信息。
这证明了网站上是存在证书的。这个证书和现实中的一些证书是不一样的。
现在回到这个证书上，既然存在证书那么就存在颁布证书的机构，这个机构就是CA机构。CA是一个权威的全球都会认的一个机构。之前说的定标准的机构也就是一个权威的机构。这个CA就相当于中国政府，我们因为相信了中国政府，中国政府给了每个人身份证，我们才能通过身份证去外面玩。CA相当于政府颁发的证书就相当于身份证，只要颁发了身份证就认为我是一个合法的中国人，同样的只要CA给某个网站颁发了某个网站，就认为某个网站是安全的。
一般如果我想要建立一个网站，除了要有云服务器要有服务，网站的站点，域名除此之外还要有一个CA证书，如果没有这个证书之后的所有人访问你的网站都会弹出上面的信息。如果你建立的网站经常弹出这样的信息，别人自然就不想访问你的网站了。所以建立好了一个网站还需要申请证书，那么CA凭什么给你呢？在我国是存在CA的子机构的。你相信了顶层的CA机构那么对于这些子机构也应该是相信的。简单说明一下申请需要的东西，如果你是个人，那么你的身份信息需要提交上去，如果你是企业老板，就需要将你企业信息和自己的信息提交上去。也因此现在的很多网站都是实名制的。不然如果你使用你的网站进行一些非法的勾当别人找不到你。
现在来看一下一般的证书的样子:
证书中的数据都是明文的数据，上面的数据中存在一个需要注意的数据也就是公钥，这个公钥就是服务器给客户端返回的公钥。到此如果服务器给客户端返回公钥的时候返回的不再只有公钥了，还存在了更多的信息，因为有了更多的信息，才给了客户端更多的可能性判断这个公钥是否是合法的。
首先证书上的明文数据一定是服务端曾经在申请证书的时候给CA提交的信息。
现在假设一个服务器刚刚建立好，别人如访问服务就会弹出上面的信息。此时服务器需要先形成自己的公钥和私钥。然后服务器将自己的私钥保存好，不给任何人。然后将CA需要的信息全部提交上去（包含公钥）。
这些数据形成了一个csr文件，然后将csr文件提交给CA机构。csr如何打包之后说明。现在这个公司已经提交了csr文件，CA机构会对这些信息进行审核。CA机构内部会使用种种方式比如接入政府的信息，打电话给你的公司，甚至是线下走访等等，反正各种方法检测你是否是合规的。没问题才会签发证书。
上面的公钥就是公司刚刚提交给CA的公钥也是服务端发送给客户端的公钥。然后这个公司的技术人员就会将这个证书放到网站中。之后所有的客户端得到的服务端的公钥就是上面证书中的公钥了，然后再走方案四的逻辑了。此时要说明的问题，首先申请证书这个过程不是经常要做的，证书中是存在有效时间的，只要在有效时间内都不需要重新申请。
那么这里的问题就是:
证书中的明文，中间人不是可以篡改吗？如果可以改了，不就和之前的方案四一样了吗。
第二个如何理解CA签发证书的过程。
最后一个如何形成csr文件。
前两个问题其实就是一个问题。
先来解决前面两个问题，经过上面的学习能够知道将一个数据经过散列函数之后能够得到一个长度固定的数值。如果再将这个数值使用签名者的私钥进行加密就能够形成一个签名。然后将原始的明文数据加到这个签名的后面（将两个数据附加到一起）。
这样就得到了一个携带签名的数据，
其中签名是被加密过的，而这个数据是明文的。
如何验证这个携带数据签名的数据是否被篡改了呢？
首先将这个数据重新分成明文数据和数据签名两个部分。然后对明文数据进行散列得到一个散列值，在对签名使用签名者的公钥进行解密得到一个散列值，最后如果两个散列值相等那就证明签名和原始的数据都没有被中间人修改过。如果不相等则证明要么是数据被修改了要么是签名被修改了。
而之前说的CA证书不就是一个签名+明文数据合在一起的一个例子吗？现在知道了上面的那个图像再来重新理解一下签名的申请。
首先CA机构要发布自己的证书首先CA机构就要有自己的公钥和私钥。服务器也有自己的公钥和私钥两者互不干扰。
现在一个服务器要申请证书就要提交自己的.csr文件，然后CA会拿着这个csr文件使用特定的哈希散列形成指纹，然后使用自己的私钥对这个指纹进行加密形成签名。
然后将服务器提交上来的诗句和签名附加在一起就形成了证书。
由此就能知道了证书 = 企业明文数据+签名
这就意味着这个签名只有使用CA的公钥进行加密才能重新解开。
现在服务端就将这个签名之前交给了客户端:
客户端拿到这个数据之后依旧是先拿明文数据使用特定的哈希函数进行哈希散列最后得到一个长度固定的哈希值，然后又使用CA的公钥得到这个散列值。
然后判断两个值是否相等，如果相等则证明签名和数据都没有被中间人修改过。
客户端就可以使用这样的判断去判定这个数据是否被篡改。
但是这里依旧是有很多的问题的。
那么这个证书中的公钥如果被修改为中间人的公钥，那么客户端就能够通过散列值的不一致，知道这个证书是一个不安全的证书会直接将其丢弃。
因为这个签名是CA使用私钥和哈希函数生成的一个签名，而中间人没有CA的私钥无法重新生成一份签名，只有CA的公钥自己也只能看一下这个签名的值是多少自己是无法做更多的事情的。
如果是这样的话如果只有证书被改了，那么是OK的因为中间人没有CA的私钥无法形成新的签名（只有散列值经过加密之后才能形成签名但是中间人没有CA的私钥无法进行加密，无法形成新的签名），这就让用户知道你修改了正文（修改了正文后得到的散列值和签名中的散列值是不一样的）。如果只改签名呢？
如果只改签名，数据没有改数据再散列之后得到的散列值和修改后的签名是不一样的，这样客户端依旧会认为这是一个无效的请求。依旧不会正常的处理，并且一般中间人想要的只是数据，自己修改签名是没有意义的。
那么如果中间人将证书和签名全部修改了是否可行呢？
首先中间人没有资格形成正常的签名，因为中间人没有CA的私钥，那么中间人有自己的私钥啊，可以使用自己的私钥啊，但是客户端的浏览器只使用CA的公钥对这个签名进行解密啊。如果是中间人自己形成的签名，是没有办法进行解密的。此时客户端的浏览器也能识别出来这个响应是无效的。
这意味着中间人如果想要骗过浏览器的话，因为浏览器只认CA的公钥。中间人就只能使用真的证书，也就是说这个中间人(黑客)脑子有病，拿着自己的个人信息去申请一份真正的证书
然后黑客在使用这个真的证书替换掉服务端发送而来的证书，此时浏览器的客户端在进行散列以及使用CA的公钥进行解密得到的两个值就是相等的了。这样做是可以骗过客户端的，但是这样做中间人自己也就暴露了。
但是不要忘了在证书上是存在域名的:
所以如果这个黑客想要使用上面的方法就需要提供一个真的域名，而这个域名和目标服务器的域名一定是不一样的。
虽然浏览器认为你的证书是合法的，但是浏览器发现请求的域名和这个证书中的域名是不一样的。此时客户端也能识别出这个证书是否合法:
由此就能够知道了签名是为了保证证书不被篡改而做的。
由此就能知道客户端得到的信息就是:
通过这些信息，客户端就能够甄别出来请求是否是合法的。
只有上面说的这些信息都是正确的，客户端才会认为这个证书是合法的。然后客户端才会从这个证书中提取公钥。这个公钥才是服务器的公钥，然后再走方案四。
之后才能进行正常的通信。因为客户端只使用CA的公钥进行解密，这就意味着客户端必须内置CA或者CA授权机构的公钥。待会去看。
但是因为全世界的民用电脑都是使用的CA的公钥进行解密，这就变相的给了CA的私钥一个签发证书的权力。
现在正式回答这个问题:
中间人可以改明文，但是修改之后中间人就能够识别出来。如何识别就是上面说的。
所以证书中的明文不可以篡改。
所以最后的方法就是:
并且如何对比之前的方法也已经说明过了。
方案5
下图就是方案5的图片:
这个过程也就上面说的那个过程同时也是https的密钥协商过程。
那么当一个公司想要申请证书的时候自己的csr文件是如何形成的呢?
在我自己的Linux上就能做，但是更加方便的方法是使用网上的在线的一些csr文件生成的服务。
最后点击生成，就会生成一个csr文件。并且会将私钥和公钥都生成好。私钥是单独的，但是公钥就没有单独了，而是直接和你所填写的数据一起打了一个包生成了csr文件。未来这个私钥我自己要保存好，而csr文件可以提交给CA让其发布证书。
既然浏览器在得到一个请求之后需要使用CA的公钥去判断是否是合法的证书。那么在浏览器内置的CA的公钥在哪里呢?
在浏览器的设置中搜索证书管理就能看到这样的证书。
这里我的浏览器只有内置CA的公钥，但是其实还可以内置一些CA的子机构的公钥，只不过这些公钥不是为了通信的而是为了认证其它的一些公司的。总结就是客户端内置了CA的公钥。
希望这篇博客能对阅读的您有所帮助，如果发现了任何的错误，欢迎指出。